One API key in every coding agent

The short answer

echo "$OPENAI_API_KEY" | yoink add --external --name openai-api --preset openai \
  --models gpt-5.2,gpt-5.2-codex --connect pi,codex --default gpt-5.2-codex --token-stdin
yoink connect openai-api --to qwen,kilo,crush,continue
yoink status openai-api

The first command saves the provider and connects it to pi and codex in one go. The second adds four more agents. The profile id is openai-api rather than openai because Codex reserves openai for its built-in provider and ignores a config table with that id; the codex page explains the clash. yoink status openai-api prints one line per harness: connected (with its default model), available, incompatible, or not installed, plus the config path. In an interactive terminal, yoink add and a bare yoink connect openai-api show the same choices as a checklist.

Why each agent wants its own config

Every coding agent reads providers from its own file, in its own shape. pi wants ~/.pi/agent/models.json with a models array and context limits per model. opencode and Kilo Code want an @ai-sdk package name and an options.baseURL in JSON or JSONC. codex wants a [model_providers.<id>] TOML table with wire_api = "responses". omp and Continue use YAML, Qwen Code keeps the key in an env block, and Claude Code takes seven ANTHROPIC_* env keys. Pasting one key into 13 formats by hand works once; keeping them in step after a key rotation is the part that breaks. The harness table lists every path and format yoink writes, and each harness has its own page with the exact entry yoink adds:

• pi
• omp
• opencode
• codex
• Claude Code
• Qwen Code
• Kilo Code
• Droid
• Crush
• Goose
• Zed
• Continue
• Claude Desktop

Which provider reaches which agent

A key is only as portable as the protocols its provider speaks. Each harness takes the first protocol in its own preference order that the provider offers:

Counted per preset, openai reaches 11 harnesses, the five dual-endpoint presets reach 12 (all but codex), and ollama reaches 10 (not codex, Claude Code or Claude Desktop). No preset reaches all 13. A custom endpoint can, but only if its probe finds both a /responses route and a /v1/messages route. The order matters in practice: Droid gets the Anthropic URL of a dual-endpoint preset, while pi and Crush get its Chat URL.

Rotate a key or change models once

echo "$NEW_OPENAI_API_KEY" | yoink edit openai-api --token-stdin
yoink models openai-api --set gpt-5.2,gpt-5.2-codex
yoink rename openai-api work-openai

Each of these saves the change and re-writes the provider into every harness it is connected to. A harness default model survives as long as that model is still selected. A rename removes the old entry from each harness before writing the new one, so you never end up with both. After a key rotation, yoink also scrubs the retired key out of any <file>.yoink.bak backup it touched during that re-sync, so the old key does not linger on disk next to the new one.

Each harness also keeps its own default. yoink connect openai-api --to codex --default gpt-5.2-codex and yoink connect openai-api --to pi --default gpt-5.2 can coexist; yoink records the default per harness and keeps it through every re-sync.

Native config, not a proxy

yoink runs only when you call it. It writes files and exits, so nothing sits between an agent and the provider: requests go straight from the agent to the provider's own URL, and an agent keeps working if yoink is uninstalled. That is the main difference from an AI gateway or a routing proxy, which give every agent one local endpoint and forward the traffic. A gateway can do things yoink cannot, such as routing rules or fallback between providers. yoink's trade is no extra process and no extra hop. The switcher comparison covers the account-switching side of this space.

Disconnect cleanly

yoink disconnect openai-api --from crush
yoink remove openai-api

yoink disconnect deletes yoink's entry from the named harnesses and clears any default that pointed at it. yoink remove disconnects the provider from every harness first and deletes the profile only when every one of those updates succeeds. If one fails, for example because a config no longer parses, yoink keeps the profile, names the failing harness and tells you to run yoink remove again once it is fixed. Nothing is left half-removed.

FAQ