By asahifile 
OpenCode, the open-source AI coding agent built by Anomaly Innovations, disclosed on 17 October 2026 that a security breach had exposed API credentials stored on its servers. In a post on X the company said the incident “impacted 1.4% of OpenCode Console users,” that all affected accounts had been notified by email that morning, and that “if you did not get an email you were not impacted.” Notification emails told recipients that unauthorised access occurred to a legacy system slated for decommissioning, and that third-party provider keys saved in their workspaces may have been accessed externally.
What actually leaked
The credentials at risk belong to OpenAI, Anthropic, Google and other external model providers — keys that users had linked to OpenCode Console, the company’s bring-your-own-key gateway. Attackers did not need passwords or card numbers. They wanted the ability to fire large volumes of queries at expensive frontier models and have somebody else pay for it. Affected users reported hundreds of dollars of usage they never made. OpenCode co-founder Dax Raad said his own personal accounts were being attacked too, calling it a “whole new world with AI-powered hacking.”
The company has released no technical detail beyond its framing of a “large scale distillation attack,” saying the incident is ongoing and that it is working with Anthropic, OpenAI and Google on remediation. Distillation here means harvesting a model’s outputs at scale to train or imitate it — the outputs, not stored user data, are the stolen asset.
The naming problem that made it worse
Much of the confusion on Hacker News came down to branding. OpenCode Console is a hosted gateway service — closer to OpenRouter or a managed LiteLLM — and is distinct from the OpenCode CLI and desktop app that most people install. Console is where a team registers provider keys so they can be distributed to members through a gateway, which is precisely why the leak was consequential: the credentials sat centralised on OpenCode’s side rather than in local configuration files.
The announcement did not draw that line clearly. As one commenter put it, the leak involved a service “much less widely used” than the coding agent, and the team “did a terrible job of communicating this.” Scepticism went further: another commenter noted there was no public evidence for the mass-distillation framing, and others asked why the company’s servers held users’ provider credentials at all.
What affected users should do
Revoke and reissue every provider key through the OpenAI, Anthropic and Google dashboards, then update every CI job, script and teammate’s local setup that pointed at the old key. Check each provider’s usage and billing dashboard for calls you did not make, and set monthly spending limits or budget alerts so a future leak cannot run up an unbounded bill. OpenCode has published no compensation arrangement for charges already incurred, and the providers have announced none either.
The structural problem with bring-your-own-key
The breach is not really a story about one company’s patching. It is a story about where credentials live. A bring-your-own-key aggregator is convenient precisely because it holds many high-value keys in one place, and that convenience is the risk: a single compromised system converts into access across several providers at once. Stolen keys also behave differently from stolen passwords. They inherit the account’s spending power, they can bypass the per-user rate limits and quotas a provider would otherwise apply, and they can be pointed at models through an API path that never surfaces in the victim’s own tooling.
There is an awkward asymmetry in the response: providers offer no self-serve endpoint for a third party to invalidate someone else’s key, so remediation depends on affected users acting and on the labs helping manually. Commenters argued OpenCode should have revoked the keys centrally; others noted that any third party able to revoke keys on demand is itself a denial-of-service risk. The practical lesson is the one security teams repeat after every aggregator incident: stored keys are only as safe as the least-maintained system behind the product holding them.
What to watch
- Whether OpenCode publishes a technical post-mortem naming the legacy system, the access path and how keys were stored — the detail that would let other gateway operators audit themselves.
- Whether OpenAI, Anthropic and Google change how third-party gateways may store customer credentials, for example by pushing scoped or short-lived keys.
- Whether affected users are compensated for unauthorised usage, or whether the bill lands on them; no refund mechanism has been confirmed by either side.
- Whether teams move from hosted gateways back to local key management or self-hosted proxies.
Sources: Hacker News discussion, OfficeChai, Crypto Briefing, SmartScope, OpenCode on X