Skip to main content
Reliant uses a tag-based system for model selection that lets workflows declare what kind of model they need rather than which specific model to use. When a workflow requests a flagship model, Reliant automatically selects the best available option from your configured providers—Claude Opus if you have Anthropic configured, GPT Codex if you have OpenAI or Codex configured, or whichever flagship model is available. This abstraction provides powerful flexibility. Your workflows continue to work even when you switch providers, add new API keys, or when better models become available. A workflow that requests tags: [flagship, reasoning] adapts automatically to your environment without any changes. You can customize this behavior in your global config at ~/.reliant/config.yaml by changing which models are preferred for each tag, adding custom models such as local models running through Ollama, and configuring provider endpoints.
Note: Model configuration lives in ~/.reliant/config.yaml rather than project-level config, and it is read on the machine where your agents’ tools run. Each machine has its own file, so a cloud machine is configured separately from your laptop, and every project on a machine shares one model configuration.

​
Understanding Tag-Based Selection

Tags describe characteristics of models rather than naming specific models. When you specify a model selector with tags, Reliant finds models that match all the specified tags, then selects the first available one according to priority order.
This selector matches any model tagged with flagship. Reliant checks each matching model in priority order and uses the first one for which you have a configured provider.

​
Available Tags

Each tag represents a distinct characteristic. Models can have multiple tags. flagship identifies the most capable models from each provider—those with the deepest understanding, best reasoning, and highest quality outputs. These models excel at complex tasks requiring nuance, multi-step reasoning, or expert-level knowledge. Use flagship for important code changes, architectural decisions, or anything where quality matters more than cost. moderate identifies models that balance quality and cost effectively. These models handle most everyday development tasks well—implementing features, fixing bugs, and writing tests—at significantly lower cost than flagship models. This is often the best choice for routine development work. fast identifies models optimized for quick responses and high throughput. Fast models handle simple tasks efficiently such as quick lookups, straightforward code generation, and basic analysis. Use fast models for iteration-heavy work or when response time matters more than depth. cheap identifies the most cost-effective models available. These overlap significantly with fast models but specifically optimize for low token costs. Useful for high-volume operations like processing many files or bulk analysis where per-request cost adds up quickly. reasoning identifies models with extended thinking capability—the ability to work through complex problems step by step before responding. Request this tag when your task involves complex logic, multi-step planning, or problems that benefit from deliberate analysis. meta identifies models used for Reliant’s internal operations like generating conversation titles and compacting long conversations. You typically do not need to select meta models directly—Reliant uses them automatically for background tasks. local identifies models that run on your local hardware rather than cloud APIs. Models Reliant auto-discovers from your configured local endpoint (see Provider Configuration) receive this tag automatically. A custom model you define by hand needs to be listed under models.tags yourself—see Adding Custom Models.

​
Multiple Tags

When you specify multiple tags, Reliant uses weighted best-match scoring to find the best available model:
How scoring works:
  • Earlier tags have higher weight
  • Models are scored by matching tags and sorted by total score
  • Perfect matches are preferred, but partial matches are used as fallback
Example: [local, fast]
  • Model with both local and fast → best choice
  • Model with only local → fallback
  • Model with only fast → fallback
  • Model with neither → not considered
This enables graceful degradation: workflows can express preferences like use a local model if available, otherwise use any fast model, without failing when local models are not configured. Tag order matters:

​
Customizing Tiers

Under the hood, each tag is not just a list of models—it is an ordered list of {model, thinking_level} entries. Selecting a tier picks both a model and the effort it thinks at in one step: tags: [flagship] might resolve to Claude Opus 5.5 running at high effort, while tags: [moderate] resolves to Claude Opus 5 running at medium. Reliant walks the list in order and stops at the first entry whose model you have a configured provider for. You can override this ordering—and the effort each entry runs at—by specifying your own entries for any tag in ~/.reliant/config.yaml:
Your entries are prepended to the built-in list for that tag—they never replace it. The built-in entries stay behind yours as the fallback, so naming one preferred model never strands you without a flagship model at all if that provider isn’t configured. When a workflow requests tags: [flagship], Reliant tries your entries first, in order, then falls through to the built-ins for any model you didn’t mention. If you list a model that already appears in the built-in list for that tag, your entry wins outright: it takes your position in the order and your effort, and the built-in copy of that entry is dropped (a model can only ever be reached through its earliest, highest-priority listing). This is also how you retune a built-in tier’s effort without touching anything else—list the same model with a different thinking_level and nothing else about the tier changes.

​
Partial Overrides

You do not need to list every model for a tag. Any built-in models you don’t mention keep their default position, right after your entries:
Every model you name in tags: must exist—either as a built-in model or as one of your own custom models (see below). An unknown model ID, an unrecognized thinking_level, or the same model listed twice under one tag is a hard error at config load: Reliant refuses to start rather than silently ignoring the typo.

​
Thinking Effort Per Tier

The thinking_level on a tag entry is the effort a request runs at when it resolves through that entry and the caller didn’t already ask for a specific level. It’s an aspiration, not a requirement—Reliant clamps it down to whatever levels the model actually supports, so setting xhigh on a model that tops out at high quietly runs at high instead of erroring or sending an unsupported value to the provider. You can omit thinking_level entirely, as the fast tier does above. In that case the model runs at its own capability default (medium for models that support extended thinking). This is also what happens when a workflow selects a model directly by id: instead of by tag—explicit ID selection has no tier to inherit an effort from, so it always gets the model’s capability default. Because effort lives on the tag entry rather than on the model, the same model can serve more than one tier at different efforts—list it under each tag with the thinking_level that tier should run at. Each tier is tuned independently: Reliant’s built-in catalog runs flagship on Claude Opus 5.5 at high for orchestration, and moderate on Claude Opus 5 at medium for implementation, where it makes edits faster.

​
Adding Custom Models

You can add custom models for local providers like Ollama, LM Studio, or any OpenAI-compatible endpoint. Custom models carry no tags of their own—a custom model joins a tier by being listed under models.tags, exactly like retuning a built-in tier.

​
Local Model Example

To add a local CodeLlama model running through Ollama and make it available under the local and fast tags:
Field notes: id is a unique identifier you use to reference this model. The ID must not conflict with built-in model IDs. name is the human-readable name shown in the UI. Custom models have no tags: field of their own—list the model’s id under models.tags for every tier it should serve, as shown above. visibility controls where the model appears:
  • user: shows in the model selector UI
  • meta: used only for internal operations
  • dev: only available in development builds
capabilities describe what the model can do:
  • can_reason
  • supports_tools
  • supports_attachments
  • supports_streaming
  • supports_caching
  • max_context_window
  • max_output_tokens
providers maps the model to API endpoints. Each entry specifies:
  • driver: which provider driver to use
  • api_model: the model identifier sent to that provider API

​
Multiple Provider Mappings

A custom model can have multiple providers for redundancy:
Reliant uses the first available provider. This model uses OpenRouter if configured, otherwise falls back to a local instance.

​
Provider Configuration

Different model drivers need different configuration. Cloud providers such as Anthropic, OpenAI, and Gemini are configured through API keys as described in API Keys. The local driver needs endpoint configuration.

​
Local Provider

The local driver connects to any OpenAI-compatible API endpoint. Configure the base URL in your models configuration:
Common base URLs:
  • Ollama: http://localhost:11434/v1
  • LM Studio: http://localhost:1234/v1
  • llama.cpp server: http://localhost:8080/v1
  • vLLM: http://localhost:8000/v1
The URL should include /v1 if the server requires it, but should not include trailing slashes or endpoint paths like /chat/completions. Reliant’s servers make all model calls, so a local model is reached through a daemon running on the machine that can see the model server (usually your own machine, via reliant daemon start). The prompt and reply are relayed through our servers and stored in your chat like any other; see Privacy & Security.

​
Running Ollama

If you do not have Ollama installed, get it from ollama.ai. After installation:
Then add the model to your Reliant configuration as shown above. Reliant automatically uses your local model when its tags match workflow requirements.

​
Provider Priority

When multiple providers can serve the same model, Reliant prefers native drivers over aggregators. If you have both Anthropic and OpenRouter configured, Claude models automatically use the Anthropic API directly. The priority order from highest to lowest is:
  1. Native drivers: anthropic, openai, gemini, xai, vertexai
  2. Local providers: local
  3. Aggregators: openrouter
Native drivers typically provide better performance, lower latency, and access to provider-specific features like prompt caching. You can override this when needed by specifying a provider explicitly:

​
Complete Configuration Example

Here is a complete ~/.reliant/config.yaml demonstrating all model configuration options:
With this configuration:
  • Workflows requesting [flagship] prefer GPT Codex at xhigh effort
  • Workflows requesting [fast] prefer your local Qwen model
  • Workflows requesting [reasoning] can use your local DeepSeek Coder

​
Validation

Reliant validates your model configuration when it loads. Common validation errors: custom model missing required id field: Every custom model needs a unique ID. custom model has no providers: Every model needs at least one provider mapping. custom model ID conflicts with built-in model: Your custom model ID must not match any built-in model ID. tags references unknown model: A model listed under models.tags does not exist as a built-in or custom model. Check for typos, or make sure the custom model is defined in models.custom. unknown thinking level: A thinking_level on a tag entry is not one of Reliant’s recognized effort levels (e.g. low, medium, high, xhigh). model listed more than once: The same model appears twice under one tag. Only the first, higher-priority listing could ever win, so this fails at load rather than silently picking one. These are hard errors—Reliant refuses to start with an invalid model configuration rather than silently ignoring the mistake.
  • API Keys — Configure API keys for cloud providers
  • Presets — How presets use model selectors
  • Custom Workflows — Use model configuration in your workflows