Complexity Tiers & Routing

Orbit is model-agnostic. The way it stays that way is a layer of indirection: prompts carry an abstract complexity tier, and you map each tier to a concrete agent and model in settings. Change the mapping and every future prompt re-routes without you touching a single prompt.

The tiers

The standard tiers are Low, Medium, High (UI), High (Backend), and Coordinator. As a rule of thumb:

• Low — routine tasks, documentation updates, and minor fixes that don’t change business logic or security.
• Medium — significant logic changes, new features, and refactors that deserve a review.
• High — structural changes, security-critical modifications, and system-wide architecture shifts.
• Coordinator — the model that decomposes a large task into parallel subtasks (see Coordinator Mode).

Routing under Settings → Model Tiers & Agents

Each tier routes to a specific agent and model, with its own effort level and authentication — a Claude Max subscription via OAuth, or an API key. At least one agent must be registered before any prompt can run. This is also where you choose the fallback model a tier drops to when its primary model hits a quota wall.

complexity vs. model

Tag a prompt with complexity: to route through the tier config, or model: to override and name a model directly. They are mutually exclusive — if you include both, complexity wins and model: is ignored, which silently isn’t what you meant. Pick one. Use complexity: by default and reserve model: for deliberate one-off overrides.

Local and custom models

Any tier can route to a local or custom OpenAI-compatible endpoint — DeepSeek, MiniMax, Ollama, LM Studio, or a custom base URL — alongside the cloud providers. When a tier runs through this API executor, the agent gets a curated, safe subset of Orbit’s tools (file reads, shell, git, context) and is blocked from the sensitive ones (vault, deploy, billing).

Next

• Connect a Coding Agent
• Quota & Cost Monitoring