orbi

Models and providers

Adding an API key, working without interruption on several keys, the list of usable models and which model gets picked.

Providers

Orbi supports four LLM providers.

Provider Notes
Anthropic The Claude model family
OpenAI The GPT model family
Google The Gemini model family
OpenRouter Access to many providers with a single key

Ollama also runs on the server, but only for producing embeddings (semantic duplicate prevention).

You can work without entering a key. If you have added no API key at all, agents are served from Orbi's shared pool (Gemini) and usage comes out of your credit. If you add your own key (BYOK), that provider's cost is billed straight to your own account and the same work spends far less credit. Your own key always comes first. If no reachable model is left, you see a standing band in the interface, and it is there so you can see the situation without waiting for a task to fail.

Working without interruption on several keys

You can add more than one key for a provider.

  • Requests are handed out among the keys round-robin.
  • If one key hits a quota or rate limit, the system switches to another automatically.
  • Keys are stored encrypted with AES-256-GCM.
  • You can test a key you entered without saving it.
  • You can disable a key without deleting it. The key leaves the pool and the model lists, but its record and its model probe results are kept, so enabling it again takes effect immediately.

In a busy workspace, adding a second key removes most of the errors caused by rate limits.

The pool rotates inside a single provider. The run's model decides the provider, so a run on a Gemini model tries only your Google keys. If all of them fail the run stops, and Orbi does not move to another provider's key on its own. The error message names the model and the provider it is tied to. To run on another provider's key, choose one of its models on the agent, on the flow or as the workspace default.

The dynamic model catalog

The model list is not hard-coded, it is synced daily from the providers' model-listing endpoints. Four things follow from that.

  • When a provider releases a new model it appears in the list with a "new" badge, so you do not have to wait for an update.
  • The tier is derived automatically and comes out as flagship, standard or light.
  • A model that leaves the catalog is not deleted, it is marked inactive. So your existing agent definitions that refer to that model do not break.
  • Whether a model supports images is recorded in the catalog too, and reading images uses this (Files). If a provider refuses an image, that model receives no images for 7 days and is retried automatically when that period ends. A temporary error never switches a model's image support off for good.

Which models are enabled: your key decides

Every model a provider lists does not mean it will work with your key. So when you add a key, Orbi actually calls every model of that provider one by one. Models your key cannot call are not hidden from the pickers: they appear dimmed and unselectable, with a short note saying why. "Where did my model go" never goes unanswered, and a previously saved choice keeps showing in the list.

There is a real measurement behind this. On the free tier with a Gemini key the provider listed 24 models, and only 10 of them could be called.

Why it is ruled out What it means What you can do
No quota Your key's tier has zero quota for this model (a permanent 429) Turn on billing at the provider, then Try again
Model closed The model is retired or is not opened to new keys (404) Pick another model
No tool calling The model does not support function calling This model cannot be used in Orbi, because every agent run uses tools
Unauthorized The key is not authorised for this model Check the permissions on your provider account

The probes are made with a tool call. The reason is this. Every agent run in Orbi uses tools, so a model that works in chat but cannot call a tool is unusable in practice. It is more helpful for such a model to stay off the list than to appear there and stop on the first run.

You can see the results on the Settings → API Keys → Models screen, and next to each key it says how many models are usable. The list is refreshed daily, and also when you press "Connection test" or "Try again". The probe runs in the background and results drop into the list model by model, so you can keep the window open and watch. The strongest and newest models are probed first. If the probe traffic itself hits the provider's per-minute rate limit, that does not count against the model. It is retried after a short wait, and a per-minute limit is taken as proof that the model is reachable.

This probe also feeds automatic selection. If you have picked no model, the system chooses among the models your account can really use. That way you do not fall back to a model you have no quota for.

Model resolution order

Which model a run uses is resolved in this order.

message/flow override  >  the agent's model  >  workspace default  >  automatic choice

Spelled out, it works like this.

  1. If you picked a specific model for that chat message or flow, it is used.
  2. If you did not, the agent's own default model takes over.
  3. If there is none, the workspace default is used.
  4. If there is none of these, the system picks a suitable model.

There is no separate model picker in the task creation dialog. A task assigned to a person runs no model, a task assigned to an agent already uses the agent's model, and a task assigned to the Orchestrator falls back to the workspace default. This lets you set up a strategy like "use a cheap model in general but give this agent the best one" from a single place, the agent's settings.

Which tier when

Tier What for
light Classification, format conversion, short summaries and tagging, which are high-volume, simple work
standard Most work, such as writing reports, analysis and research summaries
flagship Multi-step reasoning, complex planning and output where quality cannot be compromised

Making the Orchestrator flagship and the sub-agents standard is a common and efficient arrangement. Planning quality affects the whole job, while individual steps come out well enough on a cheaper model.

Models that cannot use tools are marked in the list

Orbi does its work by calling tools, not by writing text. Some models do not support tool calling at all; you can talk to such a model, but it cannot create a table, a flow or a task.

These models are not removed from the list — if your provider offers them, you see them — but no tools appears next to their name. The marker stays after you pick one, so the answer to "why is nothing being built" remains visible.

Orbi never changes your chosen model on its own. A stronger model costs more and that decision is yours; making it for you would mean spending your credits without asking.

Seeing the cost

The Dashboard shows usage and cost totals. The token breakdown by model and by agent covers the last 30 days. The spend badges give two periods separately, this month and all time. You can see what a single task spent from the card's Trail tab, which shows which agent, which model, how many tokens, and whether a fallback kicked in.