OpenCode's Console Breach Hit 1.4% of Users and Ran Up $1,000+ Bills on Their AI Keys. Here's the Key-Storage Rule That Would Have Capped It.
Last weekend attackers got into an older system behind OpenCode Console, the hosted side of the open source AI coding agent, and used the provider API keys stored there to rack up charges on other people's accounts. OpenCode says 1.4% of Console users were affected. TechCrunch reported individual bills of hundreds of dollars, and a few above $1,000. If you have ever pasted a full-power OpenAI or Anthropic key into a tool's settings page so it would "just work," this is the post to read before you do it again.
What actually happened
According to TechCrunch, OpenCode said attackers broke into an older system overnight and described it as a "large-scale distillation attack." BleepingComputer puts the earliest possible key exposure at October 17, 2026, 00:30 UTC. The affected data was the API keys some users had linked in Console workspaces, and the charges landed with OpenAI, Anthropic, and Google. Developers reported overnight spending alerts, and BleepingComputer's account includes users reporting charges of up to $1,700 and some Google Cloud projects suspended for "abusive activity consistent with hijacked resources."
OpenCode emailed the affected users on Saturday morning and said anyone who did not get an email was not impacted. Anthropic and Google blocked the keys they believed were exposed. OpenAI worked with OpenCode to restore access and refund API customers for credits used in the attack, and OpenCode said refunds for unauthorized charges were underway. As of the TechCrunch report, the company called the incident ongoing and had not explained how the attackers got in or how the keys were stored.
One detail matters for how you read this. Co-founder Dax Raad wrote that this was the Console, not the open source app or CLI, and that "those keys never come to us." If you run OpenCode locally with keys in your own environment, you were not in the blast radius. The people who got hurt had chosen the hosted convenience of keeping keys in someone else's workspace.
The part I'd push back on
The "distillation attack" framing is OpenCode's own, and TechCrunch notes some skeptics see a plain breach whose use for distillation is unproven. I would not spend energy on that argument. For your bill it makes no difference whether an attacker wanted training data or free compute. What matters is that a stored key is a spending authority, and whoever holds it can spend until something stops them.
The key-storage rule
My rule is simple: a key that lives in a third-party dashboard should be able to lose you at most a number you chose in advance.
In practice that means four things. First, one key per tool. If OpenCode Console, your CI, and your side project all share one key, revoking it breaks all three, so people hesitate. A separate key per tool means you can kill one without a meeting with yourself.
Second, put a spending limit on the account or project the key belongs to. Most providers let you set a monthly budget or hard cap at the workspace or project level. Check what yours offers, because the names and the strictness differ. The point is that a stolen key should hit a ceiling, not your card limit.
Third, turn on spend alerts and send them somewhere you actually look. The people in this incident found out from overnight alerts, which means the alerts worked. A cap would have turned the same alert into a smaller bill.
Fourth, prefer keeping keys local when the tool allows it. A key in your own shell environment or secrets manager is one fewer company that can leak it.
What I'd actually do this weekend
I'd spend ten minutes on this, in this order.
- List every tool where you have pasted a provider key. Check browser password manager entries,
.envfiles, and any "integrations" page you have clicked through in the last year. - For each one, create a fresh key labeled with the tool's name, swap it in, and revoke the old one.
- Set a monthly spend cap on each provider account or project to roughly twice your normal bill. If you do not know your normal bill, that is the first thing to find out.
- If you were an OpenCode Console user and got the email, revoke your keys directly with each provider, which is what OpenCode told affected users to do.
The cap number is a judgment call. Set it too tight and a good month of usage stops your product. Set it too loose and it is decoration. I would rather get an angry error at 2x than a $1,700 surprise.
Where this advice could be wrong
A hard cap trades one risk for another. If your cap trips during a real traffic spike, your app goes down, and for a paid product that can cost more than the stolen compute would have. If you run customer-facing features on a single key, put the cap high and rely on alerts plus fast rotation instead. The other limit is that none of this helps if the attacker also sits in your provider account. Keys and caps protect against one failure, a leaked key, not against a stolen login, so turn on two-factor auth on the provider accounts themselves.
Author
Lukas
@lukcombinator