prompt is too long / context_length_exceeded — what filled the window usually isn't what you just sent

The limit applies to the whole conversation, not to your last message. Every request re-sends everything that came before it — earlier turns, every file that was read, every tool result. So the message that finally overflows is often a one-liner. And three different limits produce nearly identical error text; only one of them is fixed by sending less input.

What you're seeing

API Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"prompt is too long: <your-count> tokens > <limit> maximum"}}

{"error":{"message":"This model's maximum context length is <limit> tokens. However, your messages resulted in <your-count> tokens. Please reduce the length of the messages.","type":"invalid_request_error","param":"messages","code":"context_length_exceeded"}}

{"type":"error","error":{"type":"invalid_request_error","message":"input length and `max_tokens` exceed context limit: <input> + <max_tokens> > <limit>, decrease input length or `max_tokens` and try again"}}

{"type":"error","error":{"type":"invalid_request_error","message":"max_tokens: <your-value> > <limit>, which is the maximum allowed number of output tokens for <model-id>"}}

Numbers are shown as <...> here because they differ per model and per endpoint — the ones in your message are the only ones worth reading.

The first two are the same problem. The third is that problem plus your output reservation. The fourth is a different limit wearing similar words, and shrinking your input will not move it.

Three limits that get called "context length"

The third row is the one that surprises people: a request can be rejected before a single output token is generated, because the space you reserved for the answer no longer fits next to the question. Nothing was actually too long. The reservation was too greedy.

Why it fires when you "only sent one line"

There is no per-message limit. Each request carries the entire conversation again, so message N costs the sum of everything from 1 to N. The last message isn't the cause; it's the straw.

What is actually occupying the window, roughly in order of how much people underestimate it:

1. Tool results. One directory listing of a repo that still has node_modules, one read of a lock file, one un-narrowed search across the tree. In the transcript these look like a single short line of output. In the request they are not.
2. Files read earlier and never released. A file read in step 2 is still being re-sent in step 40.
3. Project instruction files loaded automatically at session start. You never see them scroll past, and they are in every request.
4. The conversation itself — the part everyone blames first, and usually the smallest.

Two consequences worth internalising:

• A failed request does not shrink the history. That's why one overflow is immediately followed by another: retrying sends the same oversized payload. You have to remove something before retrying.
• The window fills fastest during a successful long task, not during a hard one. Lots of small tool calls that all worked is the classic profile.

Check in this order

/context

# <model-id>: copy an id from https://api.9coding.com/v1/models
curl -sS https://api.9coding.com/v1/messages/count_tokens \
  -H "Authorization: Bearer sk-9c-xxxxxxxx" \
  -H "content-type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model":"<model-id>","messages":[{"role":"user","content":"paste the text you are about to send"}]}'

wc -c < the-file-you-are-about-to-paste.txt

/compact

/clear

du -sh -- */ 2>/dev/null | sort -h | tail -15
find . -type f -not -path './.git/*' | wc -l

node_modules/
dist/
build/
.next/
vendor/
coverage/
logs/
*.min.js
*.map
package-lock.json
pnpm-lock.yaml
*.png
*.jpg
*.pdf
*.csv

# <model-id>: copy an id from https://api.9coding.com/v1/models
# max_tokens below is an arbitrary probe value, not a documented limit
curl -sS -w '\n%{http_code}\n' https://api.9coding.com/v1/messages \
  -H "Authorization: Bearer sk-9c-xxxxxxxx" \
  -H "content-type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model":"<model-id>","max_tokens":1024,"messages":[{"role":"user","content":"hi"}]}'

When it isn't your problem

• The same prompt fits on one endpoint and not another. A gateway may cap the window below what the model itself supports. Compare against the model's documented limit; if they disagree, that's an endpoint policy, not your payload.
• It fails at exactly the same size no matter what you remove. Fixed overhead — system prompt, tool schemas — is taking a share you can't edit from inside the conversation. Reduce the number of enabled tools.
• The failure appeared today with no change to your setup. Available window and default max_tokens are configuration on the endpoint's side and can move.
• Compaction itself fails. That's the one case where you genuinely can't recover in place; start a new session.

An endpoint that doesn't publish its effective context limit is an endpoint where you cannot plan a long task — you can only discover the ceiling by hitting it. Check the operator's status page before you spend the afternoon rewriting prompts; ours is at status.

When reporting it, include the request id — 9Coding error responses carry one in the form (request id: 2026...). That id plus the timestamp, the model name and the full error text lets the exact call be traced. A report that only says it doesn't work cannot be investigated.

Not the same problem

A 429 means the request was the right size and you sent too many of them — see 429 Too Many Requests. A 400 with invalid_request_error but no size in the message is a malformed request, not a large one — see 400 Bad Request in multi-turn conversations. Both are elsewhere.

Related

• 429 Too Many Requests — back off, or raise the limit
• 400 Bad Request in multi-turn conversations — malformed requests that aren't about size
• Model not found — one message, three unrelated causes
• All Claude Code errors — the quick reference table