Sakana Fugu Alternatives: Best Open-Source & Self-Hosted Options (2026)

Sakana Fugu Alternatives: The Best Open-Source and Self-Hosted Options (2026)

The best open-source Sakana Fugu alternative is a transparent, self-hostable orchestrator like Maestro — it routes your queries across providers you control, shows you the exact cost and model behind every answer, and runs on your own infrastructure. If you only need a multi-provider proxy, LiteLLM or RouteLLM cover that, and OpenRouter is the easy hosted route.

Sakana Fugu (launched June 22, 2026) is a clever idea: one OpenAI-compatible API that routes each task across a pool of frontier LLMs so you do not have to pick a model yourself. The catch is that it is closed. You cannot see which model answered, you cannot swap the pool, the per-query cost is opaque, and you cannot self-host it. For a lot of teams that is a non-starter, which is exactly why people are searching for a Sakana Fugu alternative they can actually open up and run themselves.

This guide covers the best open-source and self-hosted Sakana Fugu alternatives in 2026, what each one is good for, and how to choose.

TL;DR

• Sakana Fugu is closed and not self-hostable. Hidden routing, a fixed model pool, and opaque cost are the main reasons people look for an open source Fugu alternative.
• Maestro is the closest open-source take on Fugu: MIT-licensed, self-hostable, with a model pool that is 100% yours and full cost transparency on every response. It is early (v0.1), so treat it as a foundation, not a finished product.
• LiteLLM and RouteLLM are battle-tested open-source routers if you mainly want multi-provider access or cheap/strong cost routing.
• OpenRouter is the fastest path if you want a unified, hosted API and do not need self-hosting.
• Direct providers (OpenAI, Anthropic, Google) are the simplest option when you do not need any routing at all.

Why look for a Sakana Fugu alternative

Sakana Fugu's pitch is orchestration without the overhead: send a prompt, and it decides which frontier model in its pool should answer. If you want the background, see what Sakana Fugu is and our Sakana Fugu review. The concept is sound. The problems are structural.

The routing is hidden. When Fugu returns an answer, you do not know which model produced it. For a quick chatbot that may be fine. For anything where the model matters — compliance, reproducibility, debugging a bad output, or just understanding your own system — a black box is a liability.

The model pool is fixed. You use the models Sakana picked, in the configuration Sakana chose. You cannot add your own fine-tuned model, route to a local model for privacy-sensitive data, or opt out of a provider you would rather not send data to.

The cost is opaque. Because you cannot see the route, you cannot see what each query actually cost to serve. That makes per-query economics hard to predict and harder to optimize.

It is not self-hostable. Fugu is a proprietary hosted API. If you need to run inside your own VPC, keep data on-prem, or avoid a single-vendor dependency, that rules it out entirely.

None of this means Fugu is bad — it means the trade-off it makes (convenience for control) is the opposite of what a lot of engineering teams want. If you want the broader landscape, here is what LLM orchestration is and a rundown of open-source LLM orchestration and routing tools.

The best open-source alternative: Maestro

Maestro describes itself as "the open-source orchestration brain for LLMs," and it is the most direct open-source answer to Fugu. It is MIT-licensed, open-source, and self-hostable. Repo: github.com/walidboulanouar/maestro. Site: maestro.ayautomate.com.

Full disclosure: Maestro is built by AY Automate, the team behind this blog. We are not going to pretend it is more finished than it is, so read the honesty section below before you decide.

How the routing works

Maestro takes the opposite stance to Fugu on transparency. Instead of a hidden router over a fixed pool, it runs a cheap-first, verify, then escalate loop:

1. Try cheap first. A lightweight model takes the first pass at the task.
2. Verify. Maestro checks the answer against the task before trusting it.
3. Escalate only when needed. If the cheap answer does not hold up, it routes to a stronger model — and only then do you pay for the stronger model.

The point is to spend frontier-model money only on the queries that actually need a frontier model, rather than sending everything to the most expensive option by default.

The receipts: cost transparency

This is where Maestro is the most direct contrast with Fugu. Every Maestro response includes a maestro block — "the receipts" — that shows the route decisions it made, the per-model token counts, and the cost. You can see exactly which model answered, why it escalated (or did not), and what the query cost you. Nothing is hidden.

Your model pool, your infrastructure

Maestro's model pool is "100% yours." You define it in a JSON registry and point it at any open, closed, or local models you like. It works with OpenAI, Anthropic, OpenRouter, the Vercel AI Gateway, Ollama, vLLM, and llama.cpp. So you can mix a hosted frontier model with a local Ollama model for sensitive data, all behind one API.

It is OpenAI- and Anthropic-wire compatible, which means existing OpenAI clients just point their base URL at http://localhost:8080/v1 and keep working. It plugs into Claude Code, Cursor, and Continue with no code changes. You can run it with a single command — npx openmaestro serve — or with Docker. No GPU required, no heavy setup, one API key to get going. There is even a maestro-fugu mode (single worker plus verify) if you want the simplest Fugu-style behavior.

Honest status: Maestro is v0.1

Here is the part most launch posts skip. Maestro is early. It is an honest "~5-hour build." The core works and is tested live, but it is not production-hardened yet. The learned router is not built — v0.1 ships with a heuristic difficulty classifier, and that classifier sometimes mis-estimates how hard a task is, which means it occasionally routes wrong.

On its own offline benchmark, Maestro hit roughly 92% pass at about $0.00053 mean cost per query, versus a best-single-model baseline that hit 100% pass at about $0.01507. Read that honestly: the single frontier model passed everything, and Maestro did not. What Maestro did was get most of the way there for a fraction of the cost per success. It does not claim to always beat a single frontier model — and these are Maestro's own early numbers, not an independent benchmark.

So: if you want a transparent, self-hostable orchestrator you can read, fork, and run today as a foundation, Maestro is the best open-source Fugu alternative. If you need a hardened production system tomorrow with zero iteration, treat v0.1 as a starting point, not a drop-in replacement. For a head-to-head, see Maestro vs Sakana Fugu.

Other alternatives

Maestro is not the only option, and depending on what you actually need, one of these may fit better.

LiteLLM. A popular, mature open-source proxy and router that gives you one OpenAI-compatible API across 100+ providers. It is self-hosted and free. If your main goal is "talk to every provider through one interface" with good production tooling around it, LiteLLM is the safe, well-trodden choice. It is a proxy and router rather than a verify-and-escalate orchestrator, so it does not do cheap-first cost routing out of the box, but it is rock solid for unified access.

RouteLLM. An open-source framework from LMSYS focused specifically on cost routing: it decides whether a query should go to a cheaper model or a stronger one, aiming to cut cost without giving up much quality. If cost routing between a cheap and a strong model is the one feature you care about, RouteLLM is purpose-built for it and free to self-host.

OpenRouter. A hosted, unified API and marketplace across many models. It is not self-hosted and it is usage-based, so it does not solve the "run it in my own infra" requirement. But if you want the convenience of one API key across dozens of models without standing anything up, OpenRouter is the easiest hosted route — closer in spirit to Fugu's convenience, just with model choice in your hands.

Direct providers (OpenAI / Anthropic / Google). The simplest possible answer. If you do not actually need cost routing or a model pool, call the provider directly. You get no orchestration and no automatic cost optimization, but you also have nothing extra to run, and you always know exactly which model answered.

Comparison table

Pricing note: LiteLLM and RouteLLM are free and open-source (self-hostable). Hosted options (OpenRouter, direct providers) are usage-based — you pay for the underlying model calls.

How to choose

Work backward from your hard constraints.

• You need self-hosting and full transparency. Maestro is the closest fit — your model pool, your infra, receipts on every response. Accept that it is v0.1 and budget time to harden it.
• You need unified multi-provider access more than routing. LiteLLM. Mature, widely deployed, one API across everything.
• You specifically want cost routing between a cheap and strong model. RouteLLM does exactly that.
• You want convenience and do not need self-hosting. OpenRouter gives you many models behind one hosted API.
• You do not need routing at all. Call OpenAI, Anthropic, or Google directly and keep your stack simple.
• You want hands-off hosted routing and closed is acceptable. That is what Sakana Fugu is for — the alternatives above exist precisely for the teams it does not fit.

Bottom line

Sakana Fugu made multi-model orchestration easy by making it closed. The open-source alternatives flip that trade: you take on a little more setup in exchange for seeing and controlling everything. Maestro is the most direct open-source Fugu alternative — transparent, self-hostable, your own model pool — but it is early, so treat it as a strong foundation rather than a finished product. LiteLLM, RouteLLM, and OpenRouter each cover a narrower slice well. Pick based on the one constraint you cannot compromise on: self-hosting, transparency, cost routing, or sheer convenience.

FAQ

What is the best open-source Sakana Fugu alternative? For a transparent, self-hostable orchestrator, Maestro is the closest open-source take on Fugu — it routes across a model pool you control and shows the cost and model behind every answer. If you only need a multi-provider proxy or cost router, LiteLLM and RouteLLM are mature open-source options. Note that Maestro is early (v0.1).

Is there an open-source version of Sakana Fugu? There is no official open-source Sakana Fugu — Fugu itself is proprietary and not self-hostable. The closest open-source equivalent in concept is Maestro, an MIT-licensed orchestrator that does cheap-first, verify, then escalate routing with full cost transparency. It is built independently by AY Automate, not by Sakana.

Can I self-host an LLM orchestrator? Yes. Maestro, LiteLLM, and RouteLLM are all open-source and self-hostable. Maestro runs with npx openmaestro serve or Docker — no GPU required — and works with local backends like Ollama, vLLM, and llama.cpp alongside hosted providers, so you can keep sensitive traffic entirely on your own infrastructure.

Is Maestro production-ready? No. Maestro is v0.1 and an honest early build. The core works and is tested live, but it is not production-hardened yet, and the learned router is not built — v0.1 uses a heuristic difficulty classifier that can sometimes mis-estimate task difficulty and route incorrectly. Treat it as a solid foundation to build on, not a drop-in production system.

Does Maestro always beat a single frontier model? No, and it does not claim to. On its own offline benchmark it reached about 92% pass at roughly $0.00053 mean cost, versus a single frontier model at 100% pass for about $0.01507. It trades a small amount of accuracy for a large cut in cost per success — but a single frontier model passed more tasks. These are Maestro's own early numbers.

How is Maestro different from Sakana Fugu? Fugu is closed, hosted, hides which model answered, uses a fixed pool, and is not self-hostable. Maestro is open-source (MIT), self-hostable, lets you define your own model pool via a JSON registry, and returns a maestro block with the route decisions, per-model tokens, and cost on every response. See Maestro vs Sakana Fugu for the full comparison.

Will my existing OpenAI code work with these alternatives? With Maestro, yes — it is OpenAI- and Anthropic-wire compatible, so existing OpenAI clients just point their base URL at http://localhost:8080/v1 and keep working, including Claude Code, Cursor, and Continue. LiteLLM and OpenRouter also expose OpenAI-compatible APIs, so most clients work with minimal changes.

Which alternative is cheapest? The open-source tools (Maestro, LiteLLM, RouteLLM) are free to run — you only pay for the underlying model calls. Maestro and RouteLLM additionally try to lower those model costs by routing cheap-first and escalating only when needed. Hosted options (OpenRouter, direct providers) bill on usage with no infrastructure to run.

Sources

• Maestro repository: github.com/walidboulanouar/maestro
• MarkTechPost, "Sakana AI Launches Sakana Fugu, an Orchestration Model that Routes Tasks Across a Swappable Pool of Frontier LLMs": marktechpost.com

Want an Orchestration Layer Built for You?

AY Automate builds and self-hosts production multi-model orchestration and failover systems — the kind of routing, verification, and cost-control layer described above, hardened for your stack. Maestro is our open-source take on the idea, and we use what we learn from it on client work. If you want an orchestration layer designed around your model pool and constraints, see our AI agent development service.