What a very long context actually costs you

The Claude and GPT models in the catalog — claude-opus-5-5, claude-sonnet-5, gpt-5.6-sol and gpt-5.6-luna — support a 1,000,000-token context; glm-5.3 and glm-5.3-flash have 128K (current list: GET https://api.zukko.pro/v1/models). That's a large window, and the temptation to use all of it — dump the whole repository or the entire conversation history into the prompt — is understandable. But the cost isn't only measured in dollars, and it's worth understanding before your context grows on its own.

Direct cost: it scales linearly with size

Input tokens are billed per token sent, regardless of whether the model actually used all of that information. A 400,000-token prompt costs four times what a 100,000-token prompt costs, even if the model only needed the last thousand lines to answer. In agent loops, where the entire accumulated history gets resent at every step, this compounds across steps — the context grows, and each subsequent call costs more than the last simply because it drags along everything that came before. Keep a pricing detail in mind too: vendors charge about 10% of the input price for prompt-cache reads, while Zukko bills cached tokens at the normal input rate — so for agents with a large repeated context the real gap versus official pricing is smaller than a head-to-head price comparison suggests.

You can check the actual cost of a specific request from the response header:

curl -i https://api.zukko.pro/v1/messages \
  -H "Authorization: Bearer fetch_your_key" \
  -H "Content-Type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model":"claude-opus-5-5","max_tokens":500,"messages":[...]}' \
  | grep -i x-zukko-cost-micros

And you can size a context before sending the whole thing, with free token counting:

curl https://api.zukko.pro/v1/messages/count_tokens \
  -H "Authorization: Bearer fetch_your_key" \
  -H "Content-Type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model":"claude-opus-5-5","messages":[{"role":"user","content":"<full context>"}]}'

Key limits burn through faster

If a key has a daily or monthly dollar spend limit — configurable in the cabinet on the key's page — a long context eats through that limit noticeably faster than short requests do. An agent that resends 200,000-300,000 tokens on every step can hit key_daily_limit_reached in the middle of a working day, simply because the limit was sized for average load, not for dense work with large files.

Worth remembering here too: key_monthly_limit_reached follows the same logic on a monthly horizon, and doesn't reset immediately.

The cache doesn't always save you

Response caching kicks in with an X-Zukko-Cache: true header (temperature: 0 also enables it, but only on models that accept it — Claude models may reject a temperature other than 1), and a repeated identical request from the same user comes back instantly and free, with X-Zukko-Cache: hit in the response. For chat, the cache lives for up to 7 days. The key word is identical: if even one token changes in a long context — and in an agent loop it almost always does, since a new history step gets appended — the cache won't fire. Don't rely on the cache to solve the cost of a growing, dynamic context; it helps with repeated static requests, not an expanding conversation history.

Risk of dropped responses and rate limits

A large context increases request processing time. If the client or network is configured with a short timeout, a long request can cut off mid-response — that's almost always a client timeout, not a token cap, and it's fixed by raising the HTTP client's timeout and setting a sane max_tokens, not by switching models. Separately: there's no general rate limit on the gateway — a 429 from Zukko only means key_daily_limit_reached or key_monthly_limit_reached, and any other 429 comes from the model provider.

Splitting into steps instead of one giant request

Being able to send a million tokens doesn't mean a task should be solved in one call. When analyzing a large repository or a long document, it's often cheaper and more reliable to break the work into several steps with a smaller context each: first pass over a table of contents or file list, pick the relevant parts, and only send those for detailed analysis. The total token count can end up comparable, but you drop the risk of paying for one enormous failed request if something goes wrong partway through — a cut-off response, or the model misreading the task. Each smaller step can be checked ahead of time with count_tokens, and you can decide whether it's even needed before assembling everything into one giant call.

What to actually do about it

Don't pull whole files when you need a fragment. Especially in agent file-reading tools: reading a 5,000-line file in full for one function means thousands of wasted input tokens on every step.

Trim conversation history. Early messages in a session are often no longer relevant to the current step, but keep getting resent purely out of implementation inertia.

Count tokens ahead of time for expensive requests. /v1/messages/count_tokens is free precisely so you don't pay to find out the size the hard way.

Match models to steps. For steps that don't genuinely need a million-token context, glm-5.3-flash ($0.04/$0.04 per 1M) or gpt-5.6-luna ($0.10/$0.10) will do the job cheaper than routing everything through claude-opus-5-5 ($0.30/$0.30).

Size key limits realistically. If you know the workload involves large contexts, set the daily and monthly limits with headroom rather than by an average guess — otherwise the agent hits key_daily_limit_reached at an inconvenient moment.

A million tokens of context is a capability that lets you solve problems that used to require manual chunking, not an invitation to send everything indiscriminately. Price, key limits, and connection stability all respond to request size the same way, and all three are worth keeping in mind at once.