Ollama Responses API silently drops conversation history and still returns success

A silent failure in Ollama's Responses endpoint

Ollama's OpenAI-compatible /v1/responses endpoint accepts the previous_response_id parameter, replies with HTTP 200 and a "completed" status, and then answers as though the earlier conversation never happened, according to a detailed write-up on dev.to. Nothing fails and the reply looks plausible — the model is simply answering a different, context-free conversation than the one the client thinks it is having.

The author tested Ollama 0.34.0 on Debian 13, CPU-only, running qwen2.5:1.5b. Turn one told the model a secret word — PINEAPPLE — and got back "OK". Turn two referenced that response by id and asked for the secret word; the model answered "password". Two controls pinned down the cause: asking with the whole conversation inline cost 68 input tokens and correctly returned "PINEAPPLE", while asking with no history at all cost 41 tokens and produced the same "password" guess as the previous_response_id request — which also cost 41 tokens. The usage numbers are the tell: the stateful-looking request was billed exactly like a context-free one.

Worse inside tool-calling loops

The failure takes a sharper shape with tools. The author instructed the model to call a check tool once and then reply exactly "DONE". After the model emitted the function call, the client ran the tool and sent back only what the protocol prescribes — previous_response_id plus the function_call_output. Ollama returned 200 with a friendly, on-topic and wrong reply ("The test passed successfully! Is there anything else you need help with?") at 144 input tokens, the same count as turn one. The control that resent the full history cost 179 tokens and correctly answered "DONE".

The dev.to post traces the upstream report that started the investigation to a hosted :cloud model behind the same proxy, which returned an empty output with zero input tokens for the same context-free tool result — something Codex Desktop then treated as a cleanly finished turn. That exact empty-output symptom did not reproduce with a local model, and the author did not test a hosted one. What did reproduce was the underlying problem: the context is gone, and whatever the backend does with an orphaned tool result is up to the backend.

The root cause

In openai/responses.go in Ollama 0.34.0, the request struct has no field for previous_response_id at all. Go's encoding/ silently discards unknown keys unless DisallowUnknownFields is set, and Ollama does not set it, so the parameter vanishes before any handler runs. The response struct, meanwhile, does declare the field and explicitly sets it to nil with a code comment reading "Not supported", meaning every response carries previous_response_id: null. That null is the one honest signal in the exchange, and no client reads it back, because OpenAI's own implementation echoes the id you sent. A feature request to implement the field, ollama/ollama#15954, has reportedly been open since May.

The Codex proxy path

The same loss occurs through /api/codex/v1/responses, the proxy path that ollama launch codex sets up for Codex Desktop. According to the post, this is not a separate implementation but a router: models listed in ~/.codex/ollama-launch-codex-routing. are forwarded to Ollama's own /v1/responses, everything else to OpenAI. Since the drop happens downstream in the shared handler, the proxy discards the parameter in exactly the same way. A fresh install without the routing file answers 503, which is unrelated to the bug.

The workaround

Until Ollama implements the field, clients must stop relying on server-side state and resend the full conversation in input on every turn — prior messages, the function call and the function output together. That pattern worked on both paths in the tests. Most OpenAI-compatible clients already behave this way; the exposed ones are those built against the Responses API's stateful mode, Codex being the prominent case. The author also published a short verification script that plants a random secret word, asks for it via previous_response_id, and compares token counts to detect the bug on any Responses server.

Why it matters

This is the hardest class of bug in AI plumbing: a broken contract that still returns success. Logs show 200, completed and a coherent answer, so nothing raises an alarm — yet stateful agents silently lose every prior turn, forget instructions mid-loop, and confabulate around tool results that arrive from nowhere. Anyone running Ollama behind Codex or other Responses-native clients should run the secret-word check and switch to full-history requests until ollama/ollama#15954 is addressed.