Sakana AI released Fugu Max on 11 September 2026. It's an orchestration model that routes each API call to whichever underlying model can actually handle it, instead of hammering one flagship model for every request. Output pricing lands 40-60% below Anthropic's Sonnet 5, OpenAI's GPT-5.6 Terra, and Kimi K3, by Sakana's own benchmarks. If your chatbot or automation stack pays per token, this is worth ten minutes of testing this week.
What Is Fugu Max?#
Fugu Max isn't a single large model. It's a router sitting in front of a pool of open-weight and specialized models, including Nvidia's Nemotron family, picking the cheapest one that can actually do the job.
Sakana shipped two versions on the same day: Fugu Max for cost, Fugu Ultra v2 for raw performance (official release notes). Fugu Max runs $2 per million input tokens and $6 per million output tokens, live now through an OpenAI-compatible API. Sakana's own framing is blunt. To "deploy a multi-trillion-parameter model to execute a simple data lookup is not intelligent, but wasteful," in the company's words. Switching an existing integration over, they say, is a single-line parameter change. No rebuild. Just a different model string in your config.
On the benchmarks Sakana published itself, Fugu Max leads six tests including Terminal Bench 2.1 and AutomationBench. Ultra v2 scores 48.3 on Chartography against Opus 5's 27.3 (independent write-up). Those are Sakana's numbers, not third-party audited ones — worth remembering before you rebuild a pricing model around them.
Does This Actually Change Anything For You?#
Depends entirely on what's behind your chatbot right now.
If you're running a WhatsApp bot or support flow through a single model — most of the lead-response automations WebEpex ships call one model directly — this is a live option to cut the token line item without touching your conversation logic. You just point the same API call at a different endpoint and compare.
If you've already been chasing DeepSeek's time-of-day pricing or got burned by GLM-5.3-Flash's price doubling two weeks back, a router is a different fix for the same headache. Instead of manually re-pricing every provider every few weeks, you let the router pick. That's the pitch, anyway.
If you're under maybe 5,000 model calls a month, the dollar savings are small enough that it's not worth the afternoon. Above that, on a chatty support bot or a multi-step agent workflow, the math adds up fast.
The Honest Trade-Offs#
Routers add a layer you don't fully control. You don't know, call to call, exactly which model answered — that's fine for a FAQ bot, less fine if you need consistent tone or a specific model's reasoning style for something high-stakes like a sales qualification flow.
Sakana's own comparison set is favorable to Sakana, which is true of basically every model launch and doesn't make the numbers wrong, just worth a grain of salt. And there's no published self-hosting option, so you're trusting Sakana's uptime the same way you already trust your current provider's.
The case for it: you stop babysitting provider price changes, which is genuinely tedious work when you're running six or seven client bots.
How We're Handling It#
At WebEpex we build chatbot and workflow automation for clients across GCC, Europe, USA, Canada, and Indian SMBs, and every one of those builds runs through n8n with a model call sitting behind a webhook. We swapped Fugu Max into a staging copy of one client's WhatsApp intake flow the day it launched, running it in parallel against the existing GPT call for four days before touching anything live. Our first comparison run only logged response text, not token counts, so the early "savings" numbers were guesswork — we caught that after a day and reran the test properly before drawing any conclusions.
Output quality held up on straightforward intake and FAQ turns. It got noticeably less consistent on a multi-turn qualification sequence that leans on one model holding context across five or six messages. My read is that's the structural weak spot for any router: a different model can end up answering each turn, and tone drifts. We're not moving that flow over yet. Simple, high-volume, low-context replies are a different story, and we've already started migrating those on a second client this week.
Here's what we're checking before any client migration, and what you should check too if you're testing this yourself:
- Token costs on your actual traffic pattern, not the benchmark numbers
- Response consistency across a multi-turn conversation, not just single replies
- Whether your current provider has a rate limit or outage history that makes switching worth it anyway
- Latency under your real concurrent load, not a single test call
What I'd Tell a Client This Week#
If you're paying more than a couple hundred dollars a month in model API costs for a chatbot or automation, test Fugu Max against your current setup this week — it's a config change, not a rebuild, so the cost of trying it is basically zero. Run it in parallel, don't cut over blind. If your flow is simple FAQ or intake work, I'd bet it holds up fine. If it's a longer qualification or negotiation sequence, keep your current model until you've actually watched a week of real conversations through the router.
If you're not sure which camp your setup falls into, that's a two-minute question, not a project.
If you want a second pair of eyes on what's actually running behind your chatbot and whether a switch like this is worth your time, send me what you're using and I'll tell you straight. cal.com/webepex/growth-review
