# How DeepSeek-Reasonix Exposes Multiple Models from a Single Vendor > DeepSeek-Reasonix exposes multiple models from a single vendor using a simple TOML configuration. Publish unlimited models from one provider without code changes for seamless integration. - Repository: [YHH/DeepSeek-Reasonix](https://github.com/esengine/DeepSeek-Reasonix) - Tags: deep-dive - Published: 2026-06-23 --- **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`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/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`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/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`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/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`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/reasonix.toml). Each entry shares the same connection details but specifies a unique `name` and `model` identifier. ```toml # 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`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/serve/serve.go) resolves the provider name, loads the corresponding configuration, and initializes the provider with the specific model identifier. ```bash # 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`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/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`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/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`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/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. ```bash # 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`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/serve/serve.go), each potentially targeting a different model from the same vendor simultaneously. ## Summary - **Provider entries** in [`reasonix.toml`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/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`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/serve/serve.go) to route requests to the appropriate configuration. - **Model-agnostic providers** in [`internal/provider/openai/openai.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/internal/provider/openai/openai.go) and [`internal/provider/anthropic/anthropic.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/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`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/reasonix.toml), allowing granular credential management. ### Does adding a new model require restarting the Reasonix daemon? Yes. Reasonix reads [`reasonix.toml`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/reasonix.toml) at startup through [`internal/config/config.go`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/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`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/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`](https://github.com/esengine/DeepSeek-Reasonix/blob/main/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.