令牌、上下文窗口与成本
了解为什么每一轮都会发送完整历史记录，以及这样做的成本。
令牌、上下文窗口与成本 是 CoddyKit 上的免费 Claude Architect 课时。 这是第 4 节课，共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 Claude Architect 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 Claude Architect 课程共包含 4 节课。
本课时的部分内容尚未翻译，以英文显示。
Claude Has No Memory
Here is the most important idea in this lesson: the Claude API keeps NO state between turns.
The model does not remember your last message. Each API call starts fresh. So how do chatbots seem to remember?
You send the full conversation history in every single request. The messages field carries the whole back-and-forth, every time.
What a Request Carries
A Claude API request has a few key fields:
model— which Claude model to usemax_tokens— the cap on the reply lengthsystem— the system promptmessages— the FULL history every turntools/tool_choice— optional tool config
Notice messages grows over time. Turn 1 sends 1 message. Turn 10 sends all 19 prior messages plus the new one.
resp = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=1024,
system="You are a support agent.",
messages=[
{"role": "user", "content": "My order is late."},
{"role": "assistant", "content": "I can help. What is your order ID?"},
{"role": "user", "content": "It's #4821."},
],
)What Is a Token?
Models do not read characters or whole words. They read tokens — small chunks of text.
A rough guide: one token is about 4 characters of English, or roughly 3/4 of a word. "unhappiness" might split into "un", "happiness". Punctuation and spaces count too.
Tokens matter because you pay per token and the context window is measured in tokens, not words.
Input vs Output Tokens
Every request has two token counts that are billed differently:
- Input tokens — everything you send:
system+tools+ the fullmessageshistory. - Output tokens — what the model generates in its reply.
Output tokens usually cost more per token than input tokens. But because the full history is resent each turn, input tokens are what quietly balloon in long conversations.
The Context Window
The context window is the maximum number of tokens a model can handle in one request — input plus output combined.
If your full history plus the requested max_tokens exceeds the window, the request fails. The window is a hard ceiling, not a suggestion.
This is why long-running chats and big tool outputs eventually hit a wall: the resent history keeps growing toward the limit.
Cost Grows With History
Because you resend the whole history each turn, cost does not grow linearly with the conversation — it grows roughly with the square of its length.
Turn 1 bills a few tokens. Turn 20 bills all 19 prior turns again, plus the new one. A 10-message chat re-bills the early messages 10 times over its life.
For an architect, this means: a chatty agent that never trims its history is an expensive agent.
# Rough illustration of resent input growing each turn
history = []
for turn in range(1, 6):
history.append({"role": "user", "content": user_msg(turn)})
resp = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=512,
messages=history, # ENTIRE history resent every turn
)
history.append({"role": "assistant", "content": resp.content})
print("turn", turn, "input_tokens", resp.usage.input_tokens)Measure Before You Optimize
Every response includes a usage object reporting input_tokens and output_tokens. This is your ground truth for cost.
You can also count tokens before sending, so you can predict cost and check you are under the window — without paying for a full generation.
Rule of thumb: instrument token usage in production. Aggregate cost numbers hide which conversations or tool calls are the expensive ones.
count = client.messages.count_tokens(
model="claude-sonnet-4-5",
system="You are a support agent.",
messages=history,
)
print("input tokens before send:", count.input_tokens)
resp = client.messages.create(model="claude-sonnet-4-5", max_tokens=512, messages=history)
print("billed:", resp.usage.input_tokens, resp.usage.output_tokens)Tool Output Bloats Context
In agentic loops, tool results are appended to the history and resent on every following turn. A verbose tool that returns a 5,000-token JSON blob keeps costing you for the rest of the conversation.
The fix is to trim verbose tool output to the relevant fields before appending it. Do not store a whole API dump in context when three fields are all the model needs.
raw = lookup_order(order_id) # huge JSON
# Trim to what the model actually needs
tool_result = {
"order_id": raw["id"],
"status": raw["status"],
"eta": raw["estimated_delivery"],
}
history.append({
"role": "user",
"content": [{"type": "tool_result", "tool_use_id": tu_id,
"content": json.dumps(tool_result)}],
})Summarize to Stay in Budget
For long conversations, you can replace old turns with a compact progressive summary to keep the history small and under the window.
But beware: summarization makes numbers, percentages, and dates vague. The model rewrites "refund of $482.10 on 2026-03-14" into "a refund last spring."
The architect's fix: pull transactional facts into a separate verbatim "case facts" block kept outside the summary, so exact values never get blurred.
Lost in the Middle
A bigger context window is not a free pass. Models attend most strongly to the start and the end of the input, and least to the middle. This is the "lost-in-the-middle" effect.
So burying a critical instruction or fact in the middle of a giant history risks it being ignored — even though you paid full price to send it.
Keep key instructions and the current task near the edges; trim the bulky middle.
Batch API for Non-Blocking Jobs
One cost lever: the Message Batches API. It is about 50% cheaper than standard requests, with up to a 24-hour processing window.
The trade-offs: there is no latency SLA, and multi-turn tool calling is NOT supported. Use custom_id to correlate requests; re-submit only the failures.
Use Batch for overnight reports and large audits. Never use it for blocking, time-sensitive, or pre-merge checks — a user is waiting on those.
batch = client.messages.batches.create(requests=[
{"custom_id": "doc-001", "params": {
"model": "claude-sonnet-4-5", "max_tokens": 1024,
"messages": [{"role": "user", "content": classify(doc_1)}]}},
{"custom_id": "doc-002", "params": {
"model": "claude-sonnet-4-5", "max_tokens": 1024,
"messages": [{"role": "user", "content": classify(doc_2)}]}},
]) # ~50% cheaper, up to 24h, no latency SLAQuick Check
A production support chatbot's per-conversation cost is climbing fast as sessions get longer, even though each user reply is short. What is the primary cause, and the right architect-grade fix?
Recap: Tokens, Context & Cost
Key takeaways:
- The API keeps no state — you resend the full
messageshistory every turn. - Billing is per token, split into input (system + tools + history) and output.
- The context window caps input + output; resent history grows toward it and cost grows roughly with the square of conversation length.
- Measure with
usageandcount_tokens; trim verbose tool output to relevant fields. - Summarize to stay in budget, but keep exact numbers/dates in a verbatim case-facts block; watch the lost-in-the-middle effect.
- Batch API = ~50% cheaper for non-blocking jobs only — never for time-sensitive checks.
常见问题解答
「令牌、上下文窗口与成本」课时是免费的吗？
是的 — 「令牌、上下文窗口与成本」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 Claude Architect 课程的其余内容，请升级到 CoddyKit PRO。 Claude Architect 课程共包含 4 节课。
「令牌、上下文窗口与成本」这节课中我会学到什么？
了解为什么每一轮都会发送完整历史记录，以及这样做的成本。 你通过在浏览器中直接运行的动手代码来练习 Claude Architect，全天候 AI 导师会在你学习这节课的过程中回答你的问题。
学习 Claude Architect 需要有经验吗？
无需任何先前经验。CoddyKit 上的 Claude Architect 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。 这是第 4 节课，共 4 节。
「令牌、上下文窗口与成本」课时需要多长时间？
大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。
我能在这节 Claude Architect 课中编写并运行代码吗？
能。每节 Claude Architect 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。
此课程中的所有课时
- Claude 模型系列
- API 请求剖析
- 停止原因详解
- 令牌、上下文窗口与成本