TL;DR
OpenCode says a legacy Console-system breach affected 1.4% of Console users and that stored third-party provider keys may have been exposed. Affected users should revoke compromised credentials promptly, securely replace them, and review provider usage. The incident’s distillation label is OpenCode’s characterization; individual loss reports remain unverified for this briefing.
What actually happened
OpenCode reported unauthorized access to a legacy system it was decommissioning. Its customer email said provider keys saved in affected Console workspaces ‘may have been exposed,’ according to The Latent. OpenCode put the affected share at 1.4% of Console users and said it notified affected users individually.
The Latent reproduces OpenCode’s public statement describing a ‘large scale distillation attack’ and saying it was working with Anthropic, OpenAI, and Google on remediation. That is OpenCode’s characterization. The reporting does not establish the technical evidence behind that attribution.
The Latent reports that some users saw unexpected provider spending before OpenCode’s public acknowledgment. The distinction matters: account usage and incident notices are separate sources of evidence, and users should check both.
The bills landed before the disclosure
The Latent collected individual reports of unexpected charges, including $281 on one OpenAI account and $168 on an Anthropic account, alongside larger reported losses. These accounts are user reports, not independently verified loss totals for this briefing.
The same reporting describes one user’s Google project being suspended for suspicious activity. That individual account does not establish that Google was the only provider to act. Public reporting cited here does not establish a complete provider-response timeline or a universal refund outcome.
Why keys are the target now
The disclosed exposure concerns stored provider credentials. The broader scope of any data access has not been publicly established in the reporting cited here. Unexpected inference bills do not by themselves establish who used the credentials or whether the purpose was model distillation.
OpenCode’s Console documentation says the service stores connected provider credentials and routes workspace members’ requests through its gateway. Our view: shared credential gateways concentrate access and should be evaluated for credential isolation, incident response, and the limits available at the underlying provider.
What to do right now
If a provider key was affected or is suspected compromised, revoke it promptly through that provider’s own dashboard, recognizing that dependent services may stop working. Removing the connection from Console does not invalidate a copy of the key. Then create a replacement securely and update the connections and applications that need it. Follow the provider’s incident-response guidance and confirm the old key is revoked; there is no universal HTTP status code that proves revocation across every provider and interface.
Review provider usage and billing records around the incident, including the period before the notice, for unfamiliar activity. Preserve relevant notices and timestamps for support or a refund request. Use provider-supported enforced spending limits and alerts where available, and verify their scope: controls may apply to a project, workspace, or organization rather than an individual key. Check enforcement and reporting delays, and do not treat an alert-only budget as a guaranteed spending stop. Apply the narrowest supported key restrictions; Google documents Gemini-specific API restrictions where applicable.
Distinguish a direct connection using your own provider credential from a Console workspace connection. The /connect command alone does not prove local-only storage: Console members also use it to select a workspace. Check which credential and endpoint a connection actually uses. Not receiving an email is not proof that every credential is safe; compare your setup with the reported incident scope and your provider’s usage records.