OpenCode’s breach, and what it could cost users

October 17, 2026. Reporting checked through 20:30 UTC. All cost-model figures are in U.S. dollars; reported losses retain the posters’ currency labels.

OpenCode has confirmed a security breach affecting 1.4% of its Console users, limited to a subset with external providers linked. The company said it had emailed everyone affected that morning and was working with Anthropic, OpenAI, and Google. Its public statement described the incident as ongoing and connected it to a “large scale distillation attack.” [1]

Colin Parsons reported $281 in OpenAI usage and $168 at Anthropic, a combined $449. Preston Zeller said a forgotten key had incurred more than $1,700 overnight. These are firsthand accounts of costs users associate with the breach, still unverified against provider records. [2] [3]

The aggregate bill remains unknown. One conditional illustration puts user costs at $3.5 million before refunds, excluding additional disruption losses, if Console has one million users and each affected user incurs an average of $100 in unauthorized usage plus $150 in recovery time. The user count and average costs are assumptions.

What OpenCode has disclosed

A screenshot attached to Matt Johansen’s post shows a Reddit post reproducing a customer notice headed “Action Required: Potential provider key breach.” It says someone gained unauthorized access to a legacy system OpenCode was decommissioning. Third-party provider keys saved in workspaces, including OpenAI and Anthropic keys, may have been exposed. The notice tells recipients to revoke and replace those keys through their provider dashboards, update applications, and review recent usage. It also apologizes and says follow-up information will come. The screenshot can be inspected, but the underlying email has not been authenticated. [4]

Johansen’s follow-up quotes his earlier post about DMs. Raad is describing attacks on his own accounts. Neither explains how someone got into Console or supplies a verified loss total.

OpenCode’s public GitHub security advisories cover earlier local-server vulnerabilities, with the latest entry dated September 24. They contain no technical account of the October Console incident. There is no basis in those advisories for attributing this breach to the earlier flaws. [7]

Why the hosted Console matters

OpenCode’s hosted Console is an optional service for individuals and teams, with workspaces, model access, usage controls, and connections to external providers. Using the coding agent does not require using Console. [8]

Console stores linked providers’ credentials and routes requests through its gateway. Workspace members can use a provider without seeing its underlying key. The provider bills the resulting token usage directly; those requests do not consume Console credits. [9]

That explains how a breach at OpenCode could produce a bill at Anthropic, OpenAI, or Google. A usable provider credential can authorize requests against the provider account. Depending on its permissions and billing settings, an attacker may consume paid credits or generate additional charges. OpenAI’s own security guidance describes unexpected charges, quota depletion, and interrupted access as consequences of a compromised API key. [10]

The disclosed scope does not establish that credentials configured only on a user’s own machine were taken. Parsons says he used his keys only with OpenCode; that does not identify whether he configured them locally or through Console. [2] These disclosures also do not establish theft of source code, conversations, SSH keys, GitHub tokens, or ChatGPT login credentials. Those would be separate claims requiring evidence. The provider catalogue also cannot be treated as a list of breached providers: supporting an integration does not mean its credentials were exposed.

OpenCode said users who did not receive an email were not affected. One later commenter reported a drained balance without having received a notice; that account is unverified. [1] [11] Anyone seeing unexplained usage should investigate it regardless of their inbox.

What a distillation attack would mean

Distillation uses a model’s outputs to train another model. It has legitimate uses, including making smaller models from a developer’s own larger ones. Anthropic’s February explanation of abusive distillation describes coordinated querying intended to collect training material without authorization. [12]

If that was the purpose here, compromised accounts could pay for the model responses an attacker wanted to collect. Users would bear the inference charges until the credentials stopped working or a provider intervened. That would fit OpenCode’s description, though it remains an unverified explanation of the attack.

Calling it a distillation attack describes an intended use of model access. It leaves the initial vulnerability, the attackers’ identities, and the volume of training data unestablished. It also does not show that an AI system autonomously carried out the intrusion.

Raad’s comments about AI-powered attacks do not settle those questions. Claims that AI-generated code caused the breach also require evidence from the affected systems.

The public statements also leave the credentials’ protection unclear. They do not establish whether the keys were stored unencrypted, taken from a running service, or obtained through another access path. A claim that this was a plaintext-storage failure would need evidence the disclosures do not provide.

The losses users are reporting

These reports have not been independently verified.

bleakj repeats the same claim, which should count once. [11] The same person or provider bill could also appear under different names on Reddit and X. Ambiguous currency labels and possible overlaps prevent a reliable combined subtotal.

The people posting are also self-selected. Someone with a large surprise bill has a reason to speak up; someone whose exposed key was never used may have nothing to report. Some claims describe team accounts, and several credentials can lead back to the same bill. These posts cannot establish the percentage of exposed accounts actually abused or the average loss across everyone affected.

Estimating the bill

Total user cost = unauthorized charges and lost paid credits − reimbursements + recovery time + additional disruption losses.

Count unauthorized spending once for each distinct provider bill. Consumed prepaid credits count once too: their original purchase and subsequent unauthorized consumption are not two separate losses. Promotional credits need separate treatment because their face value may not represent money the user paid.

Recovery takes time: someone has to find affected credentials, check logs, update services, and deal with support. Valuing that time captures an opportunity cost. An employed developer’s two lost hours may produce no extra cash payment, but they still displace work.

A suspended project or an interrupted service can cause further losses. Those need individual evidence before they enter the calculation, and the same lost working time should not appear in both the recovery and downtime totals.

OpenCode’s response expenses, provider compute costs, and any value an attacker assigns to a training dataset fall outside this calculation of user costs. Adding them could also count the same activity more than once.

The missing denominator

The 1.4% disclosure needs a matching count of Console users. The homepage’s claim of more than 16 million monthly developers describes the wider product population. Multiplying that figure by 1.4% to announce 224,000 victims would substitute one population for another. [13] [8]

A historical figure provides some sense of scale: an August 20 founder post reported 300,000 active OpenCode Go subscribers. That is a paid-plan metric from an earlier date. It does not establish the October Console population or imply that Go subscribers were the compromised group. [14]

A workspace can let multiple people use one provider connection, which complicates the count further. A shared $400 bill must not become $4,000 because ten workspace members were affected. Conversely, one person can have several provider accounts. A per-user model needs to count shared bills once, then allocate them across the affected population. [9]

Assumptions about individual costs

The model tests three assumed average costs across the entire affected group, including people with no unauthorized usage. The comments do not supply measured averages.

The reports do not establish how common any charge level is. A $100 average could, for example, describe a group in which a quarter incurs $400 each and the rest incur no usage charges. That example explains the assumption; it is not a finding about this breach.

The $400 scenario is a group average, not a cap on individual losses. Zeller reports a much larger bill. [3]

The hours and $75 hourly value are assumptions too. Time costs vary by country, employment arrangements, the number of connected services, and how much investigation a user undertakes. Replacing one unused key involves a different recovery task from repairing several production integrations.

Conditional estimates of the total

Applying the reported 1.4% rate gives these totals. Each Console population is hypothetical. The first borrows the scale of the historical subscriber disclosure, which does not establish the incident denominator.

These totals are before reimbursements and exclude additional disruption losses. They do not establish a floor, ceiling, or confidence interval: the evidence does not show which population is most likely. Some exposed users may lose no money and spend little time responding; some organizations could incur much larger costs.

The reference illustration also gives a useful scaling rule: at an assumed $250 burden per affected user, every 100,000 Console users implies $350,000 in total user costs. The calculation can be updated when OpenCode supplies the actual population and providers establish the average unauthorized spend.

Under the one-million-user illustration, the $3.5 million total consists of $1.4 million in unauthorized API usage and $2.1 million in recovery time. Reimbursements would reduce the first amount.

Refunds change who ultimately pays

If half the assumed unauthorized spending in that illustration were reimbursed, users’ remaining burden would fall to $2.8 million. If all of it were reimbursed, the modeled burden would be $2.1 million, entirely in recovery time. Additional proven disruption would increase those amounts.

The disclosures reviewed contain no incident-specific reimbursement commitment or provider-verified aggregate spending figure, so the refund rates are hypothetical too.

A refunded charge should be removed from users’ lasting financial loss. The provider or OpenCode may then bear an expense, but that reimbursement cannot be added back to the user-cost figure. Restored paid credits also need to be accounted for, with any restrictions on their use made clear.

Until the affected population and provider bills are known, the visible user reports are too sparse to justify a reliable estimate of the actual total or a probability range.

What affected users can do now

Start with the provider accounts whose credentials were saved in the hosted Console, and with any account showing unexplained activity. OpenAI’s published guidance recommends reviewing usage, immediately rotating suspected leaked keys, updating production applications, and contacting support to investigate. [10]

1. Revoke the exposed credential at its issuing provider. Removing a saved copy from an application does not invalidate a copy someone else holds.
2. Create a replacement where needed and update every legitimate service using the old key. Verify that the old credential no longer works.
3. Preserve usage records and charge details, including the relevant key identifier, project, and timestamps. Review activity before the notification as well as afterward; the precise intrusion window has not been disclosed.
4. Open a support case for unexplained usage or a suspended project. Ask whether the charges can be reversed and what evidence the provider needs.
5. Review provider-side spending controls, permissions, and credential lifetimes before restoring routine use.

A budget alert can arrive after spending has occurred. Google’s current documentation distinguishes alerts-only budgets, which do not automatically stop spending, from spend-cap budgets available for supported services. OpenAI similarly distinguishes spend alerts from hard enforcement and cautions that enforcement is not instantaneous. [15] [10]

If an attacker has a usable underlying provider key, requests could go directly to that provider without passing through a gateway’s budget checks. That follows from the architecture; it is not a confirmed account of the route taken in this incident. Provider-side restrictions therefore matter even when a tool offers its own spending controls.

What the next disclosure needs to answer

An affected percentage leaves customers with substantial uncertainty. OpenCode should publish the absolute numbers of affected users, workspaces, credentials, and distinct provider billing accounts, explaining how those categories overlap. Providers’ totals should distinguish attempted requests from completed billable usage and separate paid credits from new charges.

The technical account needs the initial access route, the period of unauthorized access, and an explanation of which credentials the legacy system could still reach. It should explain how the affected group was identified, how other data was assessed, and what evidence supports containment. Users replacing keys need to know whether the exposure that put the original credentials at risk has been closed.

The financial update should provide a claims process for unauthorized charges and lost paid credits. It should name who handles those claims, what evidence customers need, and when they can expect a decision.

Sources

The original posts by OpenCode, Dax Raad, and Matt Johansen, including Johansen’s earlier post, were read directly through Context.dev. Parsons’s and Zeller’s original posts were also retrieved in full. The inspected screenshot attached to Johansen’s post shows a Reddit post reproducing the notice. The underlying email and provider invoices have not been authenticated. User loss claims remain attributed reports.

1. OpenCode’s October 17 statement.
2. Colin Parsons’s original report of OpenAI and Anthropic charges. Dollar currency unspecified; the $449 combined figure is the sum of his two reported amounts.
3. Preston Zeller’s original report of more than $1,700 in overnight charges. Provider and dollar currency unspecified.
4. Customer-notice screenshot attached to Matt Johansen’s post.
5. Matt Johansen’s follow-up with the notice screenshot, quoting his earlier post about DMs and API charges.
6. Dax Raad’s October 17 post.
7. OpenCode’s public GitHub security advisories, checked October 17.
8. OpenCode documentation: Console introduction.
9. OpenCode documentation: Console providers, credential storage, and billing.
10. OpenAI: Best practices for API key safety, current documentation checked October 17. This is general provider guidance, not an OpenAI statement confirming the OpenCode incident.
11. Public customer discussion and firsthand reports on r/opencode. The individual $400 Anthropic report is also available separately. Comments include repeated reports by the same user; amounts are not independently verified.
12. Anthropic: Detecting and preventing distillation attacks, February 23. Used for the technique and general pattern only; the actors named in that earlier article are not attributed this breach.
13. OpenCode homepage, which displayed more than 16 million monthly developers when checked.
14. Jay’s post reporting 300,000 active OpenCode Go subscribers, dated August 20 in RuntimeWire’s contemporaneous report. Historical Go subscriptions are not the October Console-user denominator.
15. Google Cloud: Budgets and budget alerts, current documentation checked October 17.