Token Usage Limits: Capping Tokens Across Claude and GPT
July 25, 2026 · 6 min read
Token usage limits are the most direct lever on LLM cost. How to bound input and output tokens across Claude and GPT — per call, per user, and per run.
Cost is denominated in tokens, so token usage limits are the most direct control you have. Everything else — spend caps, rate limits — is ultimately a way of bounding tokens. Getting the token limits right removes a whole class of bill surprises at the source.
Input tokens vs. output tokens
They behave differently and cost differently. Output tokens are typically several times more expensive per token, and they're the ones the model controls. Input tokens you control directly — they're whatever you send.
- Bound output with
max_tokenson every call. An unboundedmax_tokensis the single most common cost bug. - Bound input by trimming history, summarising old turns, and not resending context the model already has.
// Always set max_tokens — never leave output unbounded.
const res = await guard.messages.create({
model: "claude-sonnet-5",
max_tokens: 512, // hard ceiling on output cost
messages: trimHistory(messages, { maxTokens: 4000 }),
});The context-window trap
Large context windows are a convenience and a liability. Just because you *can* send 200k tokens doesn't mean you should pay for it on every turn. In chat and agent loops, resent context is the main driver of a compounding bill — see why agent costs compound.
Limits at three levels
- 01Per call —
max_tokensand a trimmed input. - 02Per user — a token budget per window, so no one user's calls add up to a fortune. See hard spend cap per user.
- 03Per run — for agents, a token ceiling on a single invocation.
Set these once and monitor them with real usage data, and token cost stops being a mystery and becomes a dial you turn.