Bring your own model keys — and keep them on your own machine

Most AI developer tools ask you to hand over a provider key, or quietly resell inference through their own account. Either way your prompts and your spend route through someone else's infrastructure, and you find out what that means only when something goes wrong.

VibeControls draws the line somewhere else. Open the AI Keys panel on an agent and you get a row per provider whose plugin reads credentials from that agent's own config: Anthropic (API key or auth token), OpenAI Codex, Google Gemini (either GEMINI_API_KEY or an existing GOOGLE_API_KEY), Cursor, OpenRouter, Minimax, Ollama, and a generic OpenAI-compatible slot that takes both a key and a base URL so Together, Groq or Mistral work without a new plugin. Secret fields are write-only once saved.

Two of those entries matter more than they look. The OpenAI-compatible slot means any endpoint that speaks the OpenAI protocol is a first-class provider, including one you host yourself. The Ollama entry takes an optional host override, so a local model server or a private GPU box is a normal choice in the model picker rather than a workaround.

Harnesses that authenticate through their own binary — Aider, Amp, Copilot, Crush, Goose, Plandex, Pi — never appear in the keys panel at all, because their credentials live in their own config directories on disk. Bridle manages those files instead. Nothing about that path involves the platform either.

The honest boundary: the built-in workspace AI Assistant is a different surface. It runs in a per-conversation sandbox on workspace compute and is metered in AI credits, because you are not supplying the key there. Harness sessions spend your provider key and are not metered in credits. That split is deliberate — it lets you decide, per surface, whether the inference is yours or ours, and it means VibeControls is not in the business of reselling tokens.