OpenCode's breach exposed provider keys for 1.4% of Console users. I checked what that number can and can't tell you.

On Saturday, OpenCode — the open-source coding agent built by Anomaly Innovations — told some of its Console users, by email, that the API keys they had saved in their workspaces may have been exposed. Not OpenCode's keys. Theirs: OpenAI, Anthropic, and Google keys, belonging to the users, stored in a hosted console, reached through what the company called a legacy system it was in the process of decommissioning.

I write about stolen keys a lot; a month ago I noted that every attack in Anthropic's threat report started with one. This incident is the cleanest example yet of why, because the stolen asset here wasn't data. Nobody needs to sell your API key on a market. The key is the money — it bills your account at frontier-model prices, and OpenCode says the breach was part of a "large scale distillation attack," which is a polite way of saying the keys were wanted as free inference.

What is actually confirmed

Sticking to what multiple reports agree on, plus what I checked myself:

• The intrusion was discovered overnight into Saturday, October 17, and affected users were notified by email with the subject line "Action Required: Potential provider key breach."
• OpenCode put the impact at 1.4% of OpenCode Console users — specifically the subset who had linked external providers. The company has not published a Console user count, so 1.4% cannot be converted into a number of people. Anyone who gives you a headcount is inventing the denominator.
• The exposed system was a legacy console being decommissioned. The company says its investigation found no evidence other data was exposed, and that it is working with Anthropic, OpenAI, and Google on remediation. Anthropic has reportedly revoked affected Claude keys.
• Keys added locally through the CLI's /connect flow were not part of this, per the company's statements — the blast radius is the hosted Console workspaces.

I ran the two checks I could run from my desk. The GitHub repo is as big as advertised — anomalyco/opencode sits at 216,534 stars and 28,989 forks as of today, and the "16 million developers a month" figure the company cites makes this the largest coding-agent user base to have a credential incident so far. And as of this evening, the public web presence still carries no advisory: I fetched opencode.ai and opencode.ai/docs and grepped them — zero mentions of "breach," zero of "security." Notification was email-only, to accounts the company had already identified. If you weren't on the list, the only way to learn about this incident is coverage like this.

The timeline is the uncomfortable part

The hour-by-hour reconstruction circulating among developers — assembled by a user, not the company — puts the earliest identifiable exposure at roughly 00:30 UTC on October 17 and the first notification email at about 22:51 UTC: a gap of some 22 hours. Treat the exact minutes as reported rather than confirmed, but even the company's own framing ("breach last night," emails "this morning," public post Saturday afternoon) describes a full day in which the keys were live, exposed, and — if the distillation framing is right — exactly what the intruders came for.

Users noticed before any statement. Reports of unauthorized provider usage appeared the evening of the 17th; the dollar figures in public posts don't agree with each other — one report says roughly $100, another tally lists individual accounts at $449, $700+, and $1,700 — and no provider has publicly committed to refunding fraudulent usage. That disagreement is itself the data point: a day later, there is no authoritative damage number, only self-reports.

The detail I can't stop thinking about comes from the response side: according to posts by a developer involved, relayed in coverage of the incident, the frontier models OpenCode first used to help analyze the attack material began refusing — the attack samples tripped safety filters — and the team had to switch tools mid-incident. The same week, the defenders in the Hugging Face swarm investigation needed the same kind of access. We have built a world where the best incident-response assistant is a model that may decline to look at the evidence.

What this incident is actually about

Three lessons, in ascending order of how much people will resist them:

A stored provider key is a bearer instrument. It is not a password to an account with statements and chargebacks; it is cash that spends at API speed. Any product that asks you to paste one into a hosted workspace is asking to hold cash on your behalf, and should be audited like it.

Decommissioning is an attack surface, not an epilogue. The system that got hit was on its way out. Legacy systems hold production-shaped secrets with pre-production attention. If your shutdown checklist doesn't start with "revoke and rotate every credential this system ever touched," the checklist is decorative.

Percentages without denominators are anesthesia. "1.4% of users" sounds small and is unfalsifiable as stated. What users needed — and mostly got, to be fair — was a binary: you got the email or you didn't. That's the right unit. If you got it: revoke at the provider's dashboard (not in OpenCode), reissue, update every consumer of the old key, check usage from October 17 onward, and confirm the old key actually dies — a revoked key should return 401, and "should" is a word you can test with one curl.

I test error surfaces for a living, more or less. It's a strange comfort that the end of a credential's life is the one API behavior you can verify in half a second.