Providers & Models

Where every AI credential, model and search path actually comes from — and where to change it.

This app exists because that question had no single answer. Tracing one provider key on 2026-08-24 meant reading a ConfigMap, three Key Vaults, a CSI SecretProviderClass, a git repo and the mesh. Four separate incidents that week came down to "which of those is the source of truth?"

What it shows

• Global providers (Provider/…) and your own ({you}/_Memex/…), side by side.
• Provenance per credential — the Key Vault secret it came from, the config key that seeded it, and whether the value at rest is encrypted (enc:v1:) or, alarmingly, not.
• Models and tiers — which model serves utility / chat / reasoning / coding, and whether a tier is uncarried (a miss that falls through to the deployment default — valid, but worth seeing).
• Search paths — where this instance looks for agents, skills and models.

The rule it makes visible

A credential has ONE administered home: the ModelProvider node. Configuration is a SEED into it, never a parallel live source.

ProviderCredentialSeed fills an empty key on the node from {Section}:ApiKey on every boot, and the value is stored encrypted. So a key configured after the node was created converges instead of being invisible forever — and there is never an env key and a node key disagreeing silently.

Set one up

Set up AI providers — one card per provider you can see, with the fields it actually needs and the models it exposes.

🚨 Never store a literal key by hand. Enter it on that form:

• it encrypts the value (enc:v1:, AES-256-GCM via IProviderKeyProtector) before writing, and refuses the write if this mesh cannot encrypt — never storing a key in cleartext;
• a raw patch/update does not encrypt;
• a stored key is never rendered back — the label says only whether one is set and in what state, and a blank field means keep.

Contents