tokenguardrail_
early access

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_tokens on every call. An unbounded max_tokens is 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

  1. 01Per callmax_tokens and a trimmed input.
  2. 02Per user — a token budget per window, so no one user's calls add up to a fortune. See hard spend cap per user.
  3. 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.

// get started

Stop finding out from the invoice.

// keep reading