Providers

Omegon treats provider authentication as a runtime boundary, not just a login convenience. The active provider affects routing, allowed entry points, quota semantics, and what the operator sees in the engine footer.

Provider authentication

The running contribution registry is authoritative for available providers. The examples below describe common authentication postures rather than an exhaustive provider or model inventory. A declared provider is not necessarily executable: route resolution still needs an executable contribution, accepted credentials or a declared local posture, and a constructible bridge.

OpenRouter Ox Alpha preview

The embedded OpenRouter inventory and curated model menu includeopenrouter:stealth/ox-alpha. OpenRouter describes Ox Alpha as a free stealth preview for coding, sustained agentic work, and complex reasoning, with a 1,048,576-token input context and 131,072-token output limit. It accepts text, image, and video input, returns text, and supports function calling.

The underlying developer and operator are intentionally anonymous during the preview. Although the model listing currently says retained content is not used for training, OpenRouter's governing Stealth Program EULA says user content may be collected, shared, retained, and licensed for Stealth Model training, evaluation, and improvement. Do not send sensitive or restricted data. Treat this as a distinct broker route rather than inferred equivalence with another model family.

Route state and remediation

Omegon keeps the operator-selected route separate from the model bridge that is actually serving turns. That distinction matters when credentials expire, a rebuilt binary discovers external OAuth state, or a profile permits an explicit fallback provider.

• Selected route is the provider/model the operator or profile requested.
• Serving route is the authenticated provider/model that receives the request.
• Interactive fallback is credential fallback at startup, scoped by the ordered fallbackProviders = ["provider-id"] list. The selected contribution must also declare directed, model-family-bounded compatibility with the serving provider.
• Disconnected means no valid credential or allowed fallback is available; Omegon surfaces remediation instead of pretending another provider is active.

An empty fallbackProviders list does not authorize substitution. Compatibility is directed and non-transitive: if provider A declares B, that does not authorize B to use A or A to reach a provider declared only by B. Sessionless callers do not inherit the interactive list. Ordinary sessionless resolution may follow only fallback compatibility declared by the selected contribution; exact resolution probes only the selected provider.

Use /auth status when startup or login looks wrong. It reports route state, credential diagnostics, and the next remediation step. The TUI footer also preserves route warnings so a fallback or disconnected startup is still visible after the immediate login/status message scrolls away.

Authentication and credential evidence

A provider contribution declares an authentication class such as API key, OAuth, API-key-or-OAuth, OAuth token exchange, credentialless local, or optional-key local. This is a compatibility constraint, not a secret and not proof that a usable credential exists.

Before dispatch, the route lease records a bounded credential-source class such as environment, stored, external, or secrets manager. When a more specific source is unavailable, it may record the contribution's authentication class. This evidence never contains secret material and does not promise one exhaustive credential lookup order. Provider identity, selected route, serving route, and upstream limit telemetry remain distinct fields.

Retry and fallback are different

A provider-request retry repeats request handling on the captured serving route. Fallback resolves a different declared-compatible serving provider while retaining both selected and serving route identities and a bounded reason. Neither state authorizes replay of a tool or privileged invocation whose completion became unknown after owner handoff.

Anthropic subscription boundary

Anthropic/Claude subscription auth is the one credential class with an explicit operator-risk boundary. Interactive TUI use is allowed. Headless Anthropic paths warn and proceed rather than silently switching providers or pretending subscription OAuth has API-key automation semantics.

The consumer terms page is here:anthropic.com/legal/consumer-terms

Practical guidance

• If you want to work in the TUI by hand, Anthropic/Claude OAuth is a valid path.
• If you want unattended or scripted automation with clean provider terms, configure ANTHROPIC_API_KEY.
• If you want GPT-family routing without API-key setup, try omegon auth login openai-codex.
• If you want local-only inference, use Ollama (Local).
• If you want hosted Ollama without running a local daemon, use Ollama Cloud via /auth login or /secrets.
• If you want predictable automation with commercial API terms, prefer API-key-backed providers.

How this fits the rest of Omegon

The provider layer feeds the TUI, slash commands, smoke paths, and cleave orchestration. That means auth mode affects not just model access, but which entry points Omegon can honestly and safely expose.