Sakana Fugu turns model routing into one OpenAI-compatible endpoint

Most teams I talk to already run three or four model APIs. Claude for planning, a cheap open model for edits, maybe Gemini for long context. The glue is custom routing code nobody wants to maintain.

Sakana Fugu flips that. It is itself a small orchestrator model trained to call other models, pick the right one per step, and stitch results together. You hit one endpoint. Fugu handles the rest.

That is not just convenience. In mid-2026, export controls and vendor concentration are real deployment risks. If your app hard-codes anthropic or openai, a policy change can take down a feature overnight. An orchestration layer that can swap workers without redeploying your app is infrastructure, not a nice-to-have.

What Fugu actually is

Fugu is grounded in two ICLR 2026 papers on learned orchestration: TRINITY and the Conductor. Sakana's technical report describes a family of orchestrator models that expose a multi-agent system through a single model interface.

Given a user query, Fugu constructs an agentic scaffold over a pool of frontier LLM workers. It decides:

• Which workers to involve
• What roles or instructions to assign
• How to combine or verify intermediate outputs
• When to return the final answer

From the outside, you call one model. Inside, a coordinated team does the work.

Fugu vs Fugu Ultra vs Fugu Cyber

Sakana ships three variants behind the same OpenAI-compatible API:

Fugu balances performance with low latency. Fugu Ultra coordinates a deeper pool and targets maximum answer quality on multi-step problems. For production Ultra workloads, Sakana recommends pinning fugu-ultra-20260615 rather than the moving fugu-ultra alias.

Benchmark snapshot

Sakana's published comparison (baselines from provider reports, SWE-Bench Pro via mini-swe-agent scaffolding):

The interesting part is not just the headline numbers. Fugu Ultra beats the individual models it coordinates on several tasks. The orchestrator adds value beyond any single worker.

Drop-in integration

Fugu uses an OpenAI-compatible API at console.sakana.ai. No SDK migration required.

from openai import OpenAI

client = OpenAI(
    base_url="https://api.sakana.ai/v1",
    api_key="YOUR_SAKANA_API_KEY",
)

resp = client.chat.completions.create(
    model="fugu-ultra-20260615",
    messages=[
        {"role": "user", "content": "Fix the failing test in src/auth.ts"},
    ],
)

Sakana recommends the POST /v1/responses endpoint for new integrations because it exposes richer tool-use and reasoning interfaces. Chat Completions works for a quick compatibility check.

For coding harnesses (Codex, Cline, custom agents), point the existing OpenAI client at the Fugu base URL. That is the same pattern I use with internal LLM gateways and task-based routing rules.

Export controls as an architecture problem

The AlphaSignal framing is geopolitics meeting plumbing. I see it more practically.

If one model in your pool gets restricted, Fugu can route around it. You configure blocked models at the orchestrator level. Your application code still says model="fugu". The swap happens server-side.

That is weaker than full self-hosting, but stronger than betting everything on one vendor's API key. For teams that need frontier quality without single-vendor lock-in, orchestration layers like Fugu, Coinbase's gateway, and Cursor Router are converging on the same pattern: one endpoint, many backends, policy at the router.

What I would test before shipping

Fugu hides per-query model selection. That is a feature for simplicity and a risk for cost predictability.

Before you route production traffic:

1. Pin model versions in staging (fugu-ultra-20260615, not aliases).
2. Log token usage per request. Orchestrators can burn more tokens than a single model on hard tasks.
3. Set compliance blocks early if you have data residency rules.
4. Run your own eval set. SWE-Bench numbers are useful; your repo's flaky tests matter more.
5. Compare latency on your P95 paths. Ultra is quality-first, not speed-first.

Where this fits in a client stack

I would not replace every model call with Fugu on day one. The pattern that works:

• Fugu Ultra for hard agent loops (security review, multi-file refactors, research synthesis)
• Fugu (standard) for interactive chat and lighter coding tasks
• Direct API to a cheap open model for bulk preprocessing (embeddings, classification, formatting)

The orchestrator earns its fee when task complexity is high and model choice is uncertain. For deterministic pipelines, a fixed router rule is still cheaper.

If you are wiring multi-model agents into production and want a second pair of eyes on routing, compliance blocks, or gateway design, book a free discovery call. I help teams ship agent stacks that survive vendor changes, not just demo well.