Model-agnostic: swapping providers

The memory, the gate and the audit do not depend on which model answers. How a model is chosen per request, bringing your own provider key, running against a model on your own infrastructure, and using the platform with no model at all.

Where the model sits

Identity, memory, access and the record live below the model. The model is a compute engine the platform calls with a context it has already gated, and it can be swapped per request, per application or per deployment without touching anything stored. That is the design, not a feature: the self of a system should not depend on which intelligence is plugged into it this quarter.

No model at all

A memory-profile key reaches memory, documents, threads, clearances, custody and learning, and never calls a model. Your application retrieves through the gate and prompts whatever it likes. Only embeddings are computed by the platform, and the key is metered on storage actions, not tokens.

Choosing a model per request

POST /api/ai/chat   {"message": "...", "model": "claude-sonnet-5-5", ...}
→ {"response": "...", "model_used": "claude-sonnet-5-5", "model_downgraded": {requested, served, reason}?}

The order is: the model on the request, then the application's default, then the platform default. A plan tier can downgrade a request to a model it covers; when that happens the response says what was requested and what served. Routing is by model-id prefix:

The stream (/api/ai/chat-stream) reports the model on its first event and, on done, the turn's token counts and list cost, with a byo flag when your own key paid for it. A consumer reselling chat strips that before relaying.

Bring your own provider key

POST   /api/user/api-keys/{provider}        {"api_key": "sk-..."}     provider: openai | claude | gemini | deepseek | mistral
POST   /api/user/api-keys/{provider}/test
GET    /api/user/api-keys/status             {provider: {has_key, preview, created_at}}
DELETE /api/user/api-keys/{provider}

With a key stored, calls to that provider's models go out under your account and are not metered as platform tokens. Keys are stored encrypted and shown only as a preview afterwards.

A model on your own infrastructure

A self-hosted deployment points the platform at any OpenAI-compatible server (vLLM, Ollama, a gateway in front of a fine-tune) and names the prefixes that route to it:

LOCAL_MODEL_BASE_URL=http://inference.internal:8000/v1
LOCAL_MODEL_PREFIXES=llama,qwen,mistral          # any model id with one of these prefixes goes there
LOCAL_MODEL_API_KEY=...                           # optional

Local prefixes are checked before the hosted rows, so a local mistral-… beats the hosted Mistral row. Nothing leaves your network for generation; embeddings, memory and the record are the same code either way. For a regulated deployment this is the condition that makes the rest credible: the platform answers to you the way your own staff do, and the vendor of the model is your choice to make and to change.

One stateless call

POST /api/ai/complete   {"system": "...", "message": "...", "model": "..."?}  →  {"text", "model"}

For back-office drafting that a person approves: nothing retrieved, nothing stored, metered as its own source. Useful when you want the model but not the memory for a particular step.

What stays the same when the model changes

• What is stored, and its labels, grades and history.
• What the asker may see: the gate compiles before the call, whichever model follows.
• The audit row per read and the sources verdict per answer.
• Mandates, escalations and outcomes.

What changes is the quality of the prose and the price of the turn. The platform's own consumers have moved between Claude and OpenAI models several times without a stored memory being touched.

Why this matters. Vendor independence is a condition of a governed deployment, not a convenience: Enterprise RAG with access control.