Article
August 13, 2026
3 min read
Where the Smartest Model Belongs
Model routing should follow the cost of being wrong: concentrate frontier reasoning where errors spread, then bound the remaining work with explicit contracts and evidence.
By Cristiano Pierry
This is part three of a three-part series about Learning to Aim, its playable Dart Room, and the model-routing decisions behind the work.
When I planned Learning to Aim, the model question became concrete in two pieces of work. One agent needed to implement the gradient math. Another needed to adjust the layout.
If the gradient calculation was wrong, every learning step in the presentation could be wrong with it. The animation might still look convincing. The numbers might still move in the right direction. The error could survive long enough to become part of the explanation.
A layout mistake was different. I could see it. We could compare the page with the design, correct the spacing, and move on without touching the mathematics underneath it.
The plan Codex proposed kept GPT-5.6 Sol at Ultra effort at the root of the project. It made the architectural decisions and reviewed the work coming back from the other agents. The mathematical engine went to Sol at xhigh effort. Terra handled much of the rendering, accessibility, and later polish work. I reviewed and approved that plan before the agents began.
I suspect those model names and effort settings will age faster than the decision behind them. The important part was knowing which errors could quietly spread and which outputs were easy to inspect.
The assignments only worked because the project had boundaries. Each workstream had its own worktree and a defined set of files. The agent building the network display could use the values produced by the model, but it could not create its own version of them. An agent could return a commit and its test results. It could not merge or deploy independently. I kept no more than three child agents running beside the orchestrator because reviewing the handoffs was still my job.
The tests followed the same logic. The mathematical suite ran 990 finite-difference comparisons against the analytic gradients. Inference had to leave the trained parameters byte-for-byte unchanged. The complete lecture journey ran across Chromium, Firefox, desktop WebKit, mobile Chromium, and iOS WebKit.
Those checks tell me that the implementation is behaving as designed. They do not tell me whether a first-time learner will understand the lesson. The manual device and assistive-technology work is still open, and so is the comprehension study. This is one of the places where a clean engineering result can create more confidence than it has earned.
I am not assigning each task to a model by hand. I ask Codex to inspect the work and decide which model and effort level belong on each task. It returns a routing plan with the boundaries and proof expected from each agent. I approve that plan before the work begins.
What I review is the reasoning behind those assignments. If an error could hide inside the work and contaminate everything downstream, I expect the plan to put a stronger model there. If the task is narrow and the result is easy to inspect, a less expensive model may be enough. The model names will change. The question I use to approve the plan is more durable: if this part is wrong, how far can the error travel before a person notices?
This writing reflects my personal perspectives on product management, AI, and content discovery. It does not represent the official position of my employer or any affiliated organization.