Your AI keys, not ours.
Kastel sells no AI and never resells inference: your Kastel works with your company’s key, at the provider of your choice, who bills you directly. Only one key is needed, to build: finding is computed inside your Kastel.
Two roles, one key
Your Kastel calls a model for two things, and two only. Build: read your documents, run the organisation interview, synthesise your context - that is what your key pays for. Find: index your pages so search returns the right information - that computation runs inside your Kastel, on a model it ships with, and asks for no key. You can still point it at an external search model if you prefer one: that is a setting, not a requirement.
The key lives 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.
Search, with no key
The search index has its own model, separate from chat. Your Kastel ships it: it runs inside the engine, on your server, with no network call and no key. There is nothing to configure, and nothing more to pay.
Prefer a different search model? That 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 if that model needs one, 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. The rule holds both ways: a Kastel already installed with an external search model keeps it until you ask otherwise. An update never changes your search space on its own.
Without a key, what happens?
What is missing gets said rather than guessed: with no key, each affected function refuses with its reason. On a corpus that is already built, a Kastel with no key at all reads and searches in full; what it cannot do is build. The detail:
Works. Direct reading depends on no model.
Works. The search model is built in: it needs no key. If you pointed your Kastel at an external search model, that model's key is the one required.
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.