Provider Catalog
DUUMBI keeps model choice inside the model catalog and routing policy. Provider credentials stay in provider configuration or credential storage, not in catalog metadata.
Use duumbi provider ... commands or the REPL provider setup surface for
configuration. Users should not need to choose and maintain default model IDs
for normal provider setup.
Accepted V1 direct providers
Section titled “Accepted V1 direct providers”| Provider | Config key | Environment variable |
|---|---|---|
| Anthropic | anthropic | ANTHROPIC_API_KEY |
| OpenAI | openai | OPENAI_API_KEY |
| xAI | xai | XAI_API_KEY |
| MiniMax | minimax | MINIMAX_API_KEY |
| DeepSeek | deepseek | DEEPSEEK_API_KEY |
| Alibaba Cloud Model Studio (Qwen) | qwen | DASHSCOPE_API_KEY |
| Moonshot AI (Kimi) | moonshot | MOONSHOT_API_KEY |
| Zhipu AI (GLM) | zhipu | ZHIPUAI_API_KEY |
| Google Gemini | gemini | GEMINI_API_KEY |
xai is the canonical config key for xAI/Grok models. Existing grok
configuration is compatibility-only legacy input and should not be used in new
examples.
OpenRouter is excluded from the V1 direct-provider catalog because it is an aggregator surface rather than a stable direct-provider target.
Config shape
Section titled “Config shape”[[providers]]provider = "anthropic"role = "primary"api_key_env = "ANTHROPIC_API_KEY"
[[providers]]provider = "minimax"role = "fallback"api_key_env = "MINIMAX_API_KEY"The provider catalog and routing policy choose concrete model IDs. Keep credentials in environment variables or credential storage, not in docs, catalog metadata, commits, issue comments, or screenshots.
Catalog artifacts
Section titled “Catalog artifacts”The V1 catalog is published as static deterministic artifacts:
The JSON artifact includes schema version, content timestamp, source provenance, accepted provider metadata, provider discovery status, routing metadata, and a user-facing change summary. Run-specific workflow evidence stays outside the JSON catalog so scheduled publication does not change the semantic adoption hash when catalog inputs are unchanged.
Local catalog state
Section titled “Local catalog state”A refreshed catalog is user-level installation state:
~/.duumbi/model-catalog/current.json~/.duumbi/model-catalog/current.sha256~/.duumbi/model-catalog/state.jsonThe client checks the remote hash first and stays quiet when the installed, skipped, deferred, or disabled state means no useful user action exists.
Approval revalidates the reviewed hash, downloads the catalog, verifies SHA-256, validates schema/provider/model fields, and writes the catalog atomically. Hash mismatch, unsupported schema, invalid provider/model entries, download failures, offline startup, and partial writes fail closed and keep the previous local catalog or embedded catalog active.