OpenCode Key Leak: Behind the 1.4%, an API Key Security Wake-Up Call

OpenCode, the open-source coding agent built by Anomaly Innovations, recently sent some Console users an email titled "Action Required: Potential provider key breach," admitting that stored API keys may have been compromised—not OpenCode's own keys, but the OpenAI, Anthropic, and Google keys users had saved in their hosted workspaces. The company says the problem lies in a legacy system being retired, and characterizes the intrusion as a "large-scale distillation attack"—in plain terms, attackers wanted to freeload off frontier model inference.

What the incident confirms, and what it doesn't

Based on multiple reports and independently verifiable information, here's what can be confirmed: the intrusion was discovered in the early hours of Saturday, October 17, and affected users were notified by email; OpenCode frames the scope as "1.4% of OpenCode Console users," specifically the subset that had linked external providers. But the company has never disclosed the total number of Console users, so 1.4% cannot be converted into a concrete headcount—any claim of a specific number is inventing a denominator out of thin air.

The compromised system was a legacy console being retired. The company says its investigation found no other data exposure and that it is working with Anthropic, OpenAI, and Google to handle the matter. Anthropic has reportedly revoked the affected Claude keys. Keys added locally through the CLI's /connect flow are outside the scope of this incident; the blast radius is limited to hosted Console workspaces.

I ran two desk checks: the GitHub repository anomalyco/opencode as of today has 216,534 stars and 28,989 forks, and the company's claim of "16 million developers per month" makes this the largest credential incident for a coding agent by user base to date. And as of that evening, there was still no security advisory on any public web asset—I fetched opencode.ai and opencode.ai/docs and searched, and found no mention of "breach" or "security." Notification went out by email only to identified accounts; if you're not on the list, you'd only learn about this through coverage like this article.

Distillation attack refers to attackers making massive calls to frontier models (such as GPT-4, Claude, Gemini), collecting their input-output pairs, and using them to train their own smaller models—thereby "distilling" the capabilities of large models. This kind of attack doesn't steal model weights; it steals inference behavior, at extremely low cost and with little traceability. For API providers, distillation attacks manifest as abnormally high call volumes and diverse prompts; for key holders, it means bill spikes. OpenCode's characterization of the intrusion as a distillation attack suggests the attackers' primary goal was to obtain model inference for free, rather than directly stealing funds or data.

The timeline is the most unsettling part

An hour-by-hour reconstruction circulating in the developer community (done by users, not the company) shows the earliest identifiable exposure at roughly 00:30 UTC on October 17, with the first notification email going out at about 22:51 UTC—a gap of roughly 22 hours. Specific minute figures should be treated as "reported" rather than "confirmed," but even by the company's own account ("intrusion last night," "email this morning," "public statement Saturday afternoon"), it describes a full day in which keys were live and exposed—and if the distillation-attack characterization is accurate, that's exactly what the intruders wanted.

Users noticed before any statement did. Reports of unauthorized provider usage began appearing on the evening of the 17th; dollar figures in public posts contradict each other—some say around $100, while lists cite individual accounts at $449, over $700, and $1,700—and no provider has publicly committed to refunding fraudulent usage. That divergence is itself a data point: a day later, there are no authoritative loss figures, only self-reported ones.

One detail on the response side I can't shake: according to a developer involved in the response posting (as relayed by incident coverage), the frontier models OpenCode initially used to help analyze attack material began refusing—the attack samples triggered safety filters—and the team had to switch tools mid-incident. The same week, defenders in the Hugging Face community investigation needed the same kind of access. We've built a world where the best incident-response assistant may be a model that refuses to look at the evidence.

Bearer token is a security token that grants access to resources to whoever holds it, without further proof of identity. API keys are typically used as bearer tokens; once leaked, anyone holding one can call services as the key owner and incur charges. Unlike passwords, bearer tokens aren't bound to a device or session and can't be strengthened with multi-factor authentication. A stored API key is therefore equivalent to cash: leaked means lost, and the speed of loss depends on call frequency. This explains why attackers in this incident could rapidly burn through large amounts of quota, and highlights the high risk of hosted workspaces holding keys.

What this is really about

Three lessons, in increasing order of how much people resist them.

Stored provider keys are bearer instruments. They're not account passwords with billing and chargebacks—they're cash spent at API speed. Any product that asks you to paste your key into a hosted workspace is asking to hold your cash, and should be audited on that basis.

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

A percentage without a denominator is anesthesia. "1.4% of users" sounds small and, as stated, is unfalsifiable. What users actually need is binary information: did you get the email or not. That's the correct unit. If you did: go to the provider dashboard (not OpenCode), revoke the key, reissue it, update every consumer of the old key, check usage after October 17, and confirm the old key actually stops working—a revoked key should return 401, and that "should" can be tested with a single curl.

I more or less make a living testing error surfaces. 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.

401 Unauthorized is the HTTP status code indicating a request lacks valid authentication credentials. When revoking an API key, the most direct way to verify the old key is truly dead is to make a request with it and expect a 401. If it returns 200, the key is still valid and the revocation didn't take effect. This method is more reliable than trusting what the console displays, because caching, latency, or misconfiguration can leave revocation status unsynced. The article's suggestion to test with curl is based on this simple, verifiable API behavior.

One-line Summary

OpenCode admits API keys for 1.4% of users may have leaked, exposing retired-system risks and response contradictions.

Paragraph Summary

OpenCode (the open-source coding agent under Anomaly Innovations) emailed some Console users admitting that OpenAI, Anthropic, and Google API keys stored in hosted workspaces may have leaked due to a compromised legacy system, characterizing the incident as a "large-scale distillation attack." Affected users make up 1.4% of Console users, but the company hasn't disclosed the total, so no concrete headcount can be derived. The intrusion was discovered in the early hours of October 17, with notification going out about 22 hours later, during which keys were exposed. The leak originated in a legacy console being retired; keys added locally via CLI are unaffected. Anthropic has revoked affected keys, but no provider has committed to refunds. During incident response, frontier models refused to analyze attack samples due to safety filters, forcing the team to switch tools mid-way. The article draws three lessons: stored provider keys are bearer instruments and should be audited like cash; decommissioning is an attack surface, and shutdown checklists must include credential rotation; a percentage without a denominator is anesthesia, and users should revoke and verify key invalidation themselves.