Fugu Orchestration Tokens: The Hidden Line on Your Bill

If your Fugu Ultra bill looks higher than the tokens you can count, nothing is broken. You’ve met orchestration tokens — the usage Fugu’s internal agents consume while working on your request. Sakana bills them at full standard rates, most cost estimates ignore them, and no response-length cap can contain them. This guide explains the mechanism, shows you exactly where the numbers live in the API response, and covers the cost controls that actually work.

The usage object, explained

Every Fugu Ultra response includes a usage object. On most OpenAI-compatible APIs, the token detail fields are informational — nice to know, not billed separately. On Fugu Ultra and Fugu Cyber, three of them are money. Here’s the shape, with illustrative numbers:

"usage": {
  "input_tokens": 2000,          // your visible prompt
  "input_tokens_details": {
    "orchestration_input_tokens": 3100,        // BILLED: internal agents' input
    "orchestration_input_cached_tokens": 1400  // BILLED: at the cached rate
  },
  "output_tokens": 800,          // the visible answer
  "output_tokens_details": {
    "orchestration_output_tokens": 1900        // BILLED: internal agents' output
  },
  "total_tokens": 7800           // includes ALL of the above
}

Read the asymmetry carefully. In this example, your visible traffic is 2,800 tokens — but total_tokens is 7,800. The other 5,000 tokens are the orchestrator’s own work: routing decisions, inter-agent messages, verification passes. Sakana’s pricing page states these “represent real token usage outside of the input and output tokens and will be counted in the final price of the request,” priced the same as standard input and output tokens.

Why Fugu bills these when others don’t

If you’re used to OpenAI-style APIs, token “details” fields read as diagnostics — reasoning-token counts you can inspect but that are already folded into a single advertised price. Fugu’s economics are different because the architecture is different: when you send one request to Fugu Ultra, between one and three expert agents may actually process it, coordinated by an orchestrator that reads, writes, and verifies along the way. That internal conversation runs on the same pool of frontier models your answer does. It has real compute cost, so Sakana meters it as real usage rather than hiding it in a higher headline rate.

The honest way to think about Fugu Ultra’s advertised rates: $5 in / $30 out (as of August 2026) is the metering unit, not the request price. The request price is that rate applied to everything the system used — visible and internal. Sakana publishes no fixed overhead ratio, and none could exist: how much internal work a request triggers depends on the task, which is exactly why the usage object reports it per response.

Why output caps don’t cap your costs

Here’s the trap that catches engineers who’ve built cost guards for other APIs. Setting max_output_tokens (or max_completion_tokens) on a Fugu Ultra request caps only the final visible response. The orchestrator still uses its own internal maximum for its own work. Sakana documents this directly — which means a per-request hard cost cap is not achievable with request parameters alone.

A related surprise: several familiar parameters are accepted but ignored (temperature, top_p, stop, seed, frequency_penalty, presence_penalty). Your cost-control toolbox on Fugu is genuinely different from other APIs — it’s the tactics below, not the request knobs.

How this plays across the Sakana lineup

The orchestration usage fields are documented for Fugu Ultra and Fugu Cyber — the models where internal multi-agent work is the product. On both, total_tokens includes the orchestration lines, so any dashboard or budget you build on total tokens is automatically counting the real bill.

Base Fugu handles the same economics differently: instead of itemized overhead, you pay a single rate set by the top-tier underlying model involved in your request, fees never stacked. Simpler to read, harder to predict — the rate itself varies with routing.

Sakana Namazu, the separate Japanese-specialized model, has no orchestration layer at all — but its built-in tools create an analogous effect: each internal tool-loop call re-sends the full conversation as input tokens (mostly at the cached rate for the shared prefix). Different mechanism, same lesson: on Sakana’s platform, read the usage object, not the rate card.

Estimating real costs before you commit

Since overhead varies, estimate in two steps. First price your visible traffic from the rate table. Then apply an overhead multiplier as a planning assumption and treat it as a range: our cost calculator defaults to 150% overhead (i.e., internal usage adding 1.5× your visible tokens at the same rates) with a slider from 0–300%, so you can bracket optimistic and pessimistic cases. Run a pilot batch, read the real ratios from your usage objects, then re-plan with your own numbers.

Reading your usage, request by request

The per-request audit is simple arithmetic on the usage object. Billed input is input_tokens plus orchestration_input_tokens (with the cached portion at the cached rate); billed output is output_tokens plus orchestration_output_tokens. A logging snippet like this keeps a running overhead ratio:

u = resp.usage
visible = u.input_tokens + u.output_tokens
orch = (u.input_tokens_details.orchestration_input_tokens
        + u.input_tokens_details.orchestration_input_cached_tokens
        + u.output_tokens_details.orchestration_output_tokens)
print(f"overhead: {orch / visible:.0%}  total billed: {u.total_tokens}")

Track that percentage per task type. Simple extraction jobs and hard multi-step reasoning will show very different ratios, and knowing yours turns Fugu billing from a surprise into a forecast.

A complete worked example

Take the usage object from the top of this article and price it at Fugu Ultra’s standard rates ($5 input / $30 output / $0.50 cached per million, as of August 2026):

Line item	Tokens	Rate /1M	Cost
Your prompt	2,000	$5.00	$0.0100
Orchestration input	3,100	$5.00	$0.0155
Orchestration input (cached)	1,400	$0.50	$0.0007
Visible answer	800	$30.00	$0.0240
Orchestration output	1,900	$30.00	$0.0570
Total	9,200	—	$0.1072

Two readings of that table matter. First, the naive estimate — pricing only the visible 2,800 tokens — comes to $0.034, barely a third of the real charge. Second, look at where the money went: orchestration output is the single largest line. Internal agents write a lot — plans, drafts, critiques — and they write at the $30 rate. That’s the structural reason Fugu Ultra bills confound people who budgeted from the rate card.

Note also what the cache did: 1,400 of the orchestration input tokens billed at $0.50 instead of $5.00, saving about $0.0063 on this one request. Across a month of requests sharing the same system prompt and context, that line is where disciplined prompt structure pays for itself.

The numbers above are an illustration — your ratios will differ by task. The method doesn’t: price every line of the usage object, not just the two you control.

Cost controls that actually work

1. Engineer for the cache. Cached input bills at $0.50 instead of $5 per million (as of August 2026) — and the discount applies to orchestration input too, via orchestration_input_cached_tokens. Keep system prompts and shared context stable so the prefix cache can do its work.
2. Default to base Fugu. The fugu model balances cost and latency and bills at the underlying model’s rate, never stacked. Send only genuinely hard problems to fugu-ultra. Our pillar guide covers when each is the right tool.
3. Tune reasoning effort. The API accepts effort levels high, xhigh, and max. Lower effort means less internal work. (Note: per Sakana’s get-started documentation, max is a distinct top level only on fugu-ultra-v1.1; elsewhere it maps to xhigh. Sakana’s own pages were inconsistent on this detail as of August 2026 — we follow the get-started/catalog version.)
4. Trim what you send. Every input token you delete also shrinks the base on which orchestration overhead accrues — and keeps you clear of the >272K context tier, where all rates jump.
5. Consider a subscription for human-in-the-loop use. For interactive work, the $20–$200 monthly plans convert unpredictable per-token math into a flat fee that includes both Fugu and Fugu Ultra.
6. Alert on ratios, not totals. A budget alarm on total spend tells you too late. An alarm on the overhead ratio per task type catches routing changes and prompt regressions the day they happen.

The multi-turn resend tax

One more documented behavior compounds everything above in conversations. Fugu’s Responses API does not accept previous_response_id — there is no server-side conversation state to point at. Every turn, you resend the full history in input.

Cost-wise, that means a conversation’s input grows with every exchange: by turn ten, you’re paying input rates on nine turns of history plus the new message — and orchestration overhead accrues on top of that larger base. Two mitigations follow directly. First, the cache again: an unchanged conversation prefix is exactly what prompt caches serve best, so in a well-behaved client most of that history bills at $0.50 per million instead of $5. Second, conversation hygiene: long-running sessions deserve summarization or truncation strategies, because on Fugu an unbounded chat log is an unbounded input bill.

If you’re coming from an API with server-side conversation state, audit your client’s history handling before pointing it at Fugu Ultra — it’s the quietest source of surprise spend we know of.

Budgeting when requests can’t be capped

If per-request costs can’t be hard-capped, contain them one level up. Three patterns work in practice.

Cap the credit pool, not the request. Pay-as-you-go runs on prepaid credits, so your worst case is bounded by what you’ve loaded. Keep the balance sized to a period of spend you’d be willing to lose to a bug — a runaway retry loop on Fugu Ultra is the failure mode to design against, so make sure your client retries with backoff and a ceiling.

Meter at the gateway. If requests flow through your own service, track cumulative billed tokens from each response’s usage object and shut the lane when a daily budget trips. Because the usage object arrives with every response, your meter is always at most one request behind reality — on Fugu, that lag is your actual exposure, so size single requests (prompt length, effort level) with it in mind.

Test through a limited third-party key. For evaluation, a credit-limited OpenRouter key gives you a hard external stop — that’s the setup our playground is built around, and it’s the closest thing to a per-session spending cap that exists for Fugu Ultra today.

Next: put your own numbers into the cost calculator, or see how these mechanics fit into Fugu’s full pricing picture.