Models & providers
Which model providers Dibbla runs, where each one processes your calls, why adding a model is catalog configuration rather than code, and how to pick a model in a workflow.
Every AI call on Dibbla — from a workflow’s agent node, from your own app, from a developer’s laptop — goes through the platform’s AI gateway. The gateway holds one model catalog: the list of models your organisation can pick, which provider serves each one, and where that provider processes the call. This page is the customer-facing summary of that catalog.
Providers and regions
| Provider | Region | Models | What the provider keeps |
|---|---|---|---|
| Berget AI | 🇪🇺 EU — on Berget’s own servers in Sweden | Open models: Qwen, Gemma, Kimi, GLM, Mistral Small | Neither your prompt nor the answer. Berget runs with zero data retention and never trains on your data |
| Anthropic | 🇺🇸 US | Claude: Opus, Sonnet, Haiku | Anthropic’s commercial API terms: inputs and outputs are not used to train models |
| OpenAI | 🇺🇸 US | GPT-5.1, GPT-5 mini, GPT-5 nano | OpenAI’s commercial API terms: inputs and outputs are not used to train models |
The console’s AI usage view shows the same flag next to every call: where that call was processed. — means the gateway cannot say — never a guess.
Pick a Berget model. The call is processed in Sweden and Berget stores neither the prompt nor the answer.
If your organisation stores its own provider key (Organization settings → AI), that key signs your calls to that provider and they go to the provider’s own API, in the region the table names. See Bring your own provider key.
A new model is configuration, not code
A model on Dibbla is a row in the catalog: a short alias such as
berget-qwen3.8-27b or sonnet-5, the provider that serves it, the
provider’s own model id, and its price. Adding a model, swapping the model
behind an alias, re-pricing it or retiring it is an edit to that row. The
gateway reads the catalog on every call, so the change applies from the next
call — no new release of the platform, of your workflow or of your app.
What that means for you:
- The model lists in the console come from the catalog. When a model is added, it shows up in the workflow editor’s model dropdown on its own.
- An alias can outlive a model. When a provider ships a newer version, the alias can be pointed at it, and every workflow that names the alias uses the new model from its next run.
- A retired model is refused, not silently replaced. A call naming it fails before it reaches a provider, so nothing is spent on it.
Prices are not on this page, because they change in the catalog. The console is where you see them, and what each call cost.
Pick a model in a workflow
The agent node — reasoning_agent_function — takes the model as an input.
In the editor, choose it from the node’s model dropdown
(Build a workflow in the editor).
Every catalog model appears as dibbla/<alias>, with Berget’s as
dibbla/berget-….
In YAML, set the same value on the node:
- id: reasoning_agent_function
type: function
function: reasoning_agent_function
server: function-server
inputs:
system_message: "Summarise the meeting in five bullet points."
model: dibbla/berget-qwen3.8-27b
outputs: [response]Switching provider is changing that one line; the rest of the workflow stays
as it is. dibbla wf validate refuses a model that is not in the list, so a
typo is caught before the run (YAML schema).
Berget serves the chat-completions format only. On a Berget model the agent node runs with tools, but not with file inputs, conversation threads or structured output — the run is refused up front rather than half-done. The other agent functions take OpenAI and Anthropic models.
From your own app, name the same alias on the provider’s path of the gateway,
for example model="dibbla/berget-qwen3.8-27b" with an OpenAI SDK pointed at
$DIBBLA_AI_GATEWAY_URL/berget/v1. Give your app AI
covers the setup.
Sub-processors
Every provider above is a sub-processor when your organisation uses it. The authoritative list — purpose, location and legal safeguard for each, and when it applies — is Dibbla’s Sub-processor List, which is part of the Data Processing Agreement.