Your models, your choice: plug in Claude, Codex, Ollama, or any OpenAI-compatible endpoint — or go fully local. The model layer is a choice, not a constraint.
Four interchangeable runtimes
| Runtime | Models | Where inference runs |
|---|---|---|
| Claude (default) | Anthropic models via Claude Code | Anthropic API |
| Codex | OpenAI models via Codex | OpenAI API |
| Ollama | Any Ollama model | Any endpoint you configure — local, LAN, self-hosted, or Ollama Cloud |
| OpenAI-compatible | vLLM, Together.ai, and similar | Any endpoint you configure — local or remote |
From the companion's point of view, runtimes are interchangeable: same memory, same tools (files, shell, web, integrations), same skills, same permission gating, same collaboration features. Switching provider doesn't reset who the companion is.
Reuse the subscriptions you already pay for
No separate API billing required. tamag0 signs in to the accounts you already have:
- Claude — sign in with your Claude account (OAuth): usage runs on your Claude subscription. An Anthropic API key works too, if you prefer metered billing.
The desktop uses Claude Code's standard sign-in flow, so reauthentication is the same account flow as signing in from Claude Code itself. If the installed Claude Code is too old to provide that flow, tamag0 asks you to run
claude updatebefore retrying instead of attempting an unsupported login. - Codex — sign in with ChatGPT: usage runs on your ChatGPT Pro or Plus subscription quota, not OpenAI API credits.
At every launch, the desktop updates Claude Code and Codex CLI in the background. If an update is unavailable or fails, tamag0 still starts normally.
Codex models
On Auto, Codex turns use three GPT-6 models with a Low, Medium, or High reasoning effort (Luna runs at Medium or High):
| Model | Suited to | Manual efforts | Default effort |
|---|---|---|---|
| GPT-6 Luna | Short, targeted tasks at low cost | Low to Max | High |
| GPT-6.1 Sol | Everyday development and code review | Low to Ultra | High |
| GPT-6 Astra | The most demanding professional work | Low to Ultra | Medium |
A new conversation starts on GPT-6.1 Sol at High, and so does a conversation with several participants, unless someone picks a model. After that, the companion re-evaluates the model and effort its work needs at each response. The X-High, Max, and Ultra efforts, and the GPT-5.6 Sol, Terra, and Luna models, are manual choices only.
GPT-6.1 Sol replaced GPT-6 Sol at the same price per token: conversations on GPT-6 Sol move to GPT-6.1 Sol automatically. It needs Codex CLI 0.159.1 or newer; with an older CLI, tamag0 asks you to update it from Settings → LLM Providers → ChatGPT instead of starting the turn.
If your team already pays for Claude and ChatGPT, your companions run on those plans from day one — zero additional inference budget to negotiate before trying tamag0.
Fully local when you want it
With Ollama or a self-hosted OpenAI-compatible endpoint, inference never leaves your infrastructure — for companies that need complete control. Local endpoints can be keyless; cloud endpoints keep their keys in the OS keychain.
Per-agent choice and automatic fallback
- Each companion can have its own runtime and model — a coding companion on Claude, a triage companion on a local model.
- A runtime priority order tells Auto which configured providers to try. Before execution, tamag0 skips providers that cannot be used locally, such as a missing or signed-out CLI, a disabled runtime, or an incomplete custom-provider configuration. These preflight skips are not runtime attempts and do not appear in the attempt history.
- Runtime fallback is narrower than preflight availability. During an Auto turn, tamag0 continues to the next configured provider only for a recognized Claude or Codex quota/session exhaustion, or an HTTP 429 from Ollama or an OpenAI-compatible provider. It does not infer exhaustion from ordinary assistant prose.
- Authentication, network, timeout, HTTP 5xx, context-window, cancellation, and unknown failures stop the turn. They do not start another provider. In particular, a network failure is never treated as automatic fallback.
- When a capacity failure happens after visible output or a tool action, tamag0 keeps the ordinary conversation history, persists visible partial output when there is any, and starts the successor with a short internal continuation instruction. It never mechanically replays a completed tool. A durable switch notice records the provider change.
- Capacity failures create a per-companion, per-provider cooldown that survives desktop restart. An explicit provider reset time wins; otherwise tamag0 uses a valid
Retry-Aftervalue, and falls back to five hours when neither is available. Expired cooldowns are removed automatically. - Automatic fallback applies only while the composer is on Auto. An explicit provider or model pin stops on failure. Retry bypasses that provider's cooldown for one attempt only and never starts a fallback cascade; Switch to Auto and retry returns control to the configured priority order.
- Your global priority and per-companion overrides follow your account to another device after restart. Local choices keep working offline; if an offline change could not be saved, the account's last saved choice is restored at the next online start.
- Provider availability is resolved dynamically from what is actually installed and authenticated — the app never forces a default you don't have.
- Adding an Ollama or OpenAI-compatible provider lets you fetch its model list and pick the models to add. On a provider you already saved, fetching reuses the saved key — you don't retype it, and it is never sent to the interface. A company can also declare custom providers and models shared across its companions.
Right-sized execution
Model and effort are selected per task: routine work runs on lighter, faster settings; deep architecture or debugging work gets the strongest model and higher reasoning effort. Cost stays proportional to task complexity — and both onboarding installs (Claude and Codex) are set up out of the box so the choice stays open.
Related
- Performance — token compression and efficiency
- Security — key storage and isolation