OpenCode says an unauthorised party accessed an old system being retired and may have exposed customer-supplied API keys stored in its Console. The company reported that 1.4% of Console users were affected, according to Frandroid.
Those credentials let software send requests to OpenAI, Anthropic or Google models while charging the account that owns the key. The demonstrated consequence is therefore not limited to disclosure. Users reported receiving provider consumption alerts, including one account with €355 in unauthorised Anthropic charges and another with about €200 billed by Google before its project was suspended for abusive use, Frandroid reports.
Distillation describes the motive, not the entry point
Model distillation normally uses answers from a larger “teacher” model to train a smaller “student” model to imitate its behaviour. In an illicit version, stolen credentials and fraudulent accounts can fund large volumes of requests to a rival model, whose outputs then become training material, as explained in Frandroid’s account of the incident.
OpenCode associated its incident with that activity but did not publish evidence showing how the intruder entered, how long access lasted or how many keys were obtained. The available account also provides no indication that prompt injection caused the exposure. Based on OpenCode’s disclosure, the supported distinction is narrower: credential theft was the apparent means, while distillation was the stated motive.
That distinction matters operationally. A commercial team does not need to establish what model the attacker intended to train before containing a credential that can incur charges. The purpose of the unauthorised requests may guide the later investigation, but it does not change what an exposed key can authorise.
Conceptual illustration, not a photograph, separating credential theft from the stated distillation motive.
The exposed credential is the immediate decision point
An affected company has to choose between preserving an existing integration and invalidating a credential that another party may possess. The deciding criterion is not whether the incident carries a novel label. It is whether the key was stored in the affected service or whether unexplained provider usage indicates that it has already been used.
| Option | Appropriate condition | Direct trade-off |
|---|---|---|
| Revoke and replace the key | OpenCode identified the account as affected, or provider activity is unauthorised | Stops the old credential from authorising new calls but requires connected workflows to receive the replacement |
| Disable the dependent workflow first | The team cannot immediately identify where a replacement key must be installed | Interrupts the automation while preventing it from continuing with uncertain credentials |
| Wait for more information | The key was not stored in the affected Console and provider usage remains expected | Avoids unnecessary disruption but does not resolve unexplained consumption |
OpenCode said it emailed affected accounts and that users who received no message were not thought to be affected. Some users, however, noticed provider consumption alerts before receiving OpenCode’s notification, according to Frandroid. An inbox check alone therefore provides less direct evidence than the combination of storage history and provider-side usage.
Rotation must include every dependent workflow
Revoking a key contains its future use, but replacement is a separate operational task. A key connected to a coding agent may also be referenced by local developer settings, shared automation environments or deployment configuration. Replacing it in only one location can leave another workflow unavailable after revocation.
For a commercial operations team, the practical sequence is to identify which process uses the exposed credential, create a replacement through the relevant model provider, update that process and then confirm that the retired key no longer authorises requests. Provider billing and usage records are also the evidence needed to separate ordinary automation traffic from activity the team did not initiate.
This is especially important where an agent can switch between multiple model suppliers. OpenCode supports models from several providers, and the incident concerned users who had saved their own provider keys in its online Console, Frandroid explains. Each stored credential therefore needs an individual decision; changing one provider’s key does not invalidate another provider’s credential.
Conceptual illustration, not a photograph, of replacing a credential across connected workflows.
Waiting depends on evidence OpenCode has not published
Waiting can be defensible when the relevant key was never stored in OpenCode’s Console, the account was not identified as affected and its provider records contain no unexplained activity. It is harder to justify when a provider has already issued an abnormal-consumption alert or when the team cannot establish where the credential was stored.
Important facts remain unavailable. OpenCode has not disclosed the intrusion method, the duration of access or the number of credentials obtained. Its reported percentage is also difficult to translate into an absolute number because the company has not published the Console’s total user population, Frandroid notes.
The immediate decision should therefore follow credential exposure, not the distillation narrative. Teams with a stored key or unauthorised usage have evidence to revoke and replace it now. Teams without either signal can wait, but the next material update to watch is OpenCode’s account of which credentials were accessed and how the old system allowed that access.
