Orchestration Tuning Is the New Retainer Line
The short version: on September 11, 2026 Sakana shipped Fugu Max and Fugu Ultra v2, the first orchestration product sold as a standard API-compatible endpoint — $2.00 per 1M input tokens, $6.00 per 1M output tokens, $0.25 cached input — with the routing decision itself metered. That makes the buyer's cost a routing policy rather than a token price, and it creates an agency service line that is not “which model should we use”: orchestration tuning. The arithmetic is why it is billable. On the fixed 10,000-task workload worked on the three-layer cost page, an untuned mid-weight router costs $404.30 a month against $376.00 for calling one frontier model on every task — the orchestration layer is its own $95.00 monthly line item while the rate-card advantage it exists to route to capture is worth $48.00. A router is not an upgrade you buy. It is a policy you tune, and the tuning is the retainer.
This page is the agency-side counterpart to that arithmetic: what the engagement delivers in client terms, what has to be scoped before it can be quoted, what gets measured to prove the saving, and the conditions under which we tell a client not to buy it.
1. What changed: the routing decision became a priced layer
Until this launch, a cost-per-task model had two layers — the model's tokens and the tools it called. Fugu Max adds a third by selling the decision of which model to call as a metered API SKU: you send a normal chat completion and the product chooses the model in its pool. Sakana describes the policy as routing each task to “the leanest model capable of solving them” (sakana.ai/fugu-max-release/).
What matters commercially is not the rate card but the meter. Sakana's own console states that orchestration tokens “represent real token usage outside of the input and output tokens and will be counted in the final price of the request. The price will be the same as standard input and output tokens” (console.sakana.ai/pricing). The usage fields are exposed as orchestration_input_tokens, orchestration_input_cached_tokens and orchestration_output_tokens. The counter-mechanic, from the same page: “Multiple agents — We never stack model fees. You are charged a single rate based on the top tier model involved.”
Forkast named the consequence on the same day, in an analysis piece by Lena Park: value migrates “away from the model providers and toward the orchestrators”, and “value is increasingly captured by those who control the traffic” (forkast.news). That is commentary, not measurement — and the arithmetic on the calculator page shows exactly when it holds and when it does not.
| Fugu Max rate card (retrieved 2026-09-11) | Published rate | Source |
|---|---|---|
| Input | $2.00 / 1M tokens | console.sakana.ai/pricing · OpenRouter models API |
| Output | $6.00 / 1M tokens | same two surfaces |
| Cached input | $0.25 / 1M tokens | same two surfaces |
| web_search / web_fetch, per call | $0.007 | console.sakana.ai/pricing |
| Context window / max output | 1,000,000 / 128,000 — OpenRouter's figures only; Sakana publishes no context window for Fugu Max | OpenRouter models API |
| Orchestration tokens | Billed at the same standard input/output rates and counted in the final price | console.sakana.ai/pricing |
2. What “orchestration tuning” is — and what it is not
It is not model selection. “Which model should we use” is a recommendation, and recommendations are one-off work. A routing policy is a live artefact: it decides which task classes are allowed to leave the expensive tier, what happens when a task is misrouted, how many tokens the router may spend deciding, and how anyone knows the cheaper leg is still correct. That is what a retainer pays for, because the policy decays — rates change, task mixes drift, and every policy change can silently move quality.
The engagement delivers four artefacts, all in client terms:
- Routing policy design. A written task-class → tier map stating which classes route down and which stay on the frontier model, the fallback and retry rules when a routed-down task fails its check, the output-token ceiling per class, and a routing prompt whose own token weight is measured rather than assumed.
- Evaluation harness. A labelled set per task class, a pass/fail checker for the checkable share, and a regression gate that runs on every policy change. The eval pass rate on the routed-down leg is a guardrail, not a report: the policy does not ship if it drops below the pre-tuning baseline.
- Cost-per-task baseline. Pre-tuning metering of tokens per finished task per class — input, cached input, output, tool calls, retries and orchestration tokens if a router is already in place — with the baseline model and its rate card named.
- Post-tuning proof. The same measurement re-run over the agreed window, reported as cost per completed task and as a net figure after the orchestration layer's own tokens are subtracted, alongside the routing accuracy and retry rate actually observed against target.
Cost per token is not cost per completed task. OrcaRouter's working conclusion — “orchestration saves money when it prevents retries, not when it adds parallelism for its own sake” (orcarouter.ai) — is the entire justification for a retainer that measures tokens per finished task rather than tokens per call.
3. What to scope before the engagement can be quoted
Five parameters set both the price and the arithmetic. They are also the first five questions in any discovery call.
| Scoping parameter | What we ask for | Why it decides the answer |
|---|---|---|
| Task classes | How many distinct task classes run today, and which have an automatic pass/fail checker | Each class needs its own routing rule and its own eval set. A class with no checker cannot be safely routed down, so it stays on the expensive tier — which shrinks the routable share that pays for everything. |
| Traffic volume band | Tasks per month, order of magnitude | The prize scales with volume. Routing one task down from the $2.00/$10.00 frontier card to a $1.26/$3.96 cheap card is worth $0.01154 per task — $115.40 a month at 10,000 tasks, $11.54 at 1,000. Below a certain volume the layer and the retainer cost more than the gap. |
| Target routing accuracy | A per-class target, e.g. 95% | Accuracy sets the retry budget. On the worked workload, accuracy moves the monthly bill by $49.87 between 70% and 100% — and every accuracy row, including a flawless router, still sits above the single-frontier baseline at a mid-weight router. |
| Tool-call inventory | Calls per task, per-call fee, tool-result tokens re-sent on each call | Tools are billed on every retry. On the worked workload the tool layer is $140.00 a month — 37% of the frontier baseline — and each retried task duplicates it in full. |
| Measurement window | A baseline window and a tuned window, both covering a full traffic cycle | A router tuned on one week of tickets is not a routing policy. The window is also what makes the proof auditable rather than anecdotal. |
Everything else is discovered inside the engagement, because no vendor publishes it: routing accuracy, router token spend and cache-hit rate are all unpublished by every vendor in this market. The harness exists to produce those three numbers for the client's own traffic.
4. The measurement plan: how the saving is proved
The proof is a before-and-after on the same task classes, measured in cost per completed task, with a quality guardrail so a cheaper bill cannot be bought with quietly worse output.
| Metric | Definition | How it is captured |
|---|---|---|
| Cost per completed task | All spend — model, tools and orchestration tokens — divided by the tasks that passed their checker | Provider usage records including the orchestration token fields, plus the tool-call log; reported per task class, before and after |
| Routing accuracy | Share of tasks the router sent to a tier that passed on the first pass, and the misroute rate | Labelled eval set, then production sampling over the measurement window |
| Eval pass rate (guardrail) | Share of the labelled set passing its class checker while running on the cheaper leg | Harness regression run on every policy change; must not fall below the pre-tuning baseline |
| Orchestration token spend (O) | The router's own input and output tokens, priced at standard rates | Provider usage fields — the number that decides the case, and the one no vendor publishes on a rate card |
| Retry rate (R) | Extra passes caused by a misroute, each priced as a full run on the frontier tier plus its tools | Run logs, counted per class |
| Routable share used (p) | Share of traffic actually sent down and staying down | Routing logs; must exceed the break-even share p* to be worth anything |
| Net saving | (baseline cost per completed task − tuned cost per completed task) × volume − orchestration layer cost | Computed from the first and fourth rows. This is the only number we report as a saving — never a rate-card percentage. |
The three-way comparison the proof has to win
All three columns are the same 10,000-task workload (4,000 input and 1,200 output tokens per task, two tool calls, 900 tool-result tokens re-sent per call, 5,800 billed input tokens per task), modelled on published rate cards by the three-layer cost page:
| Configuration | Monthly cost | Cost per task | vs single frontier model |
|---|---|---|---|
| (a) One frontier model on every task (Claude Sonnet 5 card, $2.00/$10.00) | $376.00 | $0.0376 | baseline |
| (b) A cheap model on every task (GLM-5.3, $1.26/$3.96) — a floor, not a plan | $260.60 | $0.0261 | −$115.40 |
| (c1) Untuned mid-weight Fugu Max router over the cheap model | $404.30 | $0.0404 | +$28.30 |
| (c1′) Tuned router, light profile (modelled: 1,300/120 orchestration tokens per task) | $342.50 | $0.0343 | −$33.50 |
The untuned middle column is the one to show a client first, because it is the default state: the layer costs $95.00 a month and the rate-card advantage it routes to capture is $48.00. The tuning levers follow directly from the break-even formula, p* = (O + R) / (N × delta), where O is the orchestration tokens in dollars per month, R the retry cost, N the tasks per month and delta the per-task saving from routing a task down ($0.01154 here):
- Cut the router's own weight (O). On this workload O is the deciding term. The mid profile spends 4,300 input and 150 output tokens per task deciding — $95.00 a month — against a per-task headroom of $0.01154, i.e. about 5,770 Fugu Max input tokens per task. The light profile, a classification call on a compressed 1,000-token routing view, spends $33.20 and drops p* to 28.77%, which is what turns the same traffic into a $33.50 saving instead of a $28.30 loss. Nothing else on this page moves the answer as much as the router's own token spend, and no vendor prints it on a rate card.
- Raise the routable share actually used (p). The mid profile needs 82.32% of traffic routed down (88.02% with retries) against the 65.0% this workload offers — which is why accuracy alone cannot rescue a heavy router. Tuning widens the share that may route down legitimately: more task classes with checkers, tighter output ceilings, and a fallback rule that does not re-run the frontier model for recoverable failures.
- Choose the baseline deliberately. The same router needs only 20.24% of traffic routed down against Claude Opus 5 ($5.00/$25.00) and 40.70% against Kimi K3 at Moonshot's list rate ($3.00/$15.00). Against Kimi K3 on OpenRouter's effective rate ($1.7955/$9.006) p* is 103.70% — arithmetically impossible, because the two cards are too close for a router to take a cut in between. Orchestration is worth most against the worst-priced baseline.
Read the light-profile row for what it is: a modelled scenario on published rate cards, with the router profiles taken from the calculator page's sensitivity table, not a measured result from any client account — the whole point of the engagement is that the client's own O, R and p replace these assumptions.
5. The counter-evidence, stated plainly
A service page that only quotes the friendly number is not a service page. Two published facts cut against orchestration as a default:
- The orchestrator's rate card can lose on price alone. GLM-5.3 lists at $1.26 input and $3.96 output per 1M — cheaper than Fugu Max on both axes (orcarouter.ai/blog/fugu-max-vs-glm-5-3). On a 1M-input + 200K-output example, Fugu Max costs $3.20 against GLM-5.3's $2.05, i.e. 55.9% more. If the baseline is already that cheap, there is little left to route away from.
- The 40–60% saving is the vendor's own sentence, not an independent finding. Sakana's release page states it; it reproduces on the output axis only, against named baselines — 40.0% versus Sonnet 5 and 60.0% versus Kimi K3 at Moonshot's list rate of $15.00/1M. Against Kimi K3 on OpenRouter's listed/effective $9.006/1M the output gap falls to 33.4%, and on the input side the claim does not hold as a range at all (0% against Sonnet 5 and GPT 5.6 Terra, 33.3% against Kimi K3 at list, −11.4% against Kimi K3 on OpenRouter). OrcaRouter, a competing gateway that sells Kimi K3 at 0% markup, reproduces the 60% figure against the list rate while disputing the framing — so it is neither vendor marketing nor clean third-party confirmation.
Three further gaps any honest tuning engagement has to carry: no independent evaluation of Fugu Max exists (no Artificial Analysis page for any Fugu model, per OrcaRouter) and Sakana's benchmark wins are unquantified rank statements; no latency or throughput is published for Fugu Max, so wall-clock cannot be modelled from public data; and the cache-hit rate is undisclosed, with OpenRouter reporting supports_implicit_caching: false for the endpoint — which is why the harness models no caching credit until it can measure one.
6. When we tell a client not to buy the engagement
- The baseline model is already a cheap one (a GLM-5.3-class card), so the delta a router can capture is thinner than the router's own token spend.
- Fewer than roughly half of tasks have an automatic pass/fail checker: unverifiable work cannot be routed down safely, so p stays below p*.
- Volume is too low for delta × N to cover both the orchestration layer and the retainer.
- Retries are not the problem. OrcaRouter's condition is the right one to sell against: orchestration pays when it prevents retries, not when it adds a parallel pass for its own sake.
7. Nine discovery questions to scope your own engagement
- How many distinct task classes run today, and which of them have an automatic pass/fail checker?
- What share of today's traffic would you expect to pass on a cheaper model — and what evidence exists for that share?
- What is the baseline model, at exactly which rate card, and is it the card you think it is?
- What is your current cost per completed task — not cost per token?
- What is your retry rate today, and what triggers a retry?
- How many tools does a typical task call, what does each call cost, and how many tool-result tokens are re-sent on every call?
- What is the output-token ceiling per task class, agreed in advance?
- What does your router spend on its own tokens per task, and does your provider expose it as a usage field?
- What measurement window will the proof cover, and who signs off on the quality guardrail?
If the last two questions cannot be answered, the engagement is not ready to be scoped — because those two are exactly what separates a tuning retainer from a model recommendation that nobody can audit.
8. The arithmetic lives on one page — link it, don't copy it
Every figure in this piece is recomputable on The Three-Layer AI Bill: Model + Tools + Orchestration, Worked: the fixed workload, the routing premium decomposed into orchestration tokens ($95.00), frontier-rate traffic ($42.12) and retries ($6.58), the break-even derivation with substitutions, the four router profiles and the accuracy and routable-share sensitivity grids. It is generated from a single source-of-truth model and independently recomputed cell by cell, and vendor rates change — so we link to it rather than restating numbers that will drift.
Run your own traffic through all three layers before you price anything
Open the three-layer cost page →Or compare vetted AI agencies if you would rather have the policy designed and measured for you.
Frequently asked questions
What is orchestration tuning?
Orchestration tuning is the work of designing, instrumenting and proving the routing policy that decides which model answers each task — as distinct from model selection, which is a one-off recommendation. The deliverables are a written task-class-to-tier routing policy with fallback and retry rules, an evaluation harness with a pass/fail checker per task class, a cost-per-completed-task baseline measured before tuning, and a post-tuning proof re-measured over an agreed window and reported net of the orchestration layer's own token spend.
How do you prove an orchestration tuning engagement saved money?
By metering cost per completed task — total spend including orchestration tokens and tool calls, divided by tasks that passed their checker — before and after tuning, on the same task classes. The saving is reported net: baseline cost per completed task minus tuned cost per completed task, times volume, minus the orchestration layer's own token cost. Quality is held by a guardrail: the evaluation pass rate on the routed-down leg must not fall below baseline, and routing accuracy and retry rate are reported alongside the cost figure so a cheaper bill cannot be bought with silently worse output.
Is orchestration cheaper than calling one frontier model?
Not automatically. On the worked 10,000-task workload modelled on the published rate cards, a mid-weight Fugu Max router comes to $404.30 a month against $376.00 for calling one frontier model on every task, because the orchestration layer is metered at $95.00 a month while the rate-card advantage it routes to capture is worth $48.00. Break-even is p* = (O + R) / (N × delta): 82.32% of traffic must route down, 88.02% once retries are counted, against the 65.0% this workload offers. A lighter router profile wins on the same workload at $342.50 against $376.00, and orchestration wins easily against an expensive baseline — 20.24% of traffic routed down against Claude Opus 5, 40.70% against Kimi K3 at list. Whether it is cheaper is an arithmetic question about your traffic, not a property of the product.
What do you need from a client to scope an orchestration tuning engagement?
Five parameters: the number of distinct task classes and which of them have an automatic pass/fail checker; the traffic volume band in tasks per month; the target routing accuracy per class; the tool-call inventory including per-call fees and the tool-result tokens re-sent on each call; and the measurement window for the baseline and the tuned run. Everything else — routable share, router token spend, retry rate, baseline model and output-token ceiling per task — is discovered inside the engagement, because no vendor publishes routing accuracy or router token counts.
When is orchestration tuning not worth buying?
When the baseline model is already a cheap one: GLM-5.3 lists at $1.26 input and $3.96 output per 1M, and on a 1M-input-plus-200K-output example Fugu Max costs $3.20 against GLM-5.3's $2.05 — 55.9% more, against a card that is cheaper on both axes. Also when a meaningful share of tasks has no pass/fail checker, because an unverifiable task cannot be safely routed down; when volume is too low for the per-task delta to cover both the retainer and the layer; and when retries are not the problem, since orchestration saves money when it prevents retries, not when it adds parallelism for its own sake.
Sources
- Sakana AI console rate card — Fugu Max $2.00/$6.00/$0.25, Fugu Ultra v2 $5.00/$30.00/$0.50 (rising to $10.00/$45.00/$1.00 above a 272K-token context), $0.007 per web call, and the orchestration-token billing paragraph: console.sakana.ai/pricing (retrieved 2026-09-11)
- Sakana AI release — launch date September 11, 2026, public model names, the vendor's own 40–60% sentence, and the “leanest model capable of solving them” description of the routing policy: sakana.ai/fugu-max-release/ (retrieved 2026-09-11)
- OpenRouter models API — Fugu Max and Fugu Ultra v2 listings, the 1,000,000-token context and 128,000-token output ceiling, and the baseline rates used here (Claude Sonnet 5 $2.00/$10.00, GPT 5.6 Terra $2.00/$12.00, Claude Opus 5 $5.00/$25.00): openrouter.ai/api/v1/models (retrieved 2026-09-11)
- OpenRouter model page and endpoints API — Kimi K3 listed/effective rates ($1.7955/$9.006) and
supports_implicit_caching: false: openrouter.ai/moonshotai/kimi-k3 (retrieved 2026-09-11) - OrcaRouter — Kimi K3 Moonshot list rate ($3.00/$15.00/$0.30), the 33%/60% decomposition, the competing-gateway caveat and the statement that no Artificial Analysis page exists for any Fugu model: orcarouter.ai/blog/fugu-max-vs-kimi-k3 (retrieved 2026-09-11)
- OrcaRouter — GLM-5.3 at $1.26/$3.96, the worked 1M+200K comparison, and the “saves money when it prevents retries” conclusion: orcarouter.ai/blog/fugu-max-vs-glm-5-3 (retrieved 2026-09-11)
- Kimi K3 list rate with explicit 0%-markup language: orcarouter.ai/models/kimi/kimi-k3 (retrieved 2026-09-11)
- Forkast — “The Orchestration Arbitrage: How Sakana's Fugu Max Rewrites the Pricing War”, analysis by Lena Park, published 2026-09-11 2:45 PM UTC (quoted as commentary, not measurement): forkast.news (retrieved 2026-09-11)
- The three-layer cost model, the routing premium decomposition, the break-even derivation and the router-profile sensitivity table used throughout this page: aiagencycalculator.com/orchestration-cost-layer/ (retrieved 2026-09-11)
Accuracy note: every rate on this page is a published rate with a source and a 2026-09-11 retrieval date. The workload, the routable share, the routing accuracy and the router token profiles are modelled assumptions carried from the three-layer cost model, not measurements of any client account, and they are labelled as modelled wherever they appear. Three of them are unpublished by every vendor in this market — routing accuracy, router token spend and cache-hit rate — which is why the engagement measures them rather than assuming them. No independent evaluation of Fugu Max exists and its six “best overall” benchmark statements carry no values or margins, so no benchmark score is reproduced here. The 1,000,000-token context and 128,000-token output figures are OpenRouter's, not the vendor's. The 40–60% saving is Sakana's own claim, reproducible on the output axis only and only against the baselines named above. Re-verify rates before building a client proposal on them.