OpenCode suffers breach, triggers unauthorized charges on users' AI accounts
OpenCode, an open-source coding agent that has been gaining ground as an alternative to Claude Code and Cursor, confirmed a breach that exposed API keys belonging to some users of its online platform. The case also exposed a bigger problem: security teams struggle to use commercial AI models in incident response, because the models' own safety defenses block analysis of malicious code.

OpenCode, an open-source coding agent that has been gaining ground as an alternative to Claude Code and Cursor, confirmed a breach that exposed API keys belonging to some users of its online platform. The case also exposed a bigger problem: security teams struggle to use commercial AI models in incident response, because the models' own safety defenses block analysis of malicious code.
What happened
OpenCode, an open-source coding agent that has been gaining ground as an alternative to Claude Code and Cursor, said on Saturday, October 17, that attackers broke into an older company system overnight. The incident affected 1.4% of OpenCode Console users, the online platform where some developers store the API keys used to access AI services.
The company posted on X:
We had a security breach last night related to a large-scale distillation attack that impacted 1.4% of OpenCode Console users. We have notified them all this morning via email.
OpenCode, official post on X
According to the company, anyone who didn't receive the warning email wasn't affected. The incident, OpenCode said, is still ongoing, and the company has not yet detailed how attackers accessed the older system, how the keys were stored, or the full extent of the misuse.
What this so-called "distillation attack" is
OpenCode did not specify how the distillation attack happened in practice. The concept, broadly speaking, describes using a larger model to generate large volumes of outputs that train a smaller, cheaper model. Leaked API keys help with exactly that: they can let someone, especially in countries with restricted access to American models, generate the volume of responses that process requires without paying for it.
Not everyone buys this version. Some skeptics considered the "distillation attack" framing an overstatement, arguing that the episode was a straightforward breach and that the use of the credentials for distillation remains unproven. Either way, the practical result for users of the tool was the same: developers reported on social media spend alerts going off and charges they never made.
I saw my Open AI, Anthropic, and Google AI spend alerts all fire off before going to bed wondering what was going on.
Affected developer, via Reddit and X
Other users reported charges of hundreds of dollars on individual accounts; some described totals above a thousand dollars. Anthropic and Google blocked the keys they believed were exposed, and OpenAI said it worked with OpenCode to restore access and refund API customers for the credits used in the attack. OpenCode itself said refunds for the unauthorized charges are underway.
The console and the open-source tool are different things
An important point for day-to-day users of the tool: the exposed keys were confined to the OpenCode Console, where some users stored them in workspaces. The app and the open-source command-line tool were not affected, according to co-founder Dax Raad.
Note this is the OpenCode Console, not OpenCode itself, those keys never come to us.
Dax Raad, co-founder of OpenCode
In other words: the risk lies specifically in storing API credentials in a third-party managed cloud service, not in the code agent itself. It's a distinction that matters for any team evaluating where to store secrets for projects that use AI agents.
When the AI model itself gets in the way of the attack response
Raad said attackers tried to break into the company's systems nonstop for 48 hours, forcing the team to keep AI-based defense agents running continuously. But the AI models used to analyze the attack started refusing to work as soon as the malicious code they needed to examine triggered the models' own safety filters.
[T]hat was a bit frustrating.
Dax Raad, co-founder of OpenCode
OpenCode ended up getting access to OpenAI's Daybreak Blue program, which grants previously vetted users models that are less likely to refuse requests for defensive security work. With that access, the company said it was able to investigate the attack more thoroughly.
This situation isn't new. In July, Hugging Face reported that commercial AI models blocked attempts to analyze activity logs from a breach carried out by autonomous AI agents, a breach that OpenAI later revealed had been triggered by its own models running with reduced safeguards during an internal test. In a passage from the post about the case, titled "The Asymmetry Problem," the company wrote:
[Guardrails] cannot distinguish an incident responder from an attacker.
Hugging Face, official company blog post
Security researchers had already been raising similar complaints, saying the restrictions are inconsistent and end up pushing part of the market toward open-weight models developed outside the United States, which anyone can download and run without that kind of filter. The OpenCode episode caught the attention of David Sacks, co-chair of the President's Council of Advisors on Science and Technology:
OpenCode (and earlier Hugging Face) hit the same wall mid-attack: frontier models refused to analyze the very exploits needed for defense because the payloads tripped safety filters. The guardrails backfired.
David Sacks, co-chair of the President's Council of Advisors on Science and Technology (PCAST)
One contextual detail worth noting: the breach happened on the same night that OpenCode released the GLM-5.3-Flash model for free to its users. The broader GLM-5.3 family had already been drawing attention from researchers who study open-weight models for having cybersecurity capabilities close to those of restricted-access models, such as Anthropic's Claude Mythos Preview. The source does not establish a causal link between this release and the attack, only the coincidence of dates.
A pattern that isn't unique to OpenCode
The case adds to a recent string of AI-related cyber incidents. Earlier this month, security firm CrowdStrike said a China-based hacker likely used an AI pentesting agent, combined with Claude, in attacks on South Korean banks. The week before, India's cybersecurity agency warned that AI agents, including some still being tested by industry companies, accessed Indian organizations' systems without authorization.
What changes for those choosing AI-assisted coding tools
For technical teams in Brazil evaluating agents like OpenCode, Claude Code, or Cursor, the episode reinforces a point that usually takes a back seat when adopting the tool: where and how API keys are stored matters as much as the quality of the code agent. A managed cloud console is an additional attack surface, separate from the tool's open-source core.
In practice, some measures discussed in the episode itself work as an adoption checklist:
- Prefer, when the provider allows it, API keys with a configured spending limit, so that a leaked key doesn't turn into a bill of thousands of reais;
- Avoid storing API keys in third-party managed service workspaces when there's an alternative to running the tool locally or with your own secrets vault;
- Have a defined key-rotation routine, since OpenCode itself advised affected users to revoke and replace credentials directly with each provider;
- Consider, when choosing between an open agent and a managed service, that the open-source part and the cloud part of the same tool can have very different exposure levels, as shown by the distinction between the OpenCode Console and OpenCode itself.
The episode of guardrails blocking the very response to the attack is also a new data point for anyone considering using commercial AI models in defensive security routines: the same protection that keeps a model from generating malicious code can keep it from analyzing a real attack to help contain it. It's a trade-off that still has no ready-made solution, and it keeps resurfacing with every new incident of this kind.
Translated from the Brazilian Portuguese original · Read the original
KiviDB claims to be up to 9 times faster than Redis while keeping full compatibility
KiviDB is an in-memory database written in Rust that speaks the Redis protocol, adds native vector search, and publishes its own benchmarks against Redis, Dragonfly, and KeyDB. The numbers show a real gain in pure caching, but the story is more contested in vector search.





