Capability where it counts.

A question about a single function and a repository-wide design decision do not ask the same thing of a model. Yet a fixed-model workflow can send both to the same expensive tier. Small requests accumulate, and developers become responsible for switching models while trying to stay focused on the work.

Switchka puts the routing decision between the prompt and the model. Its purpose is to reduce unnecessary token spend without asking you to move out of Cursor, Claude Code, or Codex. Local models are the starting point, efficient cloud models cover the middle, and frontier models remain available for work that needs their capability.

Think of routing as a lifecycle. First, the request arrives from your coding tool with the context that tool supplies. Switchka considers the capability required by the task and the routes available in the environment. A contained explanation may suit a local model; a complex architectural question may justify a more capable tier.

The selected model handles the request, and the result returns to the workflow where you started. Routing changes which model does the work, not your responsibility to evaluate it. Read explanations critically, review proposed edits, and run the checks your project requires before accepting changes.

The examples on this site describe intended behavior. They do not establish a particular retry algorithm, a latency guarantee, or a list of supported model providers. During onboarding, confirm which routes are available for your tool and what conditions permit escalation.

There are three useful concepts to establish before configuring any environment: where local work can run, whether cloud escalation is acceptable, and when frontier capability is justified. These are decision boundaries, not executable configuration instructions. The current website does not expose a production routing console.

A local preference should be considered alongside hardware and model availability. A cloud boundary should reflect what project material may leave the machine. A frontier preference should reflect the cost of a weak answer as well as the price of a request. Confirm the available controls with support rather than assuming a toggle in the illustrative interface is an implemented setting.

Visibility is useful because a cheap request is only valuable when it produces a useful answer. The illustrative dashboard groups requests by tier and shows example costs and durations. In a real evaluation, compare the outcome of the task, any additional attempts, and the total spend needed to reach an accepted result.

Switchka is most relevant when a development session contains a mixture of small questions, contained edits, and harder reasoning. Explaining unfamiliar code, adjusting a focused function, and planning a multi-module change can have very different capability needs. A routing layer makes that variation the starting point for cost decisions.

For an individual developer, the benefit is fewer model-selection interruptions. For a team evaluating adoption, the useful exercise is to choose representative tasks and agree on what counts as a correct result. Include difficult cases, not just short prompts that are easy to route cheaply.

Start with work you can assess independently. A clear expected output, a focused diff, or an existing test suite gives you something concrete to evaluate. Expand only after you understand where the available model tiers are sufficient for your actual projects.

Local availability depends on the environment, and a capable cloud model may still misunderstand incomplete context. A shorter prompt is not automatically easy, and a long prompt is not automatically difficult. Routing cannot guarantee a correct answer, a successful code change, or a particular savings rate.

Local-first does not mean local-only. If your work must remain on the machine, establish that constraint before permitting cloud use. Do not infer privacy guarantees from the color of a route. Confirm the actual configuration and the terms that apply to any external tool or model.

The supplied 70%+ token-spend reduction is a savings claim, not a forecast for every user. Savings vary by workload. A frontier-heavy project, unavailable local route, or repeated attempts can change the economics. Evaluate against your own baseline and keep task quality in view.