Tokens, Janelas de Contexto e Custo

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.

A Claude API request has a few key fields:

• model — which Claude model to use
• max_tokens — the cap on the reply length
• system — the system prompt
• messages — the FULL history every turn
• tools / 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.

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.

Every request has two token counts that are billed differently:

• Input tokens — everything you send: system + tools + the full messages history.
• 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 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.

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.

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.

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.

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.

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.

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.

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?

Key takeaways:

• The API keeps no state — you resend the full messages history 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 usage and count_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.