Extended thinking: when to turn it on and what it costs

Extended thinking is available on every text model in the catalog — from claude-opus-5-5 and the whole GPT-5.6 line to GLM 5.3 (context and vision differ between models though: Claude and GPT have 1M tokens, GLM has 128K and no vision; current list: GET https://api.zukko.pro/v1/models). Since the feature is available everywhere, it's tempting to flip it on by default for every request. In practice it isn't free in time or in cost, and for most simple requests it doesn't produce a noticeable quality difference.

How to turn it on in a request

In Anthropic-compatible mode the parameter goes in the request body to /v1/messages:

curl 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": 2048,
    "thinking": {"type": "enabled", "budget_tokens": 6000},
    "messages": [{"role": "user", "content": "Design a database schema for a marketplace with multi-vendor orders"}]
  }'

budget_tokens caps how much the model can spend on the reasoning itself before moving to the final answer — a separate budget that isn't part of the final text's max_tokens directly, but is billed the same way.

When turning it on pays off

Extended thinking helps where the answer needs several reasoning steps held in mind at once: designing a data schema under real constraints, tracking down a logical bug in an algorithm, untangling a chain of cause and effect, planning a migration with dependencies between services. On tasks like these, a model without thinking more often produces a plausible-sounding but shallow answer that doesn't hold up against the task's actual constraints.

When it's just wasted money and time

For a short factual question, simple formatting, boilerplate code against a clear spec, or an answer that fits in a couple of sentences anyway, thinking almost never changes the outcome, and it stretches out response time and adds reasoning tokens to the bill. Here it's more sensible to leave thinking off by default and turn it on selectively.

Measuring the price difference on your own requests

The most reliable approach isn't reading general advice, it's comparing the same request with and without thinking:

import requests

KEY = "fetch_your_key"
TASK = "Describe a retry mechanism architecture with exponential backoff and jitter for a task queue"

for thinking_enabled in [False, True]:
    body = {
        "model": "claude-sonnet-5",
        "max_tokens": 1500,
        "messages": [{"role": "user", "content": TASK}],
    }
    if thinking_enabled:
        body["thinking"] = {"type": "enabled", "budget_tokens": 4000}

The X-Zukko-Cost-Micros header shows the exact difference in micro-dollars between the two calls — a million micro-dollars equals one dollar. On your own task that gap might turn out to be negligible or substantial, and finding out ahead of time beats relying on general estimates from someone else's post.

Caching and thinking together

If the same thinking-enabled request repeats — say, regenerating the same analytical report — turning on caching is worth it with the X-Zukko-Cache: true header (temperature: 0 also enables the cache, but only on models that accept that parameter; Claude models — claude-sonnet-5, claude-opus-5-5 — may reject a temperature other than 1 with a 400, so don't pass it to them): then identical requests from the same user get cached for up to 7 days for chat, and a repeat call returns instantly and for free, flagged with X-Zukko-Cache: hit in the response. This only works on a fully identical request body (not "almost identical" requests and not a shared prefix), and cache hits aren't written to /v1/usage. Thinking tokens aren't recomputed in that case — the answer is simply served from cache.

Counting tokens ahead for long reasoning tasks

If the prompt for a thinking task is bulky on its own — say, it includes a large chunk of code for review — it helps to estimate its size ahead of time with the free counter:

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

That won't show thinking-token cost directly, but it tells you how much the request itself already takes up before the model starts reasoning.

Thinking doesn't replace vision or extend context

Extended thinking is about reasoning depth, not about what the model can see in an image or how much fits in the conversation. Vision and context size are properties of the model itself (Claude and GPT have 1M tokens and vision, GLM has 128K and no vision), and they don't depend on whether thinking is on — they're separate, unrelated properties. Turning thinking on hoping the model will "see an image better" or hold more context doesn't do anything: those are governed by other request parameters, while thinking only affects the quality of reasoning over data it already has.

Idempotency-Key protects your budget on thinking requests too

Since thinking tokens are billed the same way as regular ones, it's worth being more careful about automatic retries on these requests. Attach an Idempotency-Key header with a random value to each unique thinking request — if a client or agent decides to retry after a network hiccup, a repeat with the same key and the same body within 24 hours returns the already-computed answer instead of running the reasoning again and charging twice.

The practical takeaway

Turn extended thinking on selectively, for tasks that genuinely require holding several conditions in mind at once, not as a default setting across every model. The difference in price and latency between thinking on and off is easy to measure on your own example through the X-Zukko-Cost-Micros header, and that check takes less time than arguing about whether a given task needs thinking at all.