How DeepSeek-Reasonix Exposes Multiple Models from a Single Vendor

Reasonix treats every LLM vendor as a provider and lets you publish any number of models under that provider through the plain-text reasonix.toml configuration file, enabling multiple models from one vendor without code changes.

DeepSeek-Reasonix is an open-source AI agent framework that decouples provider connection logic from model identifiers. This architecture allows you to expose multiple models from a single vendor—such as DeepSeek's flash and pro variants—by simply adding entries to your configuration file, eliminating the need for custom code paths per model.

Provider-Model Architecture

The multi-model capability relies on the ProviderEntry struct defined in internal/config/config.go. Each provider entry encapsulates connection credentials—such as base_url and api_key_env—once, while the specific model field determines which endpoint variant to call.

This separation means you can define multiple providers pointing to the same vendor infrastructure but requesting different model identifiers. The provider factory in internal/provider/provider.go (New(kind, cfg)) instantiates concrete implementations (OpenAI, Anthropic, etc.) using the resolved configuration, passing the model value directly to the request payload.

Configuring Multiple Models in reasonix.toml

To expose multiple models from a single vendor like DeepSeek, add distinct [[providers]] entries in reasonix.toml. Each entry shares the same connection details but specifies a unique name and model identifier.

# reasonix.toml – minimal example

default_model = "deepseek-flash"

[[providers]]
name        = "deepseek-flash"
kind        = "openai"
base_url    = "https://api.deepseek.com"
model       = "deepseek-v4-flash"
api_key_env = "DEEPSEEK_API_KEY"

[[providers]]
name        = "deepseek-pro"
kind        = "openai"
base_url    = "https://api.deepseek.com"
model       = "deepseek-pro"
api_key_env = "DEEPSEEK_API_KEY"

Both entries use the same base_url and API key environment variable, but the model field distinguishes which specific endpoint to invoke.

Runtime Model Selection via CLI

At runtime, the --model flag (or -m shorthand) selects which configured provider entry to use. The flag parsing logic in internal/serve/serve.go resolves the provider name, loads the corresponding configuration, and initializes the provider with the specific model identifier.

# Use the default model (deepseek-flash)

reasonix run "write a function to reverse a string"

# Override the model for this invocation

reasonix run --model deepseek-pro "write a performant quick-sort implementation"

The same provider code path is used regardless of model selection; only the cfg.model value injected into the request JSON differs.

Provider Implementation Details

Concrete provider implementations are completely model-agnostic. In internal/provider/openai/openai.go, the code constructs API requests using the cfg.model field when building the request JSON. The same pattern exists in internal/provider/anthropic/anthropic.go.

Because the provider logic does not hardcode model names, you can add new models from existing vendors simply by updating reasonix.toml—no changes to internal/provider source files are required.

Two-Model Collaboration Mode

Reasonix supports concurrent multi-model workflows through its executor-planner pattern. You can run the planner with one model while the executor uses another, even when both models come from the same vendor.

# Run the planner on a large task with the Pro model,

# while the executor continues with the flash model.

reasonix run --model deepseek-pro --planner-model deepseek-flash "refactor the whole codebase"

This creates two independent provider sessions via internal/serve/serve.go, each potentially targeting a different model from the same vendor simultaneously.

Summary

• Provider entries in reasonix.toml separate connection configuration from model identifiers, enabling multiple models per vendor.
• Zero code changes are required to add new models—simply append new [[providers]] entries with distinct name and model fields.
• Runtime selection uses the --model flag handled by internal/serve/serve.go to route requests to the appropriate configuration.
• Model-agnostic providers in internal/provider/openai/openai.go and internal/provider/anthropic/anthropic.go pass cfg.model directly to API payloads.
• Two-model mode allows concurrent use of different models from the same vendor for specialized task distribution.

Frequently Asked Questions

Can I use different API keys for different models from the same vendor?

Yes. While entries typically share the same api_key_env for a single vendor, you can define separate environment variables per provider entry (e.g., DEEPSEEK_FLASH_KEY and DEEPSEEK_PRO_KEY) and reference them via the api_key_env field in reasonix.toml, allowing granular credential management.

Does adding a new model require restarting the Reasonix daemon?

Yes. Reasonix reads reasonix.toml at startup through internal/config/config.go to build the ProviderEntry list. To expose a new model from an existing vendor, you must restart the process to load the updated configuration.

How does the two-model mode handle rate limits from a single vendor?

Since each model selection creates an independent provider session in internal/serve/serve.go, rate limits apply per session based on the vendor's API constraints. When using two models from the same vendor concurrently, both sessions count against your overall rate limit quota for that vendor's API key.

What provider kinds support multiple models?

All provider implementations—including openai and anthropic kinds handled by internal/provider/provider.go—support multiple models. The architecture is fully model-agnostic, allowing any vendor offering multiple endpoints to expose their full model catalog through separate configuration entries.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}