Notes

The Model That Picks Your Platform Doesn't Write the Code

As open models make code execution cheap, a developer platform's moat becomes the loop of context, evals, and distribution that keeps critical journeys working while the models underneath churn.

One dark orchestrator node labeled Decide fans bounded tasks out to a grid of eight smaller worker nodes, one expensive decision routing many cheap builds.

GLM 5.2, Kimi K3, and a steady run of capable open models keep landing, and each one makes it cheaper to build something with your platform. When execution gets this cheap, a developer platform faces one question: what is the moat?

The easy answer is to bet on the smartest model and read this as an open-versus-frontier size race. Watch a real agent session and that framing falls apart. A frontier model reads the intent, resolves the ambiguity, and decides the design: which API fits, where the auth boundary sits, when the work is done. Then it hands bounded tasks to cheaper models that write most of the code. The model that picks your platform is not the model that writes with it.

That split is economic. The orchestrator spends its expensive reasoning on the few decisions that change the outcome. Implementation runs cheaper the moment a task is bounded and the checks are objective, because the compiler, the tests, and the linter catch what a smaller model fumbles. Good verifiers let the cheap tier carry real work. They are why open models keep sliding down the cost curve without ever winning at system design. I codified this routing in a public prompt that sends each job to the least costly model that can do it.

Your platform meets this system twice. The orchestrator is where your platform gets chosen, so it decides activation. The workers are where it gets built, so an example tested only on the strongest model is quietly undertested.

A descending staircase of tiers from Frontier to Balanced to Open, the cost circle shrinking at each step, showing the same journey completing at a cheaper tier.

The execution scoreboard is consistency. A journey is cheap when a small model completes it the same way run after run, with low variance and less context each release. When work that needed Gemini Pro lands just as reliably on Gemini Flash, developers get the same result faster and cheaper, and the same holds for every model family you route. A journey that drops a tier is a win worth counting.

The moat is the loop, not any single model. Own the context, evals, and distribution that keep your critical journeys working as the models underneath them churn. Our team runs a version of this for Google Maps Platform through portable agent skills and a task-based eval suite. Open source the skills and evals you want model teams to learn from, keep a held-out set, and ship the same tested context into every agent developers reach for.

Nobody knows where the tiers settle, including me. Treat each new model as another row in your test matrix, run it in your own harness, and let the evidence pick the tiers.

← All notes

Email list

Get new field notes by email

One email when a new essay, talk, or Labs project ships. No noise, and every send has a one-click unsubscribe.

The address is stored only to deliver these updates. See Privacy.

Discussion

Comments

Comments are GitHub Discussions rendered by giscus. Sign in with GitHub inside the widget to post or react.