Providers and models

Sentinel separates provider setup from model setup.

It helps to understand that split early.

ProvidersCopy Anchor Link

A provider is the connection layer. This is where Sentinel stores credentials, encrypted config, and the basic enabled or disabled state for that connection.

The providers screen is where you connect, edit, enable, disable, or remove a provider. Keeping that layer separate from the model catalog makes the rest of the setup easier to reason about.

What providers are supportedCopy Anchor Link

Current provider support includes OpenAI, Anthropic, Google AI Studio, Google Vertex AI, xAI, Azure OpenAI, Amazon Bedrock, Groq, Cohere, Moonshot AI, Mistral, DeepSeek, Ollama, OpenRouter, and Vercel AI Gateway.

ModelsCopy Anchor Link

The models screen is where you manage what models are available once a provider is connected. That includes built-in catalog entries, enabled and disabled state, custom model IDs where that makes sense, and capability labels. Agent models live with each engine instance in Settings → Engines instead.

This split is useful in practice. You might have a provider configured correctly but still only want a couple of models visible in the picker. Or you might want to keep a provider around while disabling it for a while. Sentinel treats those as separate decisions.

Connected vs enabledCopy Anchor Link

In Sentinel, a configured provider and an enabled model are two different things.

You can connect a provider, disable it later, leave some models enabled and others disabled, and add custom model IDs where supported. Once that split is clear, the setup screens feel a lot less confusing.

EnginesCopy Anchor Link

Providers and models feed the sentinel engine, the app-managed runtime.

The other engines are local coding agents: Claude, Codex, Copilot, Cursor, OpenCode, Grok Build, Antigravity, Pi, and agents from the ACP Registry. They sign in with their own accounts and bring their own models, so they do not use the providers configured here.

Their models come from three places, merged per engine instance:

• the models the agent itself reports
• Sentinel's engine manifest, which fills in defaults, context windows, and option labels, and lists models for agents that report none
• custom models you add to the instance, for model IDs the agent accepts but does not list

This is why engine choice changes more than the label in the model picker. Codex threads can carry sandbox mode, approval policy, and a linked Codex thread ID. Claude threads carry their own session state. ACP agents carry a session, mode, and config values. The engine changes what kind of runtime is attached to the thread, not just which model name appears in the UI.

See the engines overview for instances, sign-in, and usage limits.

Good next readsCopy Anchor Link

The next useful pages here are Search, voice, images, and videos, Memory, security, and data, and Engines, providers, and integrations.