Getting started
Begin by identifying the tool you want to connect: Cursor, Claude Code, or Codex. Request early access with a short description of your workflow and any constraints on external processing. Access and connection support need confirmation before use; submitting the website form does not sign you into a service.
Prepare a representative, non-sensitive task that you can verify independently. Note your current model workflow and a baseline for token spend if available. During onboarding, confirm the supported connection, available local capability, cloud permissions, and the way to review routing behavior. This checklist is preparation, not a sequence of installation commands.
Routing terminology
A route is the path a request takes to a model tier. A tier groups models by their intended role in the capability and cost tradeoff; it is not a named provider. Local describes processing on your machine when a suitable model is available. Efficient cloud describes cost-conscious cloud capability. Frontier describes the most capable tier reserved for demanding work.
Escalation means moving to a tier with more capability when needed. Local-first means local is the starting preference; it does not mean local-only. A workload is the set of tasks you evaluate together. Token spend is one part of the cost of completing those tasks and should include additional attempts when comparing results.
Integration overview
Choose the tool that already fits your work. In Cursor, focus first on context supplied from the editor and a small reviewable change. In Claude Code, define the investigation, permitted actions, and project checks. In Codex, establish the task scope and acceptance criteria before reviewing the resulting patch.
The integration pages explain representative workflows and onboarding questions. They do not document a verified endpoint, SDK, configuration file, or command. Tool versions and environments can differ. Confirm the actual supported connection through access support rather than modifying settings based on a conceptual example.
Model-tier behavior
The routing approach begins locally, uses efficient cloud when more capability is needed, and reserves frontier models for the hardest problems. A contained explanation may be a local candidate. A connected refactor may fit efficient cloud. A migration plan with competing constraints may justify frontier reasoning.
These examples do not establish deterministic rules. Context quality, model availability, and task requirements matter. There is no published threshold or retry algorithm on this site. Ask which route behavior and controls apply to your actual environment before relying on them, particularly if cloud processing is restricted.
Reading the illustrative interface
The homepage preview uses example requests to explain the routing concept. “Routed to” names a tier; “Status” represents completion in the example; cost and time show how request-level information might be presented. The model-mix bar illustrates how a collection of requests could be distributed across tiers.
All preview metrics are illustrative. They are not live account data, benchmark results, expected latency, or a promised distribution. A local cost shown as $0.000 refers to the example cloud-token cost and does not establish that local computing has no resource cost. The preview is not an operational account console.
Concepts versus configuration
Before connecting, establish three decisions: whether a suitable local route exists, whether cloud escalation is permitted for the work, and when the cost of frontier capability is justified. Those decisions explain the product approach; they are not names of configuration keys.
No executable configuration is provided on this website. Do not copy descriptive labels into tool settings or assume an illustrative control is available in your account. Confirm the supported settings, processing boundaries, and connection procedure during onboarding. Never share API keys or passwords through an access or support form.
Troubleshooting a routing evaluation
If a result is incomplete, first check whether the request includes the relevant context and a clear desired outcome. Missing code, unstated constraints, and ambiguous acceptance criteria can weaken any model’s response. Reduce the problem to a bounded example you can assess.
If the local route is unavailable or unsuitable, confirm the environment and available models with support. If cloud use is restricted, do not work around that restriction to complete a test. If savings are lower than expected, compare workload mix, repeat attempts, prompt sizes, and how often frontier capability was required. An isolated request is not a reliable savings baseline.
Support and next steps
For access questions, include the coding tool, your operating environment, and a brief description of what you want to evaluate. For a workflow issue, explain expected versus observed behavior and what you have already checked. If useful, include a short sanitized example without confidential code or personal data.
Use the contact page for support and the early-access page for a new account request. Never submit passwords, API keys, access tokens, or unredacted logs. There is no response-time guarantee published here. For broader context on responsibilities and information handling, read the Terms of Service and Privacy Policy.