Two keys, two roles
Your Kastel calls a model for two things, and two only. Build: read your documents, run the organisation interview, synthesise your context. Find: index your pages so search returns the right information. They are two separate providers in the configuration - they can be the same one, but nothing forces it, and some chat providers have no search model.
The keys live in your deployment’s .env file, never in a versioned file, never with us. You decide what each AI is allowed to see; what your key sends to the provider is governed by the contract you have with them.
The build key
In your deployment’s .env:
For the default OpenAI address, that is all (the default model is gpt-4o-mini). For any other OpenAI-compatible address - Mistral, DeepSeek, a self-hosted vLLM - add that address and the model:
The variable name does not change with the provider: it is the key for whatever OpenAI-compatible address you point at.
The search key
The search index has its own model, separate from chat. The default is Mistral (mistral-embed, a European provider):
Changing the search model is a configuration move, not code: the retrieval.embeddings block of kastel.config.yaml (provider, model, dimension - the documented alternatives are listed as comments in the file), the matching key in .env, then:
The whole corpus is re-indexed on the new model: two search spaces are never blended. Until the reindex has run, search refuses with an explicit message rather than mixing old and new.
Without a key, what happens?
What is missing gets said rather than guessed: with no key, each affected function refuses with its reason. The detail:
Works. Direct reading depends on no model.
Requires the search key (or a local search model): every query is projected into the index by the model.
Requires the build key.
log_trace)Refused, always. See below.
A trace is free text an agent wrote about a real working session: before anything is written, your Kastel classifies it to keep personal data out of the company memory. No key means no classifier - and the choice is to refuse the write rather than write unclassified content. There is deliberately no setting to turn this gate off: a switch that disabled it would be a switch that writes unclassified personal data to disk. The same caution applies when the key exists but no longer answers (revoked, quota reached): classification fails on the safe side and the content concerned is set aside, without a loud error. A broken build key is worth monitoring.