Your API key is a password with a credit card attached.

An API key is a bearer token: whoever holds the string can use it, and spend your money with it. On 2026.10.17, OpenCode told some users that provider keys saved in its hosted Console may have been exposed. Some of them reported hundreds of dollars in charges, a few more than $1,000. The keys kept by the same tool on users' own machines were not involved. That difference is the whole lesson.

Watch the 60-second version on Instagram.

What happened at OpenCode

Here is what has been reported, and by whom:

• The intrusion. OpenCode reported an intrusion into a legacy Console system on the night of Oct 16. Affected users got an email on the morning of Saturday, Oct 17, and OpenCode posted on X the same day (The Hacker News, TechCrunch, BleepingComputer).
• The window. The email gave 2026-10-17 00:30 UTC as the earliest possible key exposure (BleepingComputer).
• The scope. "1.4% of OpenCode Console users", and only those who had linked an external provider. OpenCode hasn't said how many people that is.
• What wasn't involved. The local CLI and the desktop app. OpenCode's Dax Raad, quoted by The Hacker News and TechCrunch: "this is the OpenCode Console, not OpenCode itself, those keys never come to us".
• The providers. Anthropic and Google blocked the keys they believed were exposed. OpenAI worked with OpenCode to restore access and refund credits used in the attack, and OpenCode says refunds are underway (TechCrunch). Google also suspended some projects for abusive activity consistent with hijacked resources (BleepingComputer).
• The charges. Hundreds of dollars per user, a few above $1,000, and up to about $1,700 in the highest single claim, from Preston Zeller. These are user claims; nobody has audited them.

OpenCode's wording is "may have been exposed". It hasn't confirmed that keys were copied, and it hasn't explained how the attackers got in, so I won't guess at either.

The figure is the part worth keeping. On the left, a key in the local CLI sits on one machine and never reaches OpenCode. On the right, the Console held many users' linked keys in one place. The 1.4% figure is OpenCode's; the drawing doesn't try to show the proportion.

Local storage isn't perfectly safe either. A stolen laptop or a key committed to git leaks it just as well. What changes is the blast radius: one machine, instead of one database that holds everyone's keys.

Why the key alone is enough

RFC 6750 defines a bearer token as one that works for "any party in possession of the token". No signature, no device, no second factor. When your code calls a model API, the whole credential is one header:

Authorization: Bearer sk-...

Whoever has that string can send that header. So the questions that matter are where the string lives, and what it can do once it's out. For local work, the boring setup is still the right one: the key in a .env file on your machine, and that file out of git.

# local: key stays on your machine, out of git
echo "OPENAI_API_KEY=sk-..." >> .env
echo ".env" >> .gitignore

Rotate, scope, cap

If a key might be out, three things limit the damage, in this order:

1. Rotate it at the provider. Deleting a key from a third-party app doesn't revoke it. Only the provider can kill it.
2. Scope it. Give each key only what it needs, so a leaked one can do less.
3. Cap it. Set a hard spend limit, so a leaked one can spend less.

Each provider handles the last two differently:

The figure is illustrative: the curve and the levels are made up, not anyone's real bill. It shows the two behaviours that matter. A spend alert fires and the spending carries on. A hard limit stops it with a 429, but a little late, because enforcement lags: OpenAI says so, and Google puts its lag at about 10 minutes. Set the cap with that overshoot in mind.

What people get wrong

• "The dashboard I pasted it into is trustworthy, so the key is safe." The OpenCode Console was a trusted dashboard. A key stored in a service is only as safe as that service.
• "I deleted it, so it's gone." Deleting it from a third-party app leaves it valid. Revoke it at the provider.
• "I have an alert set." An alert only warns you. A hard limit is what stops the spending.
• "My hard limit means I can't lose more than that." Enforcement isn't instant on OpenAI or Gemini, so spend can overshoot the cap.

On a client project I'd give every tool its own restricted key with a hard limit on its own project, so one leak costs one capped key, not the whole account.

The short version

1. An API key is a bearer token: whoever holds it can spend with it.
2. OpenCode says keys in its hosted Console may have been exposed for 1.4% of Console users; keys in the local CLI and desktop app weren't involved.
3. If a key might be out, rotate it at the provider. Deleting it elsewhere doesn't revoke it.
4. Scope every key to what it needs.
5. Set a hard limit, not just an alert, and expect it to bite a little late.

Sources: RFC 6750, Bearer Token Usage · The Hacker News, OpenCode Console breach may have exposed API keys · TechCrunch, Hackers hit AI coding tool OpenCode · BleepingComputer, OpenCode hack exposes API keys · OpenAI Help, Assign API key permissions · OpenAI Docs, Spend limits · Claude Help, Creating and managing workspaces · Gemini API, Billing · DEV, OpenCode lost the keys that lived in its cloud