1. 长对话突然报 Prompt is too long，问题到底出在哪

如果你在用 Claude 做长文档分析、多轮代码审查，或者把 Claude Code 挂在项目里连续跑任务，大概率见过这个报错：Prompt is too long。它不像语法错误那样能一眼定位，因为触发它的不是某一行代码写错，而是整个请求的输入 token 累计超过了模型上下文窗口。换句话说，你这次发出去的内容本身可能没问题，但加上之前所有对话历史、系统提示、工具返回结果，总量爆了。

这个报错在 Claude API 和 Claude Code 里都会出现。API 侧通常返回 HTTP 400，错误体里带prompt: too long或input length字样；Claude Code 侧则直接提示Prompt is too long，有时候你执行了/compact压缩历史，结果还是报同样的错。很多人第一反应是“我这条消息又不长啊”，但上下文窗口算的是总和，不是单条。

我先把结论说清楚：Prompt is too long的本质是输入 token 数超过了模型配置上限。要解决它，得先搞清楚三件事——token 怎么算、窗口怎么构成、哪部分在偷偷吃额度。这篇就按这个顺序拆，给出可复制的 token 估算脚本、分段裁剪配置，以及一次从报错到恢复的完整验证动作。适合正在用 Claude API 或 Claude Code 做长上下文任务的开发者，也适合刚接触 token 概念、被这个报错卡住的小白。

先建立一个直觉：token 不是字符，也不是单词。英文里 1 个单词大约 1.3 个 token，1 个汉字大约 1 到 2 个 token，一行代码可能 5 到 20 个 token。所以一个 10KB 的英文文本可能只有 3000 token，但同样 10KB 的中文文本可能到 6000 token。代码因为符号密集，往往比同等长度的散文更吃 token。你如果按字符数去估，误差会很大，这就是为什么很多人觉得“我没超啊”却依然报错。

上下文窗口的构成也要拆开看：系统提示 + 所有历史用户消息 + 所有历史助手消息 + 当前消息 +max_tokens输出预留。注意最后一项，max_tokens是你给输出留的空间，它同样占用窗口。比如 200K 窗口的模型，你设了max_tokens=8192，那输入实际可用就是 200K 减去 8192 再减去一些安全余量。很多人只盯着输入，忘了输出预留也在窗口里。

触发超限的常见原因按占比排：对话历史累积最高，多轮之后历史消息把窗口占满；单条消息过大其次，一次塞了长文档或完整代码文件；系统提示过长也常见，尤其是那种写了几千字角色设定的 prompt；max_tokens设置过高会挤压输入空间；工具调用返回大量数据也会中招。不同模型窗口大小还不一样，用 Haiku 时比 Opus 更容易频繁触发，因为窗口配置不同。

所以定位思路应该是：先算总量，再找最大占用项，最后决定是截断、滑动窗口还是分块。下面进入实操。

2. 用 TaoToken 统一接入 Claude，先把 Key 和 Base URL 配好

在动手写 token 估算脚本之前，得先有一个能稳定调用 Claude 的入口。我这边习惯用 TaoToken 做统一接入，原因是它把模型对话、API Key 管理、Coding Plan 这些入口放在一起，切换模型和排查请求都方便。官网是 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 地址是 https://taotoken.net/api ，注意 API 这个地址不加 UTM 参数。

如果你只是想在网页里验证一下模型能不能正常回话，可以直接用模型对话入口：https://taotoken.net/models?utm_source=taotoken_aicg_blog_end&utm_content=model_chat&utm_campaign=rewrite 。这个适合快速确认“是输入太长还是计数偏差”——你先发一条短消息，如果正常返回，说明接入没问题，问题在长输入；如果短消息也报错，那可能是 Key 或 Base URL 配错了。

要拿 API Key，去这个地址：https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api_keys&utm_campaign=rewrite 。拿到 Key 之后，Claude Code 用户还需要配 Base URL 和 Model ID，这三件套缺一不可。Claude Code 的接入文档在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite ，里面有具体的环境变量写法。

如果你打算长期跑编码任务或者 Agent，建议看一下 Coding Plan：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding_plan&utm_campaign=rewrite 。它更适合那种需要连续多轮、上下文不断累积的场景，因为这类场景正是Prompt is too long的高发区，提前规划好额度管理比事后救火省事。

配好之后，先做一次最小验证：用 curl 或 Python SDK 发一条"你好"，确认返回正常。这一步别跳过，因为后面所有 token 分析都建立在“接入是通的”这个前提上。如果这一步就报 401，那先解决鉴权，别急着调 token。

3. 可复制的 Token 估算与分段裁剪配置

这一节是核心，给出能直接跑的代码和配置。先讲 token 估算，再讲截断，最后给 Claude Code 的 settings 片段。

3.1 用 API 精确计数，别只靠字符估算

Anthropic 提供了count_tokens接口，能拿到精确的 input token 数。这是最靠谱的方式，因为不同语言的 token 密度差异太大，纯字符估算误差可能到 30% 以上。下面这段可以直接复制：

import anthropic client = anthropic.Anthropic( api_key="你的_TaoToken_Key", base_url="https://taotoken.net/api" ) def count_tokens_exact(text, model="claude-3-5-sonnet-20241022"): """调用 API 精确计算 token 数""" result = client.beta.messages.count_tokens( model=model, messages=[{"role": "user", "content": text}] ) return result.input_tokens def count_tokens_approximate(text): """降级估算：混合文本按 1 token ≈ 3 字符""" return len(text) // 3

注意base_url指向 TaoToken 的 API 地址，这样你不需要改其他代码就能切换。精确计数适合在发送前做一次校验，尤其是长文档场景，多花一次轻量请求换来确定性，很值。

3.2 分析对话构成，找出谁在吃 token

光知道总量不够，得知道是哪条消息占的。下面这个函数会按消息逐条统计，并打印最大的几条：

def analyze_conversation(messages, model="claude-3-5-sonnet-20241022", max_tokens=4096): total_text = "" breakdown = [] for i, msg in enumerate(messages): content = msg["content"] if isinstance(content, list): content = " ".join([c.get("text", "") for c in content if c.get("type") == "text"]) approx = count_tokens_approximate(content) total_text += content breakdown.append({ "index": i, "role": msg["role"], "chars": len(content), "approx_tokens": approx, "preview": content[:80] + "..." if len(content) > 80 else content }) total_approx = count_tokens_approximate(total_text) + max_tokens print(f"消息数: {len(messages)} | 总字符: {len(total_text)} | 估算总 tokens(含输出预留): {total_approx}") for item in breakdown: print(f"#{item['index']} [{item['role']}] 字符:{item['chars']} 估算:{item['approx_tokens']} | {item['preview']}") return breakdown, total_approx

跑一次你就能看到，往往不是当前这条消息最大，而是某条历史助手回复或者工具返回结果特别长。定位到之后，处理就有针对性了。

3.3 分段裁剪：保留最近消息，截断超长单条

下面这个TokenManager做两件事：从后往前保留最近消息，遇到超预算的单条就按比例截断，并尽量在句子边界断开：

class TokenManager: def __init__(self, model="claude-3-5-sonnet-20241022", max_context=200000, max_output=4096): self.model = model self.max_context = max_context self.max_output = max_output self.available_input = max_context - max_output - 1000 # 预留安全余量 def count_tokens(self, text): try: return count_tokens_exact(text, self.model) except Exception: return count_tokens_approximate(text) def truncate_message(self, content, max_tokens): current = self.count_tokens(content) if current <= max_tokens: return content ratio = max_tokens / current target_chars = int(len(content) * ratio) truncated = content[:target_chars] last_period = max(truncated.rfind('。'), truncated.rfind('.'), truncated.rfind('!')) if last_period > len(truncated) * 0.8: truncated = truncated[:last_period + 1] return truncated + "\n[内容已截断...]" def prepare_messages(self, messages, system_prompt=""): system_tokens = self.count_tokens(system_prompt) if system_prompt else 0 budget = self.available_input - system_tokens prepared = [] total = 0 for msg in reversed(messages): content = msg["content"] if isinstance(content, list): content = " ".join([c.get("text", "") for c in content if c.get("type") == "text"]) msg_tokens = self.count_tokens(content) if total + msg_tokens <= budget: prepared.insert(0, msg) total += msg_tokens else: remaining = budget - total if remaining > 100: prepared.insert(0, {"role": msg["role"], "content": self.truncate_message(content, remaining - 50)}) break return prepared, total

用法就是manager = TokenManager()，然后prepared_msgs, token_count = manager.prepare_messages(messages)。这样发送前就自动裁剪好了。

3.4 Claude Code 的 settings 配置片段

如果你用的是 Claude Code，可以在项目根目录的.claude/settings.json里配置环境变量，把 Base URL、Key、Model ID 三件套写全：

{ "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_API_KEY": "你的_TaoToken_Key", "ANTHROPIC_MODEL": "claude-3-5-sonnet-20241022" } }

注意ANTHROPIC_BASE_URL不要带 UTM 参数，保持干净。配好之后重启 Claude Code，再跑一次长任务，观察是否还报Prompt is too long。如果还报，说明是历史累积问题，需要配合/compact或者手动清理会话。

4. 验证请求：从报错到恢复的完整动作

这一节演示一次真实的恢复过程。假设你有一个长对话，发送后报Prompt is too long，按下面步骤走。

第一步，先确认接入是通的。发一条短消息：

resp = client.messages.create( model="claude-3-5-sonnet-20241022", max_tokens=100, messages=[{"role": "user", "content": "你好"}] ) print(resp.usage.input_tokens, resp.content[0].text)

如果这条正常返回，说明 Key、Base URL、Model ID 都没问题，问题在长输入。如果这条也报错，先回去检查第 2 节的配置。

第二步，用analyze_conversation跑一遍你的长对话，看总量和最大占用项。假设输出显示总估算 210K token，其中第 3 条助手消息占了 80K，那基本就是它。

第三步，用TokenManager.prepare_messages裁剪后重新发送：

manager = TokenManager() prepared, total = manager.prepare_messages(messages) print(f"裁剪后消息数: {len(prepared)}, 估算 tokens: {total}") resp = client.messages.create( model="claude-3-5-sonnet-20241022", max_tokens=4096, messages=prepared ) print("成功，input tokens:", resp.usage.input_tokens)

如果这次返回正常，并且resp.usage.input_tokens明显小于窗口上限，说明恢复成功。注意看usage.input_tokens这个字段，它是 API 实际计数的结果，比你的估算更权威。如果它接近 200K，说明你裁得还不够，需要再降max_output或者进一步截断历史。

第四步，做一次回归验证。把裁剪后的消息再跑一次analyze_conversation，确认总量在预算内。然后连续发 3 到 5 轮新对话，观察是否再次触发。如果不再触发，说明滑动窗口策略生效了。

这里有个细节：/compact在 Claude Code 里是压缩历史，但它压缩后的结果仍然占 token，如果压缩本身没压到位，还是会报错。所以/compact之后要再看一次 token 数，别以为执行了就万事大吉。

5. 常见报错对照排查

这一节把真实会遇到的报错列出来，对照处理。

401 Unauthorized：Key 错了或者没带上。检查ANTHROPIC_API_KEY是否填对，Base URL 是否是https://taotoken.net/api。注意 API 地址不带 UTM，带了可能被当成非法路径。

local proxy failed：本地网络层的问题，通常是 Base URL 写错或者本地有拦截。确认你填的是 TaoToken 的 API 地址，而不是别的地址。这个报错和 token 无关，别往上下文方向查。

reading 'choices'：这个报错通常出现在响应解析阶段，说明返回体结构和你预期的不一样。检查 Model ID 是否写对，比如claude-3-5-sonnet-20241022这种完整 ID，别简写。如果 Model ID 错了，返回体可能不是标准格式，解析就崩了。

OAuth相关报错：Claude Code 有时会走 OAuth 流程，如果你用的是 API Key 模式，确认没有混用。settings.json 里三件套写全，别只写 Key 不写 Base URL。

Prompt is too long本身：按第 3、4 节处理。先算总量，再找最大项，再裁剪。如果裁剪后还报，检查max_tokens是不是设太高，把它降到 4096 甚至 2048 试试。

还有一个容易忽略的：工具调用返回。如果你用了 function calling，工具返回的 JSON 可能非常大，它同样计入上下文。这种情况要在工具层做截断，别把整个返回塞回去。

排查顺序建议：先确认接入通（短消息测试），再看报错类型（401 还是 too long），再算 token，最后裁剪。别一上来就改代码，先定位。

6. 把上下文管理做成习惯，而不是救火

Prompt is too long这个报错，本质上是上下文管理没跟上。200K 窗口听起来很大，但在长对话里消耗得比你想象快。我的做法是在消息进入 API 之前加一层TokenManager，自动截断和滑动窗口，这样不用每次手动救火。

几个实用习惯：发送前估算总量，接近上限就主动裁剪；单条消息超过 5000 token 就截断；保留最近 10 到 20 轮对话，早期内容要么总结要么丢弃；长文档分块处理，每块控制在 3000 token 以内；系统提示精简到 1000 token 内；max_tokens别设太高，够用就行。

如果你经常跑长任务，建议把 Coding Plan 用起来，它的额度管理更适合这种连续多轮场景。接入文档在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite ，里面有完整的配置说明。需要拿 Key 就去 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api_keys&utm_campaign=rewrite ，想先验证模型回话就去 https://taotoken.net/models?utm_source=taotoken_aicg_blog_end&utm_content=model_chat&utm_campaign=rewrite 。

最后提醒一句：token 数直接决定费用，主动管理上下文不只是为了避免报错，也是在省钱。把usage.input_tokens打日志，观察它的变化趋势，比事后猜要靠谱得多。