Models and keys

Your yeti think with models from Anthropic (Claude) or OpenAI, using API keys from your own accounts. yeti doesn't resell model access and there's no yeti server in between: the provider bills you directly for what your yeti use.

Choose a model for each yeti

On Agents, each yeti's Model and cube section has a Provider switch:

Provider	Model choices
Claude	Claude Opus 5.5 (claude-opus-5-5, the default), Claude Sonnet 5.5 (claude-sonnet-5-5), Claude Haiku 5.5 (claude-haiku-5-5), Claude Fable 5.1 (claude-fable-5-1)
OpenAI	Any model ID you type in Model ID: letters, digits and . _ : / -, up to 100 characters

Different yeti can use different providers and models. One key per provider covers every yeti that uses it.

Bring-your-own and self-hosted models are planned for later.

Add a key

1. Open Agents and scroll to the Model access card.
2. Find the provider: Anthropic (for Claude models) or OpenAI (for OpenAI models).
3. Paste the key into the field and choose Save key.

The row shows set with when the key was last updated, or not set. The field is a password field, and the key is never shown again after you save it, not even to you.

yeti trims spaces around the key and rejects anything over 512 characters or containing spaces or invisible characters. Error messages never echo the key back.

Replace or remove a key

• Replace: paste a new key into Replace Anthropic API key (or OpenAI) and choose Save key. The old one is overwritten.
• Remove: choose Remove, then Remove key. Your yeti on that provider's models stop working until you add a key again.

Removing a key from yeti doesn't revoke it at the provider. If you think a key was exposed, revoke it in your Anthropic or OpenAI account as well.

Where your keys live

Model keys are not stored in your operating system's keychain. They are cluster secrets, stored on your cubes:

Provider	Secret name
Anthropic	models/anthropic/api-key
OpenAI	models/openai/api-key

When you choose Save key:

1. The app sends the key to this computer's cube over mutual TLS.
2. The cube seals it with AES-256-GCM using your cluster's data key, a random 256-bit key created when your cluster was. The ciphertext is bound to the secret's name, so it can't be moved under another name.
3. Only the sealed value enters the cluster's replicated log, so every cube gets a copy of the ciphertext. The data key itself never enters the log.

The desktop app can save, list and delete secrets, but it has no way to read one back: only a cube can decrypt a secret. That's why the card can show whether a key is set and when it changed, but never the key.

How your yeti use them

When a yeti thinks, a cube in your cluster decrypts the key and calls Anthropic or OpenAI directly. The key goes to the provider it belongs to and nowhere else.

Know the limits

Sealing protects keys in the replicated log and on the wire. It does not protect them from someone who can read a cube's state directory, because each cube keeps the cluster data key there, in a file only its owner can read. In particular:

• Anything running as your user account on a computer with a cube can read that cube's data key.
• On a cloud cube, administrators of that AWS account can read the cube's disk.
• Removing a cube revokes its certificate, but it already holds the data key and a copy of the sealed secrets. If you remove a cube you don't trust, rotate your model keys at the provider.

Security covers these and the other known limits in full.