Sakana Fugu Max pricing: every rate, and what it really costs

Sakana Fugu Max pricing: the full rate card

Here is the complete pay-as-you-go picture for the model, straight from Sakana's FAQ and the OpenRouter model page. The model id is fugu-max (v1.0).

The flat-rate design is the cleanest thing about it. Per Sakana, the $2/$6 rate holds "regardless of context length," so a 900K-token prompt costs the same per token as a short one, whatever the context window holds. Most frontier models add a long-context surcharge once you cross a threshold, so if you routinely throw large documents at a model, this is a real, checkable advantage.

For contrast, its sibling Fugu Ultra v2 does step up on long context, which makes the Max tier's flat rate stand out even inside the same family:

The two ways to pay, and one naming trap

You can buy Fugu two ways, and they are easy to confuse.

The subscriptions are a monthly allowance, and every tier gets you access to all Fugu models, not just Max:

Pay-as-you-go, by contrast, "bills by token usage instead of a monthly allowance, giving you elastic capacity for spikes and large jobs," which Sakana pitches at enterprise customers who can't cap their usage in advance.

Now the trap. The "Max Plan" subscription is not the same thing as the "Fugu Max" model. The $200 plan is a usage bucket that includes every model in the family; Fugu Max is one of the models inside it. You can run the Fugu Max model perfectly well on the $20 Standard plan, or on pay-as-you-go, and you don't need the $200 subscription to touch it. It's a small wording overlap that trips up almost everyone reading the pricing page for the first time.

The orchestration-token catch

This is the part of Sakana Fugu Max pricing that a rate table hides, and it's the single most important thing to understand before you budget.

When you call Fugu Max, you aren't talking to one model. You're talking to a learned coordinator that reads your request and routes it across a pool of open-weight and specialized models, then synthesizes one answer. That's the whole appeal of the Fugu family: you get a multi-agent system, a real AI agent pattern, without building one.

The billing consequence is spelled out on OpenRouter: "Orchestration tokens consumed by the system are billed as standard input/output tokens." In plain terms, the internal chatter between the models is on your meter, not free. So a single request that fans out to three or four models can burn noticeably more tokens than a straight single-model call would, and the low $6 output rate doesn't automatically translate into a low per-answer bill.

Sakana does soften this, and it's worth quoting the mechanism fairly. Per its FAQ, when multiple agents are active, "we never stack fees: you pay a single rate based on the top-tier model involved." So adding more agents to a request doesn't multiply the rate you're charged, it just means more tokens flow through at that single rate. The upshot: your cost scales with total tokens, and orchestration inflates total tokens. Budget on tokens-per-answer, not on the sticker rate.

What buyers actually paid in the first days

List prices and real bills are different numbers, and for once we have a public window into the gap. On OpenRouter's live pricing panel in Fugu Max's first days after its September 11 launch, the numbers looked like this:

• Listed: $2 input / $6 output per million.
• Effective input price: ~$0.61 per million, well under the $2 list.
• Effective output price: $6 per million, unchanged.
• Cache hit rate: 79.4%, which is what drags the effective input price down.
• Throughput around 29 tokens per second, single provider, 100% uptime.

So caching pulls the input cost down hard, while output stays at list. That tells you where to spend your optimization effort: Fugu Max rewards heavy caching and punishes chatty, output-heavy generation. If your workload reuses a lot of the same context (a fixed system prompt, a stable document set), the effective input rate can be a fraction of the sticker. If every call is fresh and output-heavy, you'll live closer to the $6 line.

How the cost compares to other models

Here's where the pricing gets its headline. Sakana claims Fugu Max delivers output "40-60% cheaper" than Sonnet 5, GPT-5.6 Terra, and Kimi K3 in its release post, while landing "within striking distance of elite models." Lined up against each vendor's own list rates, the output gap is real:

Two honest caveats before you screenshot that table. First, these are list rates at the time of writing, and vendors move them, so treat the row values as a snapshot, not a contract. Second, the comparison is on the raw token rate, which, as the orchestration section above shows, is not the same as your per-answer cost on Fugu Max. A model that fans out will spend more tokens to reach the same answer than one that doesn't, so a cheaper rate can still produce a similar bill.

The efficiency framing is the real pitch, and I think it's a fair one: performance close to elite models at a lower output cost, verified so far only by Sakana's own benchmarks. The strongest proprietary models, like Fable 5, aren't in Fugu's pool, which is the point Sakana is making and also a limit on how far the comparison stretches. As with any AI model claim, the vendor's grid is a starting point, not proof.

Estimate your own Fugu Max bill

The math above is easier to feel than to read, so here's a quick calculator. Plug in your rough monthly volume and cache behavior, and it estimates the pay-as-you-go bill and tells you where the $200 Max subscription starts to make sense.

The lever that jumps out when you drag the sliders: cache hit rate moves the input line more than raw volume does. That matches the OpenRouter data, and it's the first thing I'd tune before worrying about the subscription tier.

Where a model's bill ends and the real cost begins

Here's the distinction I keep coming back to, because a pricing post makes it easy to forget: the token bill is not the cost that matters for most jobs. It's the cost of the engine, not the cost of the work.

Take customer support, the area I know best. A model, however cheap its tokens, hands you back text. To turn that into resolved tickets you still have to connect it to your helpdesk, teach it your knowledge base and policies, give it permission to look up an order or tag a ticket, decide when it escalates to a human, and prove it's safe before it touches a real customer. That work is most of the project, and none of it shows up on a per-million-token rate.

This is exactly why I compare the cost of an AI agent versus a human agent on resolution, not on tokens, and why an offshore support team cost comparison turns on the same per-resolution math.

It's the same logic that makes Fugu itself attractive: most teams don't want to build the multi-agent plumbing themselves, so they buy managed orchestration. Push that one level up, and for support you probably don't want to hand-build the whole employee around a model either.

Try eesel: price the ticket, not the token

That's the gap eesel fills. eesel is an AI teammate platform: you hire ready-to-work teammates for specific jobs, and each one arrives with the skills, integrations, and company context for its role. The AI helpdesk teammate joins your existing queue, looks up orders and records, tags tickets, and drafts or sends replies, all inside the helpdesk you already run.

The part that matters for a pricing post: you never do per-model math. eesel runs on frontier models under the hood and handles that choice for you, and it bills on resolution, not tokens, so the number you forecast is the number that maps to work done. It trains on your past tickets and knowledge base, plugs into 1000+ tools like Zendesk, Freshdesk, and Gorgias, and lets you simulate on historical tickets to see both the resolution rate and the cost before it ever answers a customer, the dry run Fugu's opaque routing can't give you.

If you live in a terminal, eesel also exposes a real programmable surface. The eesel CLI (@eesel/cli) and its MCP server let a person, a script, or a coding agent like Claude Code drive the same teammate as the dashboard: connect integrations, edit the teammate's standing instructions, run eesel activity to inspect every run, and approve or deny actions, all as JSON, with a --dry-run flag that prints the exact call a write would make before it sends. That's the agentic access an API-only model leaves you to build yourself.

Fugu Max is a strong answer to "which model should power my app, and what will the tokens cost." If your real question is "what will it cost to resolve more tickets," you can try eesel free, no credit card and no sales call, and price the work instead of the token.