Define the task.
Let the route fit.
Keep Codex in your development workflow. Match model capability to the work, then review the result against clear acceptance criteria.
A Codex workflow with room for every tier.
A useful coding task has a boundary: what should change, what should remain true, and how the result will be checked. That boundary also helps explain the model capability the task may need. A focused cleanup and a design decision across a codebase are different kinds of work.
Switchka is designed to route prompts in Codex workflows through local, efficient cloud, and frontier tiers. The aim is to avoid using the most expensive capability by default. The available connection method, environment support, and model choices need to be confirmed during onboarding.
Start with a clear task brief.
State the outcome, the constraints, and the evidence you will use to accept the work. The examples below show why a task’s scope matters more than its label.
A small, testable change
Specify one behavior and the files or area involved. A suitable local route may handle a contained request. Inspect the final patch and verify that the change meets the original acceptance criteria.
A multi-file implementation
Describe the interfaces and constraints the change must preserve. Efficient cloud can be a candidate when more context or capability is required. Evaluate the result as one coherent change, including any additional attempts.
A difficult design tradeoff
When the task involves competing constraints or a migration strategy, frontier reasoning may be justified. Request explicit assumptions and alternatives, then assess the recommendation against information outside the prompt.
Before your first connected session.
Prepare these details for onboarding. This checklist describes readiness; it is not an installation procedure.
- Describe your Codex environment and confirm its supported Switchka connection.
- Write down a representative task and concrete acceptance criteria.
- Identify what context the workflow uses and whether cloud processing is acceptable.
- Confirm available tiers and any restrictions before evaluating route selection.
- Review the patch, run appropriate project checks, and compare total spend for the accepted result.
Context, escalation, and review.
Route selection should be evaluated against the completed task, not simply the size of the initial prompt. A brief instruction may require significant reasoning about an unfamiliar codebase. A detailed request may still describe a simple and well-bounded transformation.
Keep review standards consistent across tiers. Look for unintended file changes, assumptions that were never established, and checks that were skipped. A cheaper response is useful only when the resulting work is acceptable, and a frontier response still needs independent validation.
During an evaluation, include easy and difficult tasks from your normal workflow. Track additional attempts and corrections alongside token spend. The supplied 70%+ savings claim is not a promise for any individual Codex task: Savings vary by workload.
Common questions
Does this page describe Codex configuration?
No executable configuration is published here. The task examples explain intended routing behavior; request access to confirm the supported connection for your environment.
Should I split every task into smaller prompts?
Give tasks a clear and reviewable scope. Splitting work can be helpful when it creates independent outcomes, but unnecessary fragmentation can lose context and increase attempts.
How should I compare routes?
Use representative tasks with the same acceptance criteria. Compare the accepted result, corrections, and total token spend rather than one response in isolation.