Models

DioscHub does not ship a model of its own — it runs on the LLM providers you bring. You register a provider’s credentials once, list the models you want available, and then each Assistant picks one of those models. DioscHub supports OpenAI, Anthropic, Azure OpenAI, Google, AWS Bedrock, Ollama, and any OpenAI-compatible endpoint.

Register a provider credential

A provider credential is a named record — “Production OpenAI”, “Azure — East US” — holding the provider type and its connection details (API key, base URL, deployment, and so on). Create one in the admin portal (or POST /admin/llm-provider-configs).

Credentials are write-only over the API

The admin API never returns a stored secret. When you read a provider credential back, each secret field comes back as a boolean “is set” flag, not the value — so a key can be set and updated but never exfiltrated through the API. For those secrets to be encrypted at rest, configure the credential master key described in the production hardening checklist.

You can validate a key before you rely on it: DioscHub can run one minimal completion against the provider to confirm the credential works.

List the models you want available

A model entry names a specific model — gpt-4o, a Claude model, a Gemini model — and records what DioscHub needs to route and budget it: its provider, its context window, its maximum output, and its per-token cost for usage accounting. Add the models you intend to use (POST /admin/models), and optionally link each one to a provider credential you registered above.

How DioscHub finds the credential for a model, in order:

1. The provider credential linked to that model, if you set one.
2. A shared credential registered for that provider.
3. The provider’s environment variable (for example OPENAI_API_KEY), as a fallback.

Note

When you export configuration to another environment, model entries travel without their credential link and without any secret — DioscHub never moves credentials between environments. Re-register the provider credential on the target and re-link it there. See configuration transfer.

Choose a model per Assistant

Each Assistant selects its model in llmConfig:

Field	What it controls
model	The model id to run — this is what picks the provider and credential at run time.
maxTokens	A ceiling on tokens generated per turn (capped further by the model’s own maximum).
reasoningEffort	How hard a reasoning-capable model thinks: minimal, low, medium, or high.
temperature	Sampling temperature — best-effort; reasoning models ignore it (below).

The model id is the selector. DioscHub looks up that model to decide which provider and credential to use — so pointing an Assistant at a different provider is a matter of choosing a model that belongs to it. If an Assistant has no model set, it falls back to the deployment’s environment defaults.

Reasoning models need room to think

reasoningEffort turns on a model’s internal reasoning, and DioscHub maps it to each provider’s own control (extended thinking on Anthropic, reasoning effort on OpenAI and Azure, thinking level on Google). Two consequences to plan for:

• Reasoning consumes your token budget. The thinking a model does counts against maxTokens. Set maxTokens too low and the reasoning eats the budget before any answer is produced, and the reply comes back truncated. Give reasoning models generous headroom.
• Reasoning models ignore temperature. When reasoning is active, the provider fixes sampling itself and your temperature is not applied. Treat temperature as effective only on non-reasoning models.

---

Next: Knowledge bases.