The Monogamy Assumption
Most AI engineering tools ask you to pick a model the way you pick a spouse: one, up front, for everything. The assumption is so common it goes unexamined — one product, one model, one bill.
But look at what a real engineering mission actually contains. Architecture and planning: deep reasoning over a large context, where a mistake poisons everything downstream. Implementation across four repositories: sustained, high-quality code generation. Research: reading hundreds of files and summarizing — broad, shallow, massively parallel. Verification: reading test output, CI logs, and metrics against explicit criteria — high-volume, well-specified, cheap.
These workloads differ by orders of magnitude in difficulty and in volume. Routing all of them to one model means you are either overpaying for the easy work or under-serving the hard work. Usually both, at different hours of the same day.
Nobody runs infrastructure this way. You do not put your batch jobs on the same instance type as your database. Compute is matched to workload; it is the most basic operational instinct we have. Models are compute. The instinct applies.
Roles, Not Requests
The practical question is where routing decisions should live. Per-request routing — classifying each prompt and picking a model on the fly — is clever and unpredictable, which is a bad combination for engineering work where you want to know what quality bar produced a change.
Skyflo routes at the level of mission roles, and the configuration is yours:
- The orchestrator — planning, decomposition, integration — gets your strongest reasoning model. This is the role where quality compounds: a bad plan makes every downstream token worthless.
- Implementation agents get frontier or near-frontier coding models, chosen per your taste and budget.
- Research roles get fast, cheap models. Summarizing three hundred files does not need genius; it needs throughput.
- Verification can run on a local model. Reading evidence against explicit criteria is exactly the shape of task where smaller models shine — and there is something architecturally satisfying about the auditor costing nothing, so you never economize on auditing.
Roles are stable, so behavior is predictable: you always know which class of model produced the plan versus the summary. And because the roles are explicit, changing your mind is a config edit — swap the implementation slot to this month's best coder and the mission structure does not move.
The quiet corollary: the harness is the durable layer. Models will keep leapfrogging each other every quarter. The missions, the memory, the verification structure, the approval gates — those persist. Betting your workflow on a single vendor's model is betting on a snapshot of a leaderboard. Betting on the layer that coordinates models ages better.
BYOK Is an Incentive Structure, Not a Feature
Skyflo runs on your keys: hosted providers, OpenAI-compatible endpoints, or local inference. This gets listed as a feature; it is better understood as an alignment mechanism.
When a product resells inference, every token you burn is revenue. The vendor has a structural incentive toward chatty agents, padded context, and "thorough" runs — and no incentive to let you route the easy 70% of work to a model that costs a tenth as much. When you bring your own keys, the incentive flips: the product competes on how efficiently it spends your budget, because the bill is legible to you, at provider rates, with no markup hiding in the middle.
That is why the pricing prices the harness — coordination, memory, governance — and takes zero percent of your inference. Two bills, no overlap, and the party orchestrating your tokens has no reason to waste them.
The Local Option Is Not a Toy
Per-role routing has a consequence that matters enormously to a specific set of teams: some roles can run on models that never leave your building.
A fully local configuration — local models via an OpenAI-compatible server, local execution, on-disk memory — yields missions with zero external calls. Code never leaves the machine; neither does the memory of what the code means. For regulated environments, air-gapped networks, or plain institutional caution, this is the difference between "we can evaluate agents" and "legal said no."
The more common pattern is a mix: frontier models for planning and implementation, local for verification and anything that touches sensitive paths. The point is not local purity. The point is that sensitivity is a per-role property, and the routing should be too.
The Portfolio Mindset
The teams getting the most out of AI right now do not have a favorite model. They have a portfolio: strongest available reasoning where mistakes compound, cheap throughput where they do not, local where data demands it — rebalanced as the market moves, without re-platforming.
One model is the wrong number for the same reason one instance type is the wrong number. The interesting engineering was never in picking the winner. It is in building the system where you do not have to.