prompt is too long / context_length_exceeded — 把上下文窗口塞满的，通常不是你刚发出去的那一句

这个上限管的是整段对话，不是你最后那条消息。每一次请求都会把之前的所有东西重发一遍——先前的每一轮、读过的每一个文件、每一条工具结果。所以真正撑爆的那条消息，往往只有一行。而且有三种不同的上限，报错文字几乎一模一样；其中只有一种能靠少发输入解决。

你看到的报错

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 <模型 id>"}}

这里的数字一律写成 <...>，因为它们每个模型、每个端点都不一样——只有你自己报错里的那组数字才值得看。

前两种是同一个问题。第三种是这个问题再加上你给输出预留的空间。第四种是换了一身相似措辞的另一个上限，把输入缩小完全动不到它。

三个都被叫作「context length」的上限

表格第三行是最让人意外的：一个请求可能在还没生出任何一个输出 token 之前就被拒绝，因为你给答案预留的空间，已经跟问题挤不下了。其实没有任何东西太长，是预留得太贪心。

为什么你「只发了一行」它也会炸

没有「单条消息」的上限这回事。每一次请求都会再带上整段对话，所以第 N 条消息的代价，是 1 到 N 的总和。最后那条消息不是原因，它只是压垮骆驼的最后一根稻草。

真正占住窗口的是这些，大致按「被低估的程度」排序：

1. 工具结果。对一个还留着 node_modules 的仓库列一次目录、读一次 lock 文件、在整棵树上做一次没收敛范围的搜索。在对话记录里，这些看起来只是一行短短的输出。在请求里不是。
2. 早先读过、之后一直没放掉的文件。第 2 步读的那个文件，到了第 40 步还在被重发。
3. 会话一开始就自动加载的项目指示文件。你从来没看它们滚过屏幕，但它们在每一次请求里。
4. 对话本身——大家第一个怪罪的那块，通常也是最小的那块。

有两个推论值得记牢：

• 失败的请求不会让历史变短。这就是为什么一次溢出之后紧接着又一次：重试发的是同一份超大的请求内容。你得先移掉一些东西，再重试。
• 窗口填得最快的时候，是一个顺利进行的长任务，不是一个难搞的任务。一大堆全都成功的小工具调用，就是最典型的样子。

按这个顺序排查

/context

# <模型 id>：从 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":"<模型 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

# <模型 id>：从 https://api.9coding.com/v1/models 里复制一个
# 下面的 max_tokens 只是个随便取的探测值，不是文档写的上限
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":"<模型 id>","max_tokens":1024,"messages":[{"role":"user","content":"hi"}]}'

什么时候这不是你的问题

• 同一份 prompt 在某个端点塞得下，在另一个端点塞不下。网关可能把窗口压在低于模型本身支持的上限。拿它跟模型文档写的上限比一比；两者对不上，那就是端点的策略，不是你发的内容。
• 不管你删掉什么，它都在完全相同的大小失败。固定开销——系统提示、工具 schema——吃掉了一块你在对话里编辑不到的份额。把启用的工具数量减少。
• 今天突然开始失败，而你的配置完全没动。可用窗口大小和默认 max_tokens 都是端点那一侧的配置，是会变的。
• 连压缩本身都失败。这是唯一一种你真的没办法原地救回来的情况；开一个新的会话。

一个不公开自己实际上下文上限的端点，是你没办法规划长任务的端点——你只能靠撞上去，才知道天花板在哪。在你花一下午重写 prompt 之前，先去看运营方的状态页——我们的在状态页。

提问题时请带上 request id——9Coding 的报错响应里都有一个，形如 (request id: 2026...)。这个 id 加上时间戳、模型名和完整报错文本，就能把那一次调用查出来。只说「用不了」的反馈没法排查。

不是同一个问题

429 表示请求大小没问题，是你发太多次了——请看 429 Too Many Requests。带 invalid_request_error、但报错里没有任何大小数字的 400，是请求格式有问题，不是请求太大——请看多轮对话里的 400 Bad Request。这两种都在别的页。

相关报错

• 429 Too Many Requests — 退避重试，或把上限拉高
• 多轮对话里的 400 Bad Request — 格式有问题、跟大小无关的请求
• Model not found — 一种报错，三个互不相干的原因
• 全部报错速查 — 排查手册总表