We’re seeing web search citation markers bleed into the actual text output on the Responses API with gpt-5.5.

The model emits citation spans wrapped in invisible unicode (U+E200 to open, U+E201 to close, U+E202 between the inner tokens) and these aren’t being stripped before the text comes back to us. They’re invisible characters, so the moment anything renders the text and drops them, you’re left with the visible junk in the middle of the response, e.g. citeturn0search2turn0search4

The multi-source form (\ue200cite\ue202turn0search0\ue202turn0search1\ue201) seems more likely to show up visibly.

Screencap from one of our streams:

These come through alongside proper structured url_citation annotations on the text block, so the citation data itself is fine, it’s just the inline text that’s dirty.

Rough repro: Responses API, gpt-5.5, streaming, web_search tool enabled. Force a turn that searches the web and cites an official page inline, e.g. ask it to state some current fact and cite the source in its reply. Prompting it to cite the source inline, especially multiple sources, makes the markers show up.

The issue is a behavior also seen with citations in file search.

The issue is not “aren’t being stripped”. The issue is, “being generated incorrectly by the AI model”.

Instead of correctly closing with the special symbol to end the citation, the AI repeated the mid symbol. Then it continued with another item, potentially made up - or the AI model could have written the first one wrong (or sampled from poor certainty), and then tried again immediately.

It is a model behavior.

If you extract the special code points as you’ve done, you can produce some more developer message with examples of how to write citations, further modeling on the web search tool instruction of citation that is injected in web search tool specification in OpenAI’s own system message, and continuing in that style. Seeing a proper closing, and examples with higher turn numbers, then the AI might be encouraged to write the citation correctly such that the backend can detect and strip the text, and include the correct API return object.

Fair, I’ll take the correction on what the underlying cause probably is.

We have coded around it for now, but is the suggestion that this is something we should be building prompts around? With unmatched markers leaking into text, it seems reasonable that Openai would address this, especially given they’ve been addressing similar issues with the file search tool.

If you want to see the symptom “addressed”, you might test the behavior along with your API use-case against the gpt-5.6 AI model family, as this is an issue with generation - the AI not producing the correct ending symbol of a citation, not enough attention paid to the one place in the tools spec injection where it says how to write a citation.

You can also disallow citations completely, going against the higher-priority system message, but then you won’t have any web links to re-insert if the AI model does obey.

Parallel tool calls and its internal method, if not being used for developer functions, can also be disabled by API parameter, as this is more tokens of “wrapper” instructions of developer function to enable placing function calls within a different tool output wrapper that would not be needed and cannot be used for internal tools. That can reduce distraction.