What the gateway layer got right
Layer Cake is the part of myOrbit that decides how agent work gets done across model providers. Before describing it, credit where it belongs.
OpenRouter gave developers one API key and one endpoint reaching hundreds of models across dozens of labs, and solved real operational problems on the way. Provider failover is automatic and on by default. Fallbacks trigger on downtime, rate limits, context-length errors, and moderation flags. Billing is honest about failure — requests are priced using the model that was ultimately used, so a dead attempt doesn’t land on your invoice.
There is a defensible cost model underneath, too. Their default balancing across providers for a given model is weighted by the inverse square of price, filtered for recent outages. For a neutral marketplace serving every workload on earth, that is the right default: the caller knows their own job, the gateway doesn’t, so optimize the thing that generalizes.
They solved one-API-many-models for inference. What follows is a step past that, and it isn’t only ours.
One request is not one model call
Inference routing takes a prompt and picks a model for it. That is the correct abstraction when a prompt is the whole job.
Agent work isn’t one prompt. A single request — research this, draft that, act on the result — is not one call, and the work it becomes does not have uniform requirements. Sending all of it to one provider means most of it is served by a model chosen for someone else’s problem.
So Layer Cake runs a request across multiple labs rather than through a single provider. That placement is the product, and it is the part we do not describe in public — for reasons that turn out to be shared.
A Tokyo lab published the same shape
Sakana AI’s Fugu is, in their words, “a Multi-Agent System, Delivered as One Model” behind an OpenAI-compatible API. It is grounded in two ICLR 2026 papers, TRINITY and the Conductor; the former “uses a lightweight evolved coordinator to orchestrate multiple LLMs over several turns,” and the system “learns to dynamically assemble agents from a pool” rather than following hand-designed workflows.
Their release notes put the motivation plainly. They describe a “pool of entirely swappable agents.” If a single provider restricts access, “Fugu dynamically routes around the disruption.” The stated purpose is to address “the severe risk of single-vendor dependency” — and they frame collective intelligence, not any one model, as “the practical hedge against this concentration of power.”
We want to be careful about what we claim here. We are not saying we did this first, and we are not claiming our results match theirs — theirs are benchmarked and published, and this note is not a benchmark. What we are pointing at is convergence. They name the same pressures we did — single-vendor dependency as an operational risk, long and messy real-world work as the thing that breaks under one model. We got there building for agents doing multi-step work on a person’s behalf, where an outage is a broken promise to a user rather than a degraded score. Same conclusion, reached separately. That is usually a sign the shape is right rather than clever.
The part nobody in this class of system will tell you
Here is the sentence from Sakana’s own page that we would put on the wall:
“The specific models Fugu selects and how it coordinates them are proprietary, so this routing information is not exposed by design.”
We have made the same call, and we said so before — we do not publish how a request becomes work, or how the choice of provider is made. This note is not a quiet retirement of that promise. It is the same line, drawn in the same place.
It is worth saying why, because “proprietary” on its own is a shrug. The placement logic is the hard-won part, and a published description of it is a specification for reproducing it. And the honest answer to why a piece of work went one way today changes faster than any page can be kept true — a routing story published in good faith becomes a lie by attrition, and a stale technical page is worse than none, because people plan against it.
If that reads as evasive, notice who else is being evasive in the same way for the same reason. A frontier lab that publishes its ICLR papers, its benchmarks, and its architecture still draws the line at per-request routing. When independent teams keep landing on the same boundary between what is worth explaining and what is worth keeping, that boundary is probably real.
Capability first, and only
There are no cost caps in Layer Cake’s selection path. No price ceilings, no latency budgets, no cheaper-provider-if-the-question-looks-easy heuristic. Capability decides, and the bill is whatever the bill is.
That is not a criticism of price-weighted routing — for a neutral gateway it is the better design. It is a statement about position in the stack. A gateway is a utility serving callers whose jobs it cannot see. We are the caller. We know what a piece of work is for and what it costs us when it comes back wrong, and quality quietly traded away to save a fraction of a cent is the worst kind of saving: the gain is measurable and the damage isn’t.
Our own outcomes outrank the marketing
Provider choice here is informed by what actually happened in our production runs, and that ledger is weighted above what any lab says about its own release. Launch-day benchmark claims are marketing artifacts with a real signal buried somewhere inside them. Our own outcome data is narrower, noisier, and about the exact work we do. When they disagree, ours wins.
Third-party rankings feed in too, but not indiscriminately. What counts as a source is settled by a deterministic step rather than a model’s judgement — the one place here where we deliberately refuse to be clever. Primary lab documentation and published research qualify. Press wires recycling a press release, and engagement-farming aggregators restating a leaderboard they did not run, do not. A benchmark laundered through four rewrites is not evidence, and a language model asked to judge source quality can be talked into believing it is.
Failing over without hiding our own bugs
Failover chains span labs, with one rule that matters more than the rest: a non-retryable client error never advances the chain.
If a call fails because of rate limiting, a timeout, or a provider having a bad afternoon, moving on is correct. If it fails because we sent a malformed request, or a schema we broke, or credentials we misconfigured, then advancing is actively harmful. The fallback would mask our own defect behind a successful-looking response, and we would watch our bug fail identically across every provider on the chain while the dashboards stayed green. Better to fail loudly, once.
This is not an idea we invented, and it would be dishonest to present it as one. OpenRouter draws the same line — a 400 for a malformed request comes straight back rather than triggering a fallback. Good discipline converges. We apply it to agent work, where a masked failure has more places to hide.
One further rule: a provider already burned in this run — billing exhausted, hard-failed — is skipped without another call. Retrying a known-dead provider to watch it fail again is latency spent on theatre.
Where this goes
Three labs — Anthropic, OpenAI, and Google — sit behind Aura and Echo OS today, and Layer Cake is how their work gets placed.
We have considered exposing this as an inference API, so other builders could get cross-lab placement without assembling it themselves. That is a direction we find interesting, not a commitment with a date on it. If it ships, it will ship as a note like this one, after it works.
