Skip to main content

Store AI credentials

For the concept of providers and how keys are resolved, see Choose a translation provider; this recipe walks the desktop credential vault.

Goal: save a provider's API key once, securely, so every translate, qa, or rewrite step that needs it just works — and the key never lands in the committed recipe.

Outdated recording

The interface has changed since this was recorded. The workflow it demonstrates still applies, but some screens and labels differ from the current release. The sidebar now reads Terms and Content Memory, and AI Models shows which model runs are using.

Video — retargeting needed

This clip is reused from the tour's "appearance, providers, and plugins" settings segment. TODO: retarget it to the credential-vault task only — adding a provider key, it landing in the OS keychain (not the recipe), and a translate step picking it up — and cut the unrelated settings. Scene scripts: web/walkthroughs/.

Steps​

  1. You may not need a key. On first open, the Connect your AI card offers what it detects — a Claude Code sign-in (uses your Claude subscription) or a local Ollama model — one click, nothing stored. The vault below is for API keys.
  2. Open the vault. From Settings → Providers, add a credential: pick the provider (Anthropic, OpenAI, Gemini, …) and paste its key.
  3. Stored in the keychain. The key is saved to the OS keychain, never written to the kapi.yaml recipe — so the recipe stays safe to commit and share.
  4. Use it. A translate step (in the flow editor) or any AI-backed tool resolves the credential automatically; no key on any command line.

Why the desktop​

The vault makes credential handling safe by default: keys live in the OS keychain, the recipe carries only the provider name, and the app surfaces which providers are configured. The same keychain store backs the CLI's kapi credentials, so a key added here is available to command-line runs too.

Next​