The Monogamy Assumption
Many AI engineering tools begin with one model choice for the work in front of them. The assumption is easy to leave unexamined: one product, one model, one bill.
But look at what a broad engineering mission contains. Architecture and planning need deep reasoning over a large context. Implementation needs sustained code generation. Research often means reading many files and summarizing. Review means inspecting artifacts against explicit criteria.
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.
Skyflo currently supports model access through signed-in coding harnesses and configured Moonshot or Z.ai keys. Managed inference and expanded paid capacity are Planned. This article describes why a complete harness should route models by role; it does not claim that the planned managed lane ships today.
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.
A target harness can route at the level of mission roles:
- 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.
- Review can use a model suited to reading diffs and reporting findings against explicit criteria.
Roles are stable, so behavior can stay predictable. A team should be able to identify which class of model produced a plan or report and change that choice without changing the mission structure.
The quiet corollary is that the harness is the durable layer. Models will keep changing. The mission, approval boundary, review structure, and accepted memory should persist around them.
BYOK Is an Incentive Structure, Not a Feature
The current Desktop harness uses supported signed-in coding harnesses or configured Moonshot and Z.ai keys. This is better understood as an alignment mechanism than a pricing slogan.
With BYOK or provider-direct access, the model bill remains legible at the provider. Skyflo applies no token markup to those lanes.
Managed inference is a separate Planned lane and should not inherit the BYOK no-markup claim. The pricing page labels the catalogue and current availability explicitly.
Local Execution Is Not Local Inference
Skyflo's mission state, repository work, terminal, browser, and personal memory remain on the Mac. That local execution boundary does not mean every model request stays on the device.
Supported coding harnesses and provider-key lanes may send model requests to their respective providers. Skyflo does not currently expose a generic local-model or OpenAI-compatible endpoint, so the product makes no on-device inference claim.
The architectural point is honest custody. Local project and memory storage must not be presented as proof that model traffic remains local.
The Portfolio Mindset
An effective model portfolio can use strong reasoning where mistakes compound and cheaper throughput where it does not.
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.