01 / Capability first. Cost in context.
The cheapest model is useful only if it can handle the request. Switchka’s routing principle is to find the lowest-cost capable route, rather than minimize the price of an isolated response at any cost. If an answer creates more repair work, its apparent savings may disappear.
Capability depends on the task, the context available, and the models available in your environment. A routine syntax explanation differs from diagnosing a subtle interaction across modules. The right comparison includes the quality of the final result and the number of attempts needed to reach it.
02 / Give local work the first lane.
Local-first means beginning with a suitable model on your machine for tasks it can handle. Contained explanations, small transformations, and well-scoped questions are representative candidates. Keeping everyday work on a local route can reduce cloud token usage and leave more of the budget for difficult tasks.
A local route needs an appropriate environment. Hardware, the model in use, and the context size all affect what it can do. This site does not prescribe a machine specification or a local runtime. Confirm the available local setup during onboarding, and test it against work that resembles your own.
Local inference can avoid cloud token charges for that request, but running a machine still has resource costs. Local-first is a preference in the routing approach, not a promise that all requests stay on the machine or that every task runs free of any cost.
03 / Escalate to efficient cloud.
When a task needs more than the local route can provide, an efficient cloud model is the next tier. A focused refactor involving several connected functions is a representative example: the task may need more context and reasoning without requiring the most capable model for every step.
Escalation changes the processing boundary. Before enabling it, understand what context your tool sends and whether project material may be processed externally. The details depend on the supported integration and model arrangement. Nothing on this page establishes a provider list, a data-retention promise, or a cloud permission setting.
Efficient cloud is a capability and cost category, not the name of one particular model. The useful question is whether a supported route can complete the task to the quality you need. A low price alone is not evidence that it is the right route.
04 / Reserve frontier for the hard parts.
Some work is expensive to get wrong. Planning a migration, reconciling competing architectural constraints, or reasoning about a difficult failure can justify the strongest available tier. Switchka keeps frontier capability in the routing story rather than treating it as the starting point for every request.
Frontier does not mean infallible. Give the model the relevant context, ask for assumptions to be made explicit, and validate the result. For code, inspect changes and run project checks. For planning, compare the proposal against operational constraints that may not be present in the prompt.
The tier examples describe why a route might be appropriate. They do not promise that a named task always takes one route or that the router follows a published confidence threshold. Actual task complexity and available capability decide whether escalation is useful.
05 / Follow the task, not its label.
These journeys are conceptual examples. They illustrate how the same development session can call for different capability levels, rather than documenting measured routing decisions.
Explain one unfamiliar function
A contained question with the relevant code in context may fit the local tier. Review the explanation against the implementation before using it to make a change.
Refactor a connected module
A broader edit may need more context. An efficient cloud route can be appropriate if it has the capability; validate the diff and the behavior after the edit.
Plan a staged migration
A plan involving dependencies, compatibility, and rollback constraints can justify frontier reasoning. Ask for tradeoffs and check the plan against the real system.
| Tier | Representative need | Consider before use |
|---|---|---|
| Local | Contained, everyday work | Suitable model and machine resources |
| Efficient cloud | More context or capability | External processing and result quality |
| Frontier | Demanding, consequential reasoning | Whether added capability justifies cost |
06 / Measure savings against useful work.
Start with a baseline for the way you currently work: the same tool, a representative set of tasks, and a consistent definition of an accepted outcome. Compare total token spend for that workload, including additional attempts or corrections. A single inexpensive response does not establish a workload-level improvement.
The supplied savings claim is 70%+ less token spend. Savings vary by workload. Your model mix, prompt and response sizes, available local capability, and need for frontier reasoning can all affect the result. Time, hardware resources, and review effort may also matter to your wider evaluation.
Keep a record of difficult cases as well as successful ones. If a task repeatedly needs escalation, that is useful evidence for deciding how to use routing in your environment. Request early access with your tool, a sanitized task example, and any constraints that determine which routes are acceptable.