Stay in the editor.
Spend with intent.
Bring local-first prompt routing to your Cursor workflow, from a quick code explanation to a change that needs broader reasoning.
A Cursor workflow with room for every tier.
In an editor-centered session, questions arrive at different scales. You might ask what a selected function does, adjust a component, then reason about a dependency that affects several files. Sending every request to the same tier overlooks those differences.
Switchka is designed to sit in the model-routing path while you continue working in Cursor. The goal is to use a suitable local model for everyday work and add cloud capability when the task calls for it. Exact compatibility and the supported connection method need confirmation during onboarding.
Understand selected code
With a relevant function and a narrow question, a suitable local model may be enough. Check the answer against the actual control flow, especially if behavior depends on callers or external state.
Make a focused edit
Describe the intended behavior and the files involved. A contained edit may remain local, while a change that needs more context may fit efficient cloud. Review the diff and run the relevant project checks.
Reason across the project
A change that crosses module boundaries may justify a more capable route. Explain the constraints and ask for assumptions. Frontier capability can be useful when the problem demands it, but the proposal still needs review.
Before your first connected session.
Prepare these details for onboarding. This checklist describes readiness; it is not an installation procedure.
- Confirm your Cursor version and the supported way to connect Switchka before changing settings.
- Choose a small project task with a result you can assess independently.
- Review what code and context may be shared with a cloud route. Establish any local-only requirement.
- Confirm local model availability and the cloud tiers available to your environment.
- Keep a baseline for the same kind of task, then compare total token spend and accepted results.
Context, escalation, and review.
Editor context is part of the routing evaluation. A short question can depend on code outside the visible selection, and a long pasted function may still ask for a simple explanation. Include enough context to make the request answerable without sending unnecessary material.
When evaluating results, consider whether the response fits the codebase’s existing patterns. A plausible edit can still violate a project convention or miss a caller. Use the same review, tests, and source-control habits you would use with any other model-backed edit.
Do not treat local-first as a blanket promise about all editor traffic. Understand the actual connection, what context is included, and when cloud processing is allowed. This page describes intended workflow rather than a verified installation procedure.
Common questions
Do I need to change how I write prompts?
Keep stating the outcome you need and include relevant context. Clear scope makes both routing and review easier, but no special prompt syntax is documented here.
Does every Cursor request stay local?
No. Local-first routing can escalate when more capability is needed. Confirm the processing boundaries for your setup before using sensitive material.
Where are the setup commands?
Request access so the supported connection method can be confirmed for your environment. This page does not publish unverified commands or endpoint settings.