Model tiers and spend ceilings

Your organization's assistant runs on model credentials your team registers directly — this is the admin-driven onboarding CLAUDE.md describes applied to the one resource nothing else can substitute for. Setting one up is two separate acts.

1. Register — this does not touch the vault

Fill in the provider (OpenAI, Azure OpenAI, Anthropic, Bedrock, Vertex, or an OpenAI-compatible local endpoint), a cheap model id and a strong model id, and the name of a vault entry holding the credential. Optionally, a translation model, a reranker model and whether reranking is on.

Registering creates the row as Unverified, and it does not read the vault at all at this point — it can't, because there's no field on this screen or any server field behind it that could carry the actual key value. The entire credential surface, at every privilege level, is a name you supply and a fingerprint the platform later shows back to you. That's the shape of the underlying record, not a restriction this one screen happens to add.

2. Activate — this is when the vault is actually read

Activation reads the vault once, keeps only the resulting fingerprint and a last-used timestamp, and flips the row to Active. From that point the credential can serve real requests.

Two tiers, and a ceiling your team can see filling

The cheap model handles a straightforward lookup; the strong model is reserved for questions that genuinely need it — routed automatically, per the platform's confidence-based escalation, not chosen per capability by hand. The optional translation and reranker models are independent settings: leaving translation blank means the routing table's own default tier handles it, while leaving the reranker model blank means this organization simply doesn't rerank.

The hard ceiling is your organization's own spend cap, visible as a number filling up rather than a hidden default somewhere in a billing dashboard you don't have access to.