This guide compares nine OpenCode alternatives for people who run a coding agent in the terminal with their own API keys: Atomic Agent, Goose, Codex CLI, GitHub Copilot CLI, Crush, Pi, Qwen Code, Cline CLI and Kilo CLI. After the OpenCode Console breach, the question most people are asking is simple: where does each tool keep my provider keys, and does any vendor hold a copy? So for every tool we checked the exact key file, keychain support, any hosted key vault or gateway, the telemetry default and how it handles approvals.
What happened at OpenCode. On October 17, 2026, OpenCode posted that it “had a security breach last night related to a large scale distillation attack that impacted 1.4% of OpenCode Console users” (via IBTimes; Hacker News thread). The breach hit the hosted Console, a web workspace where users could save provider keys. The customer email said that “Third party provider keys (eg OpenAI, Anthropic) saved in your workspace may have been exposed” (via DEV Community). Co-founder dax drew the line for CLI users: “note this is the OpenCode Console, not OpenCode itself, those keys never come to us” (via IBTimes). Users have reported their own losses, including $281 on OpenAI plus $168 on Anthropic for one and $1,700 for another (Dealroom figures, via The Hacker News).
We build Atomic Agent, so it sits first. Every claim about it was checked against its code at v0.6.9 and Desktop v0.0.3 (main as of October 15, 2026), including the parts where it is weaker than the others. Everything else was checked on October 19, 2026.
Quick answer: which OpenCode alternative should you pick?
Pick by the risk that brought you here. If it is a vendor holding your keys, any of the nine works as long as you skip optional web key pages and gateways. If it is malware reading key files, Goose’s keyring default is the strongest start, and the table maps the other needs.
| If you need | Pick | Why |
|---|---|---|
| No cloud API key at all | Atomic Agent (ours) | Default provider is a local llama-server on 127.0.0.1, no key needed |
| Keys in the OS keyring by default | Goose | Keyring first, plaintext only as a fallback, telemetry opt-in |
| A sandbox by default | Codex CLI | OS sandbox on with network off; switch key storage to keyring |
| GitHub integration, BYOK from env vars | GitHub Copilot CLI | GitHub token in the keychain, BYOK keys read from env only |
| The best-looking TUI with llama.cpp | Crush | llamacpp, lmstudio and ollama provider types built in |
| A small agent you can rewire | Pi | Minimal harness; keys can come from the macOS Keychain via a command |
| Any provider protocol | Qwen Code | OpenAI, Anthropic, Gemini, Vertex and Qwen protocols |
| The same setup as Cline in VS Code | Cline CLI | One provider config across IDE, CLI and desktop |
| The closest thing to OpenCode | Kilo CLI | A fork of OpenCode; keep keys in local auth.json |
For a wider list of agents built around local models, see our sister project’s roundup of the best local AI agents.
What to do first if you used OpenCode Console
If you ever saved a provider key in an OpenCode Console workspace, revoke it at the provider today, even if you did not get an email. Deleting it inside Console is not enough. Then create new keys, check usage from October 16 onward, set spend limits, give each tool its own key, and confirm the old key is dead.
- Revoke at the provider. Go to the OpenAI, Anthropic, Google or OpenRouter dashboard and delete the key there. Some providers acted on their own: Anthropic’s Lydia Hallie said Anthropic “revoked Claude API keys we believe were affected” (via avneeshk.me), and OpenCode’s follow-up email said “We’ve worked with OpenAI to revoke all of them and they have issued refunds” (via Hacker News).
- Create new keys. Do not paste them back into any hosted console.
- Check usage from October 16. Look for traffic you do not recognise. Affected users reported unexpected charges on OpenAI, Anthropic and Google accounts, as Infosecurity Magazine and IBTimes covered.
- Set spend limits in each provider dashboard. Atomic Agent has no spend cap for API-key providers, and we did not find one in most of the others, so set the provider’s limit.
- Use one key per tool. If one agent’s file leaks, you revoke one key and know where it came from.
- Confirm the old key returns 401. Send one request with it, for example
curl https://api.openai.com/v1/models -H "Authorization: Bearer $OLD_KEY", and check that the provider rejects it.
OpenCode has not explained the “distillation attack” it named; a Hacker News thread says it could just as well be key reselling.
How we checked these OpenCode alternatives
We checked nine terminal coding agents on October 19, 2026, using each project’s GitHub repo, release page, docs and, where the docs were silent, source code. To make the list, a tool had to be a terminal-first coding agent, ship a release in the last 90 days, and accept your own keys for more than one provider.
For each tool we looked at five things:
- Key path: the exact file or store where a key ends up after you log in or paste it.
- Keychain or plaintext: whether the OS keychain is the default, an option or absent, and the file permissions where we found them.
- Vendor-held keys or gateway: whether the vendor offers a hosted place to store your provider keys, or a gateway your traffic can go through.
- Telemetry default: on, off or asked, and the documented off switch.
- Approvals: what the agent does before it writes files or runs shell commands, out of the box.
Stars and release dates come from the GitHub API on October 19. We did not benchmark the agents or run them side by side.
Four tools other lists recommend did not make it. Aider’s last release is v0.86.0 from August 9, 2025. Hermes Agent is a general personal agent with a chat gateway, and we compared it in our OpenClaw alternatives guide. Gemini CLI only talks to Google models. Claude Code is built for Claude models: other models work only through an Anthropic-compatible gateway or Ollama’s own integration. It keeps its login in the macOS Keychain and falls back to ~/.claude/.credentials.json with 0600 permissions (docs). If you only use Claude, it is a solid choice, and our Claude Code alternatives post covers the open-source field around it.
A note on “plaintext”: a file with 0600 permissions is readable only by your user. That stops other users on the machine. It does not stop malware running as you, and infostealers now look for agent key files. Gen Digital reported infostealers that target the local data of Claude, Cline, Continue, Cursor and OpenCode (Amatera and Remus), plus a macOS stealer, Djinn, that adds Codex, and Symantec described one that collects coding-agent configs and tokens.
The 9 OpenCode alternatives, reviewed
All nine run in the terminal, take your own keys for several providers, and shipped a release after July 21, 2026. Each card covers where your keys live, any vendor cloud option, telemetry and approvals. The Note is the downside we would want to know before switching, and the Verdict says who should pick it.
1. Atomic Agent: best for local models with no API key
We build Atomic Agent, so read this card with that in mind and check it against the repo.
Atomic Agent is a local-first agent runtime under the MIT license, with a terminal UI and a desktop app. It runs local models, cloud models, or Fusion, where one model plans and workers execute. It has 3,405 stars; the latest releases are v0.6.9 and Desktop v0.0.3, both on October 15, 2026. Install with curl -fsSL https://atomicagent.io/install | sh, or irm https://atomicagent.io/install.ps1 | iex on Windows; the installer verifies a checksum.
- Where keys live: in plaintext files under
~/.atomic-agent. The terminal setup wizard writes.env(for exampleOPENROUTER_API_KEY), and the desktop app writes the key inline inconfig.json. Both files are written with 0600 permissions, plus a Windows ACL for.env.config.jsonhas been 0600 since v0.6.7; installs on v0.6.5 or earlier wrote it without that, and it may stay readable by other users until the next save. There is no OS keychain support. - Vendor cloud: none. There is no Atomic-hosted console, account or proxy that holds or forwards your model keys. Calls go from your machine straight to the provider, such as openrouter.ai, api.anthropic.com or api.openai.com.
- No key at all: the default provider is a local llama-server on 127.0.0.1. The agent can manage llama.cpp for you, or use your own llama-server, and the Ollama and LM Studio presets need no key either. A keyless setup sends no Authorization header.
- Telemetry: on by default. PostHog and Sentry events carry provider, model, token and cost data, without message content, and a scrubber filters Sentry reports. Turn it off with
analytics.enabled: falsein the config, which covers the terminal and the desktop app (theATOMIC_AGENT_ANALYTICS=offvariable covers the terminal only). - Approvals: a five-level approval ladder, level 1 by default. File edits to the agent’s own
config.jsonor.envask at every level below 5, and a session-wide grant cannot silence that; at level 4, shell commands are auto-approved and could still change those files. Outbound HTTP requests from its web tool do not ask by default.
Note: on key storage itself it is weaker than Goose, Claude Code and Copilot CLI: plaintext files, no keychain. It has no spend cap for API-key providers, and traces store prompts and tool output as they are, so if the agent reads a .env, that content goes to the model unredacted. Telemetry is on until you turn it off. atomic-agent uninstall removes everything, keys included.
Verdict: Choose Atomic Agent if the safest key for you is no cloud key: you want a local model as the default, with no vendor account in the path, and you are fine with keys in 0600 files when you do add a cloud provider. Download it here.
2. Goose: best for keys in the OS keyring by default
Goose started at Block and now sits in the Agentic AI Foundation at the Linux Foundation. It is Apache-2.0, has 55,437 stars and released v1.55.0 on October 16, 2026.
- Where keys live: in the system keyring under the service name “goose”. If no keyring is available, or
GOOSE_DISABLE_KEYRINGis set, it falls back to plaintext~/.config/goose/secrets.yaml(%APPDATA%\Block\goose\config\secrets.yamlon Windows), written with 0600 permissions on macOS and Linux (source). - Vendor cloud: none.
goose gatewayis a Telegram bridge and does not proxy model calls. - Providers and local models: about 50 providers, plus any OpenAI-, Anthropic- or Ollama-compatible endpoint; local options include Ollama, LM Studio, Ramalama and Docker Model Runner (providers doc).
- Telemetry: opt-in, asked at first run. Data goes to PostHog;
GOOSE_TELEMETRY_ENABLED=falseturns it off (usage data doc). - Approvals: four modes: Autonomous (the default), Manual, Smart and Chat Only. In Autonomous mode it can modify and delete files without asking (permissions doc).
Note: out of the box Goose acts without asking, so switch to Manual or Smart before you point it at a real repo. And if your system has no keyring, keys land in a plaintext YAML file.
Verdict: Choose Goose if you want an OS-keyring default and dozens of providers without a vendor account.
3. Codex CLI: best for a sandbox by default
Codex CLI is OpenAI’s open-source coding agent, written in Rust under Apache-2.0. It has 129,910 stars and released rust-v0.163.0 on October 15, 2026.
- Where keys live: by default
cli_auth_credentials_store = "file", which means plaintext~/.codex/auth.json(ChatGPT tokens, or your OpenAI API key if you log in with one) written with 0600 permissions on macOS and Linux. The other options arekeyring,auto(keyring, else file) andephemeral. OpenAI’s own docs say to “treat ~/.codex/auth.json like a password” (auth docs). Keys for custom providers are normally read from an environment variable (env_key) at runtime and never written to that file, though the discouragedexperimental_bearer_tokensetting puts a key in plain text inconfig.toml(source). - Vendor cloud: no store for third-party keys; custom providers are called directly.
- Local models:
--osswith Ollama or LM Studio. - Telemetry: anonymous usage metrics to OpenAI, on by default;
[analytics] enabled = falseturns them off (advanced config). - Approvals: an OS sandbox is on by default with network off, and
approval_policycontrols when it asks (approvals and security).
Note: the default key file is plaintext, and it has already been a target: the codexui-android npm package stole tokens from ~/.codex/auth.json, per a Cloud Security Alliance note. Set cli_auth_credentials_store = "keyring".
Verdict: Choose Codex CLI if you want an open-source agent with a real sandbox, and you will switch key storage to the keyring.
4. GitHub Copilot CLI: best for GitHub users who keep BYOK keys in env vars
GitHub Copilot CLI is GitHub’s terminal agent. It is proprietary: the repo holds the README, license, changelog and install script, but no source. It has 11,273 stars and released v1.0.98 on October 14, 2026. BYOK works through COPILOT_PROVIDER_* environment variables.
- Where keys live: the GitHub OAuth token goes into the OS keychain (service
copilot-cli). Without a keychain, the CLI asks before saving plaintext~/.copilot/config.json(auth docs). BYOK keys are read from environment variables; we found no step in the docs that saves them. - Vendor cloud: on Enterprise, enterprise owners can upload provider keys for “custom models” into GitHub’s settings and can let organization owners do the same, which means GitHub holds those keys (a public preview) (docs). Individual BYOK does not need a GitHub login at all, though you lose /delegate, the GitHub MCP server and code search (BYOK docs). Remote session sync is on by default;
--no-remoteturns it off. - Local models: Ollama through
COPILOT_PROVIDER_BASE_URL=http://localhost:11434, plus vLLM and Foundry Local per the BYOK docs, with a model that supports tool calling. - Telemetry: on by default, including for BYOK without login. The only documented full opt-out is
COPILOT_OFFLINE=true. - Approvals: read-only actions run on their own; writes and shell commands prompt.
--allow-tooland--deny-toolfine-tune it.
Note: it is closed source, and turning telemetry fully off means offline mode, which drops the GitHub features that make it worth using.
Verdict: Choose Copilot CLI if you already live in GitHub and want keys only in env vars and the keychain.
5. Crush: best terminal UI for local model servers
Crush is the coding agent from Charmbracelet, Inc. It has 28,704 stars and released v0.98.1 on October 9, 2026. Its license is FSL-1.1-MIT, which is source-available and bans “Competing Use”, so it is not OSI open source (license).
- Where keys live: plaintext JSON, with no keyring. Keys you paste in the UI go to
~/.local/share/crush/crush.json(%LOCALAPPDATA%\crush\crush.jsonon Windows), written with 0600 permissions, and OAuth tokens go in the same file (source). Environment variables work too. - Vendor cloud: Charm Hyper is Charm’s own optional subscription gateway, and your traffic goes through Charm when you use it. Its Enterprise plan advertises bring-your-own frontier-lab keys, and we found no documentation of how it stores them (Hyper).
- Local models: provider types
ollama,lmstudioandllamacppare built in (README). - Telemetry: pseudonymous PostHog metrics, on by default, without a prompt.
CRUSH_DISABLE_METRICS=1orDO_NOT_TRACK=1turns them off. - Approvals: asks before tool calls by default, with allow and deny lists in config;
--yoloskips prompts.
Note: keys sit in a plaintext file next to OAuth tokens, metrics are on without asking, and the license is not OSI-approved.
Verdict: Choose Crush if you want the nicest terminal UI and first-class llama.cpp or LM Studio support, and you keep your keys in env vars.
6. Pi: best for a minimal, hackable agent
Pi is a small, extensible coding agent by Mario Zechner, acquired by Earendil Inc. on April 8, 2026 and still MIT (announcement). It has 116,373 stars and released v1.3.0 on October 15, 2026.
- Where keys live: plaintext
~/.pi/agent/auth.json, mode 0600 in a 0700 directory. A key can instead be a shell command, such as!security find-generic-password ..., which reads it from the macOS Keychain at runtime (providers doc). - Vendor cloud: Radius, an optional Earendil gateway in early alpha with organization controls. Its API lists “BYOK credential providers”, and we could not confirm how it stores them.
/shareuploads to Radius when you are logged in, or to a GitHub gist otherwise. - Local models: Ollama, LM Studio, vLLM and SGLang, plus a llama.cpp guide.
- Telemetry: install and update pings and provider attribution headers are on by default; analytics are opt-in.
PI_TELEMETRY=0turns telemetry off andPI_OFFLINEstops automatic network activity. - Approvals: none by design. Pi’s security doc recommends running it in a container or VM.
Note: out of the box Pi acts without asking, and plan mode and sub-agents are not built in.
Verdict: Choose Pi if you want a small agent you can rewire, you will run it in a container, and you will pull keys from your Keychain.
7. Qwen Code: best for mixing provider protocols
Qwen Code is the Qwen team’s fork of Gemini CLI, under Apache-2.0. It has 28,582 stars and released v0.25.3 on October 19, 2026. It speaks the OpenAI, Anthropic, Gemini, Vertex and Qwen protocols, and /model switches models at runtime. The free Qwen OAuth tier ended on April 15, 2026.
- Where keys live: a key typed into
/authgoes to anenvblock in plaintext~/.qwen/settings.json, written with no explicit file mode, so a new file usually gets 0644. Environment variables and.qwen/.envalso work; the docs headline the one-filesettings.jsonsetup but advise.qwen/.envfor security (auth doc). We found keychain code for MCP tokens only. - Vendor cloud: none for third-party keys.
- Local models: Ollama, vLLM and LM Studio through the
openaiprotocol with a localhost base URL. - Telemetry: usage statistics are on by default and go to Alibaba Cloud’s monitoring service; code and prompts are not collected. Set
privacy.usageStatisticsEnabledto false to stop it. - Approvals: Plan, Ask, Auto-Edit, Auto and YOLO. The interactive default is Auto, where an AI model judges each action (approval modes).
Note: keys are plaintext, statistics go to Alibaba unless you switch them off, and the default approval mode leaves the risk call to a model.
Verdict: Choose Qwen Code if you want a Gemini-CLI-style agent that takes any provider’s key.
8. Cline CLI: best for teams already on Cline in VS Code
Cline by Cline Bot Inc. shares one provider config across its IDE extension, CLI and desktop app, under Apache-2.0. It has 70,550 stars and released cli-v3.0.73 on October 17, 2026. cline kanban runs parallel agents in git worktrees.
- Where keys live: plaintext
~/.cline/data/settings/providers.json, mode 0600 in a 0700 directory, with no keychain (source). Passing-kon a run also saves the key. - Vendor cloud: no cloud store for individual BYOK keys. Enterprise remote config sets providers and models, while members’ keys stay “stored locally” (docs). Cline’s default provider is its own pay-as-you-go gateway, so your traffic goes through Cline unless you pick a direct provider.
- Local models: Ollama and LM Studio (docs).
- Telemetry: on by default, including for BYOK. Opt out with
"telemetryOptOut": truein~/.cline/data/settings/global-settings.json. - Approvals: the CLI’s
--auto-approvedefaults to true, and there is no built-in allow or deny list for shell commands (CLI reference).
Note: out of the box Cline CLI acts without asking. For enterprise users, the CLI can also write org settings into .cline/enterprise/ in the project folder, and the docs say to add it to .gitignore.
Verdict: Choose Cline CLI if your team already uses Cline in VS Code and wants the same providers in the terminal.
9. Kilo CLI: best for the closest OpenCode workflow
Kilo CLI is a fork of OpenCode by Kilo Code, under MIT. Kilo’s docs now carry the banner “Kilo has been acquired by Anaconda” (source). It has 27,659 stars; the latest stable release is v7.8.12 from October 15, 2026. It can also import Claude Code and Codex sessions.
- Where keys live: plaintext
~/.local/share/kilo/auth.json, mode 0600 (source). - Vendor cloud: yes, optional. You can paste Anthropic, OpenAI, Google, Bedrock, Azure and other keys into a web BYOK page at app.kilo.ai, and requests then go through the Kilo Gateway with your key (BYOK docs). The gateway page claims encrypted-at-rest storage. This is the same shape as OpenCode Console.
- Local models: Ollama and LM Studio (docs).
- Telemetry: PostHog, on by default;
KILO_TELEMETRY_LEVEL=offturns it off. - Approvals: allow, ask or deny per tool. Most tools default to allow, and reading
.envasks (docs).
Note: if you are leaving OpenCode because of the Console, the web BYOK page has the same shape: the vendor stores a copy of your key and serves it through its gateway. Out of the box Kilo also allows most tools without asking, and telemetry is on.
Verdict: Choose Kilo CLI if you want OpenCode’s workflow back today, and you keep keys in the local auth.json, never in the web BYOK page.
OpenCode alternatives compared: keys, telemetry, local models
The table compares the nine, with OpenCode’s CLI as the baseline. A keyring protects against local malware, while a vendor web page puts a second copy of your key in someone else’s database. Only Kilo offers a personal web page for your provider keys; Cline defaults to its own gateway, and Kilo, Crush and Pi run optional ones.
| Tool | Where keys live | OS keychain? | Vendor stores your keys? | Vendor gateway? | Telemetry default | Local models | License |
|---|---|---|---|---|---|---|---|
| Atomic Agent | ~/.atomic-agent/.env or config.json (0600) | No | No | No | On (analytics.enabled: false) | Local llama-server by default; Ollama, LM Studio | MIT |
| Goose | OS keyring; fallback ~/.config/goose/secrets.yaml (0600) | Yes, default | No | No | Opt-in, asked at first run | Ollama, LM Studio, Ramalama, Docker Model Runner | Apache-2.0 |
| Codex CLI | ~/.codex/auth.json (0600) | Optional (keyring) | No | ChatGPT login traffic via OpenAI | On | Ollama, LM Studio | Apache-2.0 |
| Copilot CLI | GitHub token in keychain; BYOK from env | Yes, for GitHub login | Enterprise and org owners (custom models, preview) | Copilot subscription models via GitHub | On (COPILOT_OFFLINE=true) | Ollama, vLLM, Foundry Local | Proprietary |
| Crush | ~/.local/share/crush/crush.json (0600) | No | Enterprise only (Hyper BYOK), storage not documented | Hyper (optional) | On | Ollama, LM Studio, llama.cpp | FSL-1.1-MIT |
| Pi | ~/.pi/agent/auth.json (0600) | Via a Keychain command | Unclear (Radius BYOK, alpha) | Radius (optional, alpha) | Pings on, analytics opt-in | Ollama, LM Studio, vLLM, SGLang, llama.cpp | MIT |
| Qwen Code | ~/.qwen/settings.json (no explicit mode) or .qwen/.env | No | No | No | On | Ollama, vLLM, LM Studio | Apache-2.0 |
| Cline CLI | ~/.cline/data/settings/providers.json (0600) | No | No | Cline provider (default) | On | Ollama, LM Studio | Apache-2.0 |
| Kilo CLI | ~/.local/share/kilo/auth.json (0600) | No | Yes, optional web BYOK page | Kilo Gateway | On | Ollama, LM Studio | MIT |
For the baseline: OpenCode’s own CLI keeps provider keys on your machine, in plaintext and with no keychain. The current release, v1.19.3, writes them to ~/.local/share/opencode/auth.json with 0600 permissions (source), and the V2 line, published so far only as tags while npm latest is still 1.19.3, stores them in the local SQLite database opencode.db, created with 0600 permissions, importing the old file (V2 docs). The Console worked differently: its docs say “Console stores the credential and serves each provider through its gateway” (Console docs). That stored copy is what may have been exposed.
Frequently asked questions
Bottom line: matching the tool to your risk
Start from the risk that brought you here. If it is a vendor holding your keys, all nine keep keys on your machine; with Kilo, Crush and Pi, skip their optional gateways, and with Cline, pick a direct provider over its default gateway. Against malware reading key files, Goose’s keyring default is strongest; Codex needs one setting.
For the least change, Kilo CLI is an OpenCode fork; keep keys in its local auth.json. For a sandbox around every command, Codex CLI. For GitHub, Copilot CLI.
If you would rather not hold a cloud key at all, try Atomic Agent. Its default model runs on a local llama-server, so there is no key to leak until you add a cloud provider. When you do, the key sits in a 0600 file under ~/.atomic-agent, without keychain support, and telemetry stays on until you set ATOMIC_AGENT_ANALYTICS=off. Weigh that against Goose’s keyring if key storage is your main concern.
Whatever you pick, do the provider-side work too: one key per tool, a spend limit on each, and a quick check that every old key now returns 401.
Release dates, versions, licenses and star counts were checked against the GitHub API and each project’s documentation on October 19, 2026. Atomic Agent claims were checked against its source code at v0.6.9 and Desktop v0.0.3 (main as of October 15, 2026). Quotes about the breach reached us through the linked news reports. We did not benchmark these agents or run them side by side.


