Skip to content
FeaturesError referenceBlogDocsChangelog

stream disconnected before completion: Your input exceeds the context window of this model. Please adjust your input and try again

The prefix is misleading and the suffix is the answer. Nothing on your network failed. A size limit was enforced, the platform said so in plain words, and your client wrapped that verdict in the same sentence it prints for dropped connections and dead sockets. Read past the colon: this is arithmetic, it is deterministic, and it will produce the identical result every time until the input changes. It is not a rate limit — those arrive as a 429 with headers attached — and it is not an outage.

Data as of 2026-09. Vendor limits and defaults change; check the official docs for current values before acting on any number below.

Two failures wearing one sentence

The reason this page exists is that the two halves of the string carry opposite advice, and the half people act on is the wrong one. “Stream disconnected” invites you to retry, check your VPN, and blame the network. The rest of the sentence says retrying is pointless. When a message contains both a transport complaint and a server verdict, the verdict wins — the transport complaint is just the shape your client’s error-handling code happened to have available.

That also tells you which of this site’s pages are useless to you. The byte-counting and timeout-hunting techniques that work on genuine stream failures will find nothing here, because there is nothing wrong with the path. Skip them entirely.

Did any output arrive before it?

Ask this before you change anything, because it splits the error into two different problems with two different fixes.

OpenAI’s streaming semantics are documented along exactly this line: for streaming requests, HTTP error responses apply before the stream starts, and an error arriving after streaming begins comes through as a stream event instead. So the timing of the verdict tells you when the ceiling was crossed.

No output at all. The request was measured and refused before the model saw any of it. The overflow was already present when you pressed enter, the number is whatever you sent, and the fix is straightforward reduction. Your client simply formatted a pre-stream rejection using its streaming error text — which is a reporting defect, not a clue.

Output arrived, then the verdict. This is the interesting case and the one people misdiagnose. The request was accepted, so it fit at submit time. The ceiling was reached while the turn was in flight. The number that overflowed is not the number you sent. Something grew during the turn: tool results appended to the conversation, files read into context, retrieved documents, intermediate reasoning, and the model’s own output — all of it occupies the same window. This is why people measure their prompt, find it comfortably under the limit, and conclude the error is lying. It is not; they are measuring the wrong moment.

The window is not your input budget

Here is the hard fact that resolves most of the confusion, and it is published on the model pages rather than derived.

For the currently featured models the context window is 1,050,000 tokens while the maximum input is 922,000 tokens. Those are two different published numbers, and the gap exists because the window has to hold the answer as well as the question. Writing “the window is 1.05M, so I can send 1.05M” is wrong by a margin large enough to be the whole cause of your failure.

Two consequences follow. First, “my prompt is under the context window” is not a valid test — compare against the published input maximum, and leave room for the output you actually want. Second, the same reasoning is why switching to a model with a larger window is a weaker fix than it sounds: you inherit a new pair of numbers, not a removed constraint, and if the growth is happening mid-turn a larger window postpones the wall rather than removing it.

There is a cost consequence worth knowing before you solve this by buying more room. Per the current pricing documentation, prompts over 272,000 input tokens are billed at 2× the input and cache rates and 1.5× the output rate for the entire request — not just for the overflow. So the expensive threshold sits well below the wall you just hit, and a workflow that habitually runs near the ceiling is paying the multiplier on every request long before it starts failing. Check the current pricing page before you plan around those figures.

Is retrying useful?

No. An identical request produces an identical rejection.

Nothing about waiting changes a token count. There is no queue draining, no capacity recovering, no Retry-After to honour — those belong to throttling errors, and this is not one. Each attempt re-sends the entire oversized input, which means you pay for it, and failed requests still count against your per-minute limits.

One honest caveat for the mid-turn case: a retry sometimes appears to work, because the turn is not really identical — a tool returned less output this time, or the model reasoned more briefly. That is luck, not a fix. The workflow is running at the ceiling and will hit it again on the next turn that goes slightly longer. Treat an accidental success as a warning, not a resolution.

If your tooling automatically retries this, turn that off before it burns through a budget reproducing a known answer.

Where the tokens actually are

Each of these has an observation that confirms or rules it out.

Does a fresh session with the same prompt succeed? If yes, the accumulated conversation is the weight, not your request. If it fails identically in a clean session, the request itself is oversized and the history is irrelevant.

Does removing attachments or file reads fix it? Files pulled into context are the most common single contributor and the easiest to test by subtraction. Remove the largest one and re-run.

Does it only happen on turns that call tools? Tool results are appended to the conversation and counted like everything else. A turn that calls a tool returning a large payload can cross the line that the same turn without the tool never approaches.

Does it happen right after a failed summarisation? Then you are in a loop, not an incident. A failed compaction leaves the session at its maximum size, which makes the next turn a worst-case request — see the remote compact task failing mid-stream for why the operation meant to save you is the one most likely to fail.

Does the same input rejected cleanly by a non-streaming call name a number? A direct rejection reports the counts explicitly, which turns your estimate into a measurement; see the 400 context_length_exceeded response for the shape of that answer.

Fix by scenario

  • No output arrived, clean session — the request is too big as written. Reduce it against the published input maximum, not the window, and budget for the response as well. The context window calculator is for doing that before you send rather than after you fail.
  • No output arrived, long-running session — the history is the payload. Start a new session seeded with a short summary you write yourself. A summary you paste is a few hundred tokens; the history is not.
  • Output arrived, then the verdict — the growth is mid-turn. Cap what enters the conversation during a turn: bound tool output size, read file excerpts rather than whole files, and split multi-step work into separate turns so each one starts from a known size.
  • You reserved a large output allowance — the window holds both halves. Reducing the reserved output is sometimes the smallest change that makes an otherwise correct request fit; the failure mode where those two numbers leave no room at all is maxTokens too close to contextLength.
  • Tempted to just move to a bigger model — do it with the input maximum and the repricing threshold in front of you, not the marketing number.

How to confirm it’s fixed

A smaller request succeeding proves nothing; smaller requests were never failing. The confirmation has to run at or above the size that failed.

Measure the input before you send it, re-run the turn that broke, and require it to complete twice in a row with the measurement recorded both times. For the mid-turn case, add the specific check: log the size of the conversation after the turn completes, and confirm it is still under the input maximum with room for another answer. A turn that succeeded while landing exactly at the ceiling has not fixed anything — it has scheduled the same failure for the next turn.

Neighbouring failures in this cluster are told apart by when the ceiling was measured. When the same verdict arrives as an ordinary HTTP rejection with the counts printed, nothing is wrapping it and the numbers are handed to you; that is the 400 context_length_exceeded response. When the operation that fails is the summarisation itself rather than your turn, read Error running remote compact task, because that one is a delivery failure on the largest request in the session and has a different fix. And when the input fits but the requested output leaves no room to produce an answer, the arithmetic is the other way round in maxTokens is too close to contextLength.