How to actually cut token spend

Token spend rarely drops because of one clever trick. It's usually a set of smaller decisions — which model to pick, what not to put in the context, where to use caching — that add up to a real difference by the end of the month. Here's what actually works, based on features that exist in the gateway today.

Match the model to the task instead of defaulting to one

The catalog currently has six models at different prices (per 1M tokens, input/output): claude-opus-5-5, claude-sonnet-5 and gpt-5.6-sol at $0.30/$0.30, gpt-5.6-luna and glm-5.3 at $0.10/$0.10, and glm-5.3-flash at $0.04/$0.04; the cheaper ones are the natural first try for simple, high-frequency calls like classification or short rewrites — test which one handles your tasks. Running the most expensive model on routine work that doesn't need it is the most direct way to overpay. Current model list: GET https://api.zukko.pro/v1/models; prices and limits:

curl https://api.zukko.pro/v1/models/info

Count tokens before sending, not after the bill arrives

The /v1/messages/count_tokens method is free and doesn't execute the request — it only counts:

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-sonnet-5","messages":[{"role":"user","content":"<draft prompt>"}]}'

If a prompt is assembled programmatically from templates and attachments, checking its size at this step is worth doing before the monthly total has already grown, not after.

Use the cache for repeated requests

If part of your traffic is repetitive — the same classifications, template checks, or repeated questions against the same piece of content — turn the cache on explicitly with X-Zukko-Cache: true (temperature: 0 also enables it, but only on models that accept it — Claude models may reject a temperature other than 1). A fully identical request (the whole body matches) from the same user, repeated within 7 days for chat, comes back instantly and free, flagged with X-Zukko-Cache: hit in the response. This is especially useful for pipelines where the same data gets checked several times a day.

Don't let context balloon unnecessarily

This is the most common reason agent workloads end up with a surprisingly high bill. A few concrete rules:

• don't pass a whole file when you only need one piece — read and paste only the relevant part;
• trim conversation history down to what's actually needed at each step, instead of resending all of it out of inertia;
• don't duplicate the same information in both the system prompt and the user message.

Every extra thousand tokens in a system prompt gets multiplied by the number of agent steps — this is the piece of spend that's easiest to overlook, precisely because it sits in the background and doesn't look like a large variable cost.

Don't inflate max_tokens "just in case"

max_tokens is a generation ceiling, not a guaranteed length, but some models tend to fill it, especially when the task's phrasing leaves room for a verbose answer. If the answer should genuinely be short — a classification, a yes/no, a small JSON object — set a realistic limit instead of a large round number for safety.

Set key limits instead of relying on discipline

Every API key can have a daily and monthly dollar spend limit and a list of allowed models, configured in the cabinet on the key's page. This isn't mainly about saving money in the moment — it's protection against the scenario where a runaway agent or a retry bug quietly drains the balance overnight. A separate key with a hard limit for experiments and draft runs is cheaper than dealing with the aftermath.

Use idempotency on retries

If your code or library retries requests on network errors, attach an Idempotency-Key header with the same value for every attempt at the same logical action — unique per logical request and set on the specific call, not in the client's default headers (otherwise the next request gets a 422 idempotency_conflict). A retry with the same key within 24 hours returns the stored response without charging again — without this header, every retry after a response that actually went through but wasn't received by the client becomes a separate paid request.

Watch actual spend, not estimates

Every regular (non-streaming) response carries an X-Zukko-Cost-Micros header — the cost of that specific request in microdollars — and X-Fetch-Balance-Cents, the balance remaining after the charge (despite the name, also in microdollars: 1,000,000 = $1; the exact balance in cents is GET /v1/balance, field balance_cents). Streaming responses (stream: true) don't carry these headers. Logging those two fields into your own monitoring gives an exact picture without extra API calls. For a summary over a period, /v1/usage with cursor pagination is there — useful for building a report by day; its history covers the whole account with no per-key filter, so do per-project breakdowns from your own X-Zukko-Cost-Micros logs (for non-streaming requests).

Revisit system prompts every so often

A system prompt written at the start of a project often keeps running unchanged for months, even after part of its instructions are no longer needed — the task changed, requirements got simpler, some examples became redundant. Since the system prompt gets resent on every request, and in an agent loop on every step, leftover paragraphs in it cost more than they look like they do. Rereading the system prompt every few weeks and cutting whatever's stopped being necessary isn't a one-time optimization — it's the same kind of routine maintenance as cleaning up dependencies in code.

The bottom line

None of these on its own produces a dramatic drop in spend. The right model saves on volume of calls, caching saves on repeats, a disciplined context saves on the size of each request, key limits save on risk, and idempotency saves on retries. Together they add up to a difference that shows up within the first week of real traffic.