OpenCode Security Breach 2026: API Keys Exposed, Unauthorized AI Charges, and What Developers Must Do

Key Takeaways

• OpenCode confirmed a security breach on October 17, 2026, affecting approximately 1.4% of OpenCode Console users who had connected external AI model providers.
• Third-party API keys may have been exposed after unauthorized access to a legacy system that OpenCode was preparing to decommission.
• OpenAI, Anthropic, and Google are involved in remediation. Anthropic confirmed that it revoked Claude API keys believed to be affected.
• Developers reported unexpected AI API charges, including approximately $400 in Anthropic spending and more than $1,000 in Google Cloud usage. These are individual reports, not independently verified totals.
• The incident primarily concerns OpenCode Console, the hosted platform that stores external provider credentials. Local OpenCode installations were not identified as the compromised system.
• OpenCode leadership stated that refunds were underway, but no comprehensive public reimbursement policy had been established.
• Potentially exposed credentials should be revoked at the original AI provider, not merely removed from OpenCode Console.
• The exact intrusion method, number of compromised credentials, total financial losses, and identity of the attacker remain undisclosed.

On October 17, 2026, OpenCode, the open-source AI coding assistant, disclosed a security breach involving its hosted Console infrastructure. The company linked the incident to a large-scale AI model distillation attack and confirmed that a subset of users who had connected external AI providers were affected.

The announcement quickly attracted attention after developers reported unexpected charges appearing in their OpenAI, Anthropic, and Google accounts.

Unlike a conventional password leak, a stolen AI API key can immediately become a financial liability. An attacker possessing a valid credential may be able to generate large volumes of model inference requests while charging the legitimate account holder for the resulting token consumption.

The incident also exposed a broader security problem: AI coding tools increasingly act as intermediaries between developers and commercial model providers, sometimes storing credentials that can authorize substantial spending.

This analysis examines the confirmed facts, affected configurations, potential attack mechanisms, reported financial losses, official responses, and practical steps developers can take to protect their accounts.

Last updated: October 19, 2026.

What Happened in the OpenCode Security Breach?

OpenCode publicly acknowledged the incident through its official security announcement on X on October 17, 2026.

The company confirmed that a security breach had occurred during the preceding night and described it as related to a large-scale distillation attack.

According to OpenCode's announcement:

• Approximately 1.4% of OpenCode Console users were affected.
• The affected accounts were a subset of users who had connected external AI model providers.
• All users identified as affected had been notified by email.
• OpenCode was working with Anthropic, OpenAI, and Google on remediation.
• The investigation was ongoing, limiting the technical details the company could disclose.

OpenCode also stated that users who did not receive a notification were not impacted according to its investigation at that time.

However, the 1.4% figure applies specifically to OpenCode Console users, not to everyone who has installed OpenCode on a computer.

The Compromised Legacy System

Affected customers received a security notification titled Action Required: Potential provider key breach.

According to the notification, OpenCode identified unauthorized access to a legacy system that was already being decommissioned.

Third-party API keys saved in affected Console workspaces, including OpenAI and Anthropic credentials, may have been exposed.

Recipients were instructed to:

1. Revoke potentially exposed credentials through their original providers.
2. Generate replacement API keys.
3. Update applications and integrations using the old credentials.
4. Review recent model usage for unexpected activity.

The notification was shared publicly in a Reddit discussion among OpenCode users.

Importantly, potential credential exposure does not prove that every affected key was actually extracted or abused.

OpenCode has not disclosed how many credentials were accessed, how many remained valid, or how the attacker initially entered the system.

Why Legacy Infrastructure Creates Security Risks

A system being decommissioned can remain vulnerable even after its main functionality has been replaced.

Legacy services may retain database connections, authentication credentials, encryption capabilities, internal network access, or permissions that are no longer required.

If those components remain accessible, an attacker may exploit an overlooked system to reach more valuable resources.

The general risk involves three conditions:

• An older service remains reachable or accessible through another compromised component.
• The service retains access to sensitive credentials or credential-management infrastructure.
• Those credentials remain valid at downstream providers.

Together, these conditions can make a relatively unimportant legacy application an entry point into financially valuable systems.

This is an architectural explanation rather than a confirmed reconstruction of the OpenCode intrusion. The company has not published sufficient forensic information to establish the precise failure mechanism.

OpenCode Security Breach Timeline: October 16–19, 2026

The following timeline combines official announcements, customer notifications, and publicly documented responses. Times are expressed in UTC where available.

Some affected users received follow-up notifications reportedly identifying October 17 at 00:30 UTC as the earliest possible exposure time.

That timestamp should not be treated as a confirmed intrusion start time.

Additional chronology is documented by the VibeIncidents security incident tracker and StepSecurity's incident analysis.

Who Was Affected by the OpenCode API Key Leak?

The most important distinction is between the locally installed OpenCode coding agent and OpenCode Console, the hosted service.

Although they share a product name, their credential-management architectures differ significantly.

OpenCode Console: Credentials Stored in the Cloud

OpenCode Console is an optional hosted platform that provides shared workspaces, centralized provider integrations, model access, request tracking, and budget management.

According to the official OpenCode Console provider documentation, workspace administrators can connect external AI providers using their existing credentials.

Console stores those credentials and routes requests through its own gateway.

A typical configuration works as follows:

1. A workspace administrator connects an external provider such as OpenAI or Anthropic.
2. The administrator supplies the provider's API credential.
3. OpenCode Console stores the credential for future requests.
4. Authorized workspace members send inference requests through Console.
5. Console forwards requests to the upstream model provider.
6. The upstream provider bills the credential owner for the resulting usage.

This architecture allows team members to access enabled models without directly receiving the underlying provider credentials.

However, it also creates a centralized repository containing secrets that authorize billable inference requests.

That repository is relevant to the October 2026 breach.

Local OpenCode: Credentials Managed by the Client

OpenCode can also run locally and connect directly to model providers.

Developers may configure credentials using the /connect workflow, CLI authentication commands, environment variables, or supported OAuth mechanisms.

In those configurations, credentials are managed by the local OpenCode installation or its configured server environment rather than automatically uploaded to an OpenCode Console workspace.

OpenCode co-founder Dax Raad publicly clarified that the reported breach involved Console, not the local coding agent.

Consequently, developers who only used locally configured OpenCode credentials were not identified as part of the confirmed Console exposure.

This does not guarantee that every local development environment is free of unrelated security vulnerabilities. It defines the known scope of this specific incident.

Exposure Risk by Configuration

An additional distinction concerns externally supplied provider credentials versus OpenCode-issued service credentials.

A Console API key used to authenticate to OpenCode's gateway is not necessarily the same as an OpenAI or Anthropic API key stored by Console.

Those credentials have different issuers, permissions, and billing relationships.

The public disclosure specifically emphasized external provider connections.

What Is an AI Model Distillation Attack?

OpenCode's description of the incident as a large-scale distillation attack is particularly significant.

Model distillation is a machine-learning technique in which outputs from one model are used to train another model.

A smaller model can learn patterns from responses generated by a more capable model, potentially reproducing some of its behavior without undergoing the same original training process.

Distillation itself is not inherently malicious. Authorized knowledge transfer is widely used in machine learning.

Security and contractual concerns arise when an attacker collects model outputs through unauthorized access, compromised credentials, fraudulent accounts, or other prohibited methods.

Anthropic discussed this distinction in its February 2026 publication on detecting and preventing distillation attacks.

How Stolen API Keys Could Support Model Distillation

A possible attack sequence involves several stages:

1. An attacker obtains valid credentials capable of accessing commercial AI models.
2. Automated software submits substantial numbers of prompts using those credentials.
3. The models generate responses that are collected by the attacker.
4. The responses are organized into a potential training dataset.
5. The attacker may use the dataset to train or fine-tune another model.
6. The original API credential owners are billed for the inference requests.

This method may offer attackers two advantages.

First, it shifts inference costs away from the attacker and onto legitimate customers.

Second, previously established paid credentials may be less conspicuous than newly created fraudulent accounts, although provider-side anomaly detection can still identify suspicious usage.

The relationship between the security breach and model distillation remains incompletely explained by OpenCode.

The company's terminology does not establish that every exposed key was used for distillation or that a downstream model was successfully trained.

Why AI API Keys Are Financially Valuable

Commercial language-model APIs generally charge according to consumption, including input tokens, output tokens, and sometimes additional service-specific usage dimensions.

Complex reasoning tasks, large context windows, repeated requests, and long generated outputs can significantly increase spending.

Consider a hypothetical provider charging $10 per million output tokens.

Generating 20 million output tokens would incur the following output-token cost:

20,000,000 / 1,000,000 × $10 = $200

Generating 200 million output tokens would cost $2,000 for the output tokens alone.

These are illustrative calculations, not verified OpenCode attack volumes or actual pricing for a specific model.

The example demonstrates why access to a high-capacity API credential can have direct monetary value.

An attacker may not need the account owner's password, payment information, or administrative dashboard access to create significant costs if the exposed key independently authorizes billable requests.

How Much Money Did OpenCode Users Lose?

OpenCode has not published a verified total for unauthorized inference spending or the number of compromised credentials that generated charges.

However, several developers reported abnormal usage during the incident window.

In the OpenCode Reddit discussion, user razorpolar reported approximately $400 in unauthorized Anthropic spending.

User bleakj reported more than $1,000 in Google Cloud API charges.

Other participants reported smaller unexpected costs, depleted prepaid balances, and Google Cloud project suspensions.

Reported Financial Impact

Additional reporting from Dealroom described claims involving hundreds or more than a thousand dollars in unexpected usage.

These figures should not be combined into an official incident total.

They also do not establish the average financial loss among affected users.

A potentially exposed key may generate no unauthorized charges if it was already inactive, restricted by an effective spending cap, revoked quickly, or never used by the attacker.

Why Some Users Experienced Larger Charges

The financial consequences of credential theft depend on several variables:

• Spending capacity: Accounts with larger approved limits may authorize more inference before billing restrictions intervene.
• Model selection: Premium reasoning models may cost more per token than smaller models.
• Rate limits: Higher throughput can allow more requests during a short attack window.
• Detection speed: Early anomaly detection and credential revocation reduce the time available for abuse.
• Budget enforcement: Provider-side spending caps can limit additional costs.
• Automatic recharge: Prepaid accounts configured to replenish balances may make additional spending capacity available.
• Credential scope: Broadly permitted credentials may authorize services beyond the developer's intended use.

These factors explain why a single credential-exposure incident can produce very different outcomes across individual accounts.

Will OpenCode Refund Affected Users?

OpenCode co-founder Dax Raad publicly indicated that affected users had been contacted and that refunds were underway.

His response is available in the public discussion about reimbursement.

However, as of October 19, 2026, no comprehensive public reimbursement policy established universal eligibility, guaranteed refund amounts, or final responsibility between OpenCode and upstream model providers.

Affected developers should preserve billing evidence and submit disputes through the relevant provider's support process rather than assuming automatic reimbursement.

How to Check Whether Your OpenCode API Keys Were Compromised

The first step is to determine whether third-party credentials were stored in OpenCode Console.

The second is to establish whether those credentials generated suspicious upstream usage.

Step 1: Check for OpenCode Security Notifications

Search the mailbox associated with the Console account for the subject Action Required: Potential provider key breach.

Also review spam, archived notifications, and shared administrative inboxes.

Some recipients reported receiving follow-up messages identifying affected workspaces and provider credentials.

OpenCode stated that users who had not received notifications were not impacted according to its investigation.

However, developers who remember storing externally billable provider keys in Console can still conduct a precautionary audit, especially while the investigation remains incomplete.

Avoid following suspicious links in unexpected security notifications. Navigate directly to official provider management pages.

Step 2: Review OpenCode Console Providers

Open OpenCode Console and inspect the provider integrations associated with each workspace.

Review credentials previously connected for services such as:

• OpenAI
• Anthropic
• Google Gemini
• Google Cloud or Vertex AI
• OpenRouter
• Other external model providers

Not every provider in this list has been confirmed as compromised. The purpose is to identify credentials that may have been stored in an affected Console workspace.

For each connection, record the provider, upstream project or workspace, credential identifier, approximate creation date, and dependent applications.

Historical connections matter because a developer may have stopped using OpenCode Console without revoking the associated upstream credential.

Step 3: Inspect Local OpenCode Authentication

Developers using the local OpenCode CLI can list configured authentication providers with:

opencode auth list

This identifies locally configured authentication connections but does not prove whether those credentials were previously uploaded to Console.

For OpenCode V2, the location of the local credential database can be displayed with:

opencode debug paths db

According to the OpenCode V2 provider documentation, newly saved API keys and OAuth tokens are stored in the server's SQLite database.

The typical local release database is ~/.local/share/opencode/opencode.db, although environment configuration can change the actual path.

Older OpenCode versions commonly used ~/.local/share/opencode/auth.json, and supported credentials may be imported during migration.

Never publish local authentication databases, complete credential files, or screenshots exposing API key values.

The existence of a local key does not demonstrate that the Console breach exposed it.

Step 4: Review Provider Billing and Usage

Inspect upstream provider usage from at least October 16 through October 19, 2026.

Look for:

• Requests occurring while the developer was not actively using the service.
• Sudden increases in daily or hourly token consumption.
• Unfamiliar model names or expensive model variants.
• Activity associated with old projects or unused API keys.
• Abnormal request concurrency.
• Unexpected credit exhaustion.
• Provider warnings about suspicious activity.
• New or unexplained billing charges.

Where possible, compare usage by API key identifier, model, project, and UTC timestamp.

A particularly useful investigation technique is comparing upstream provider activity with OpenCode Console request records.

If a provider reports substantial inference usage absent from the Console gateway's logs, direct use of a compromised upstream credential becomes one possible explanation.

However, delayed logging, incomplete records, different aggregation periods, and log retention limits can also produce discrepancies.

Step 5: Revoke and Replace Exposed Credentials

Potentially exposed API keys should be revoked through the original provider.

Relevant management pages include:

• OpenAI API Keys
• Anthropic Claude Console
• Google Cloud Credentials
• Google AI Studio

After revocation, create replacement credentials and update all legitimate consumers, including production applications, local development environments, CI/CD pipelines, secret managers, and other AI coding tools.

For a credential under active attack, stopping unauthorized usage takes priority over avoiding a temporary application interruption.

Deleting an integration inside OpenCode Console does not necessarily revoke the original API key.

A copied upstream credential may remain usable until its issuing provider explicitly invalidates it.

Step 6: Verify Revocation and Monitor Delayed Charges

Confirm that legitimate applications are using their replacement credentials.

Where safe and supported, verify that the old credential no longer authorizes requests.

Continue examining usage records after revocation because billing aggregation can lag behind actual inference activity.

Delayed charges are not necessarily evidence that the revoked credential remains active.

The effective end of unauthorized usage should be established from provider-side request records whenever possible.

How to Check OpenAI, Anthropic, and Gemini Billing

OpenAI API

Visit the OpenAI usage dashboard.

Review spending and token consumption by project, model, date, and available credential attribution.

Investigate unexpected activity from projects associated with OpenCode Console.

If unauthorized requests are identified, revoke the relevant key, preserve the billing details, and contact the provider's support team.

Anthropic Claude API

Use the Claude Console to examine usage and cost reports for the relevant organization and workspace.

Anthropic's workspace documentation explains how to manage workspace credentials, permissions, usage, and spending limits.

Anthropic representative Lydia Hallie confirmed publicly that the company had worked with OpenCode and revoked Claude API keys it believed were affected.

This upstream remediation can prevent future misuse of revoked keys, but it does not automatically establish that historical unauthorized charges have been reimbursed.

Google Gemini and Google Cloud

For Gemini API projects, review billing information through Google AI Studio and the applicable Google Cloud account.

For Google Cloud projects, inspect Cloud Billing reports and filter costs by service and SKU.

This distinction matters because Google Cloud billing can aggregate several services into one project-level total.

A spending spike may require additional investigation to determine whether it originated from the Gemini API, Vertex AI, or another authorized service.

Some users reported Google suspending projects after detecting suspicious activity.

Such intervention may reduce additional charges, but it should not be assumed to occur automatically for every compromised key.

How to Prevent API Key Theft From Becoming a Large Bill

The OpenCode incident highlights a fundamental security principle: AI API keys represent both access permissions and the ability to consume billable computing resources.

Effective protection therefore requires controls enforced by the upstream provider, not only inside an AI coding assistant.

Compare AI API Spending Controls

OpenAI: Enable Enforced Hard Spending Limits

OpenAI's official spending limits documentation distinguishes spending alerts from hard limits.

Developers can configure monthly organization or project spending thresholds.

To interrupt traffic after tracked spending reaches the configured amount, administrators must enable Enforce a hard limit.

When a hard limit is reached, affected requests return an HTTP 429 response with an applicable spending-limit error.

Enforcement is not instantaneous, so a small overage remains possible while the limit propagates.

A dedicated project with a relatively low hard limit is safer for experimental AI coding integrations than sharing credentials associated with high-capacity production workloads.

Anthropic: Separate Workspaces and Apply Spending Limits

Anthropic supports workspace-level controls for usage management.

According to its workspace documentation, eligible workspaces can receive monthly spending limits and rate-limit overrides.

These limits cannot exceed the organization's applicable limits.

The Default Workspace does not support custom workspace limits, making dedicated non-default workspaces useful for isolating external integrations.

A practical configuration gives a hosted coding assistant its own workspace and credential rather than reusing a broadly shared organizational key.

Rate limits and spending limits serve different purposes.

Rate limits constrain short-term traffic intensity, while spending limits constrain accumulated financial exposure.

Both are useful when protecting against automated API abuse.

Gemini API: Configure Project Spending Caps

The Gemini API billing documentation describes monthly spending caps at the project and billing-account tier levels.

Google notes that project-level caps are experimental and may experience approximately ten minutes of billing-processing delay.

Long-running batch workloads and agent sessions may also incur overages beyond a configured cap.

Consequently, developers should choose conservative thresholds and avoid treating these controls as perfectly instantaneous financial guarantees.

Google Cloud: Distinguish Spend Cap Budgets From Alerts

Google Cloud offers spend cap budgets for certain eligible services, including the Gemini API and Gemini Enterprise Agent Platform, formerly Vertex AI.

According to the official Google Cloud spend cap documentation, these controls can pause new usage after estimated spending exceeds the configured amount.

However, they are limited to eligible services and specific project scopes.

Traditional Google Cloud budget alerts are different: they notify administrators about spending thresholds but do not automatically stop billable requests.

A developer who has configured only an alert may still experience additional charges during an attack.

Why OpenCode Console Budgets Alone Cannot Protect Every API Key

OpenCode Console includes workspace, member, and service-account budgets.

According to the official Console budget documentation, these controls can prevent additional gateway requests when tracked spending reaches a configured monthly threshold.

The system can also count requests made through connected external providers when their models have configured prices.

However, the protection depends on where inference requests are processed.

Scenario A: Legitimate Requests Through Console

A workspace member submits a model request through the Console gateway.

Console evaluates applicable budget restrictions, records usage, and forwards authorized requests to the upstream provider.

Gateway limits can control this traffic.

Scenario B: Direct Requests Using a Stolen Upstream Key

An attacker obtains the original upstream API key and calls the provider directly.

Those requests may never pass through OpenCode Console.

The Console gateway therefore cannot be assumed to observe, count, or block that usage.

The upstream provider may still authenticate the key and attribute the resulting charges to the legitimate account owner.

This creates a critical distinction between gateway budgets and provider-enforced spending limits.

Gateway budgets protect traffic processed by the gateway.

Provider-enforced limits can protect the underlying billing project even when requests bypass the original gateway.

Both are useful, but they address different parts of the risk.

The Hidden Danger of Reusing One API Key Across Multiple AI Tools

Many developers use the same provider credentials across multiple coding assistants, backend applications, automation jobs, and experimental agents.

This creates two major problems.

First, compromising one integration can expose the same credential used by unrelated applications.

Second, identifying the source of unexpected usage becomes difficult when many workloads share one authentication identity.

Consider a developer using one Anthropic API key for OpenCode Console, a production web application, and a scheduled automation.

If the key is exposed through one integration, revoking it may disrupt all three workloads.

The developer must then determine which historical requests were legitimate and which were unauthorized.

A better architecture uses separate credentials for distinct trust boundaries.

This approach reduces the blast radius of a credential compromise.

It also simplifies incident attribution because suspicious activity can be associated with a smaller number of intended applications.

What Evidence Should Victims Collect for Refund Claims?

Developers who identify unauthorized charges should preserve evidence before logs become unavailable or are aggregated into less detailed billing records.

A useful evidence package includes:

• The OpenCode security notification and relevant workspace details.
• The upstream model provider and affected project identifier.
• A masked credential identifier or API key suffix, never the complete secret.
• The suspected unauthorized usage window in UTC.
• Daily or hourly spending reports showing abnormal activity.
• Model names and token consumption where available.
• Provider-side request identifiers and accessible audit logs.
• Credit depletion notices, suspension messages, or billing alerts.
• The estimated unauthorized amount separated from normal usage.
• The date and time the compromised credential was revoked.

One useful investigation technique is comparing the affected period with historical usage.

For example, if an application normally consumes approximately $3 per day and suddenly generates $400 in model spending overnight, that anomaly provides a clear starting point for investigation.

However, a spending increase alone does not prove fraud.

Strong evidence combines billing anomalies with credential identifiers, unexpected models, request timing, and the affected service's incident notification.

Refund eligibility depends on provider policies, account agreements, and the findings of the investigation.

A Similar October 2026 Incident at Fireworks AI

The OpenCode breach is not the only recent example of third-party AI infrastructure exposing customer credentials.

On October 9, 2026, Fireworks AI published an official security bulletin describing an incident identified on October 6.

According to Fireworks, an unauthorized party used compromised internal credentials to access environment variables associated with evaluation jobs in a limited number of customer accounts.

Those environment variables included stored API keys and tokens.

Fireworks reported revoking affected internal credentials and exposed Fireworks API keys, while instructing customers to rotate relevant third-party credentials through the original issuing providers.

The incident differs technically from OpenCode's publicly described Console breach, and there is no verified evidence connecting the two attackers.

Nevertheless, both incidents illustrate the risks created when AI infrastructure platforms store customer credentials for other services.

A useful architectural conclusion follows: every additional platform that receives a long-lived provider API key becomes another dependency in that key's security lifecycle.

Seven Security Lessons for AI Coding Assistants and Agent Platforms

1. API Keys Are Financial Assets

An AI API credential may authorize expensive inference requests even when it grants no interactive account access.

Credential-security programs should therefore account for financial exposure as well as data confidentiality.

2. Hosted Gateways Introduce Concentrated Risk

Centralized model gateways can prevent teammates from receiving raw credentials.

However, the gateway itself becomes responsible for protecting potentially large numbers of valuable secrets.

Credential encryption, access segmentation, auditing, and retention controls become critical architectural considerations.

The OpenCode incident does not establish which specific security control failed.

3. Retired Infrastructure Requires Credential Rotation

Decommissioning an application should include reviewing every secret the application stored or could access.

Disabling an interface is insufficient if upstream credentials remain active.

Credential retirement should be part of the infrastructure shutdown process.

4. Local Storage and Cloud Storage Must Be Distinguished

A locally configured credential and a credential explicitly uploaded to a hosted gateway have different exposure paths.

Developers should understand exactly where their AI coding assistant stores authentication material before connecting sensitive production accounts.

5. Independent Provider Logs Are Essential

A stolen upstream key can potentially be used outside the gateway that originally stored it.

Provider-side usage and billing records therefore provide an independent source of evidence during incident investigations.

6. Spending Caps and Rate Limits Are Complementary

Rate limits reduce the intensity of automated requests.

Spending limits reduce cumulative financial damage.

Neither should be confused with ordinary billing alerts or treated as a substitute for revoking a known compromised credential.

7. Credential Ownership Must Be Documented

Each external API key should have a known owner, intended application, provider project, spending limit, and revocation procedure.

Without this inventory, teams can lose valuable time identifying dependencies during an emergency rotation.

Recommended Incident Response Checklist for Development Teams

Organizations using hosted AI coding tools should implement a response process that covers both the compromised integration and upstream provider accounts.

Immediate Containment

• Identify Console workspaces containing external provider credentials.
• Revoke keys flagged as potentially compromised.
• Suspend nonessential integrations until safe replacements are available.
• Preserve security notifications and billing records.
• Check upstream accounts for unexpected usage.
• Record the suspected exposure window and relevant credential identifiers.

Credential Recovery

• Generate replacement keys in separate projects or workspaces where practical.
• Update production applications and secret managers.
• Replace credentials in CI/CD systems and automated agents.
• Verify that legitimate workloads operate correctly.
• Confirm that old credentials no longer authorize requests.
• Review pending charges for activity recorded before revocation.

Financial Protection

• Configure provider-enforced spending limits.
• Establish alerts below the maximum permitted spending threshold.
• Apply rate limits appropriate to each workload.
• Review automatic credit replenishment settings.
• Separate development and production credentials.
• Avoid reusing high-capacity API keys in experimental integrations.

Long-Term Hardening

• Maintain an inventory of all external AI provider integrations.
• Establish periodic credential rotation and retirement procedures.
• Review secrets stored in abandoned applications.
• Document ownership of each billable API credential.
• Require security assessment before storing production credentials in external gateways.
• Retain provider-side usage records where available.
• Conduct periodic incident-response exercises involving leaked credentials and unexpected inference charges.

What Remains Unknown About the OpenCode Breach?

Despite official confirmation and rapid initial remediation, several important questions remain unanswered.

How Did the Attacker Access the Legacy System?

OpenCode has not published the initial access method, exploited vulnerability, or complete root-cause analysis.

There is no adequate public evidence attributing the incident to a specific CVE, dependency, insider, software update, or AI-generated code defect.

Were API Keys Stored Without Encryption?

The public disclosures do not establish whether the affected credentials were encrypted at rest, decrypted by an application with legitimate access, or exposed through another mechanism.

A model gateway generally needs access to usable provider credentials when authenticating upstream requests, but that requirement does not prove insecure storage.

Claims about plaintext credential storage remain speculative without additional forensic evidence.

Were Source Code and Chat Histories Exposed?

The confirmed disclosure focuses on third-party credentials stored in Console workspaces.

No complete public forensic report has established whether additional categories of customer information were accessed.

At the same time, there is no verified basis for claiming that the incident compromised every local OpenCode repository or conversation history.

How Many API Keys Were Stolen?

The 1.4% figure represents a percentage of Console users, not a verified number of extracted credentials.

A single affected workspace may have stored several provider integrations.

OpenCode has not published the Console user denominator or complete credential inventory needed to calculate the absolute impact.

Who Conducted the Distillation Attack?

No attacker identity or organizational attribution has been independently established.

Claims linking the incident to a particular country, AI company, or model laboratory should be treated as speculation unless supported by further evidence.

Did the Attacker Successfully Train Another Model?

OpenCode's announcement described a connection to distillation but did not identify the collected dataset, the target models, or a resulting trained model.

Unauthorized model usage and actual downstream training are separate claims requiring different evidence.

Has Every Affected Customer Been Reimbursed?

OpenCode leadership indicated that refunds were underway, but a final accounting of reimbursements had not been publicly established by October 19, 2026.

Individual users should continue working with the relevant providers to document and dispute suspicious charges.

Frequently Asked Questions

Was OpenCode hacked in October 2026?

Yes. OpenCode confirmed a security breach on October 17, 2026, affecting a subset of its hosted Console users. The incident involved potential exposure of external AI provider credentials.

What percentage of OpenCode users were affected?

OpenCode reported that 1.4% of Console users were affected. This figure does not represent the percentage of all developers using the locally installed OpenCode application.

Were OpenAI and Anthropic API keys exposed?

OpenCode's customer notification warned that external provider credentials saved in affected Console workspaces, including OpenAI and Anthropic keys, may have been exposed.

Were Google Gemini API keys affected?

OpenCode named Google as a remediation partner, and some users reported suspicious Google AI usage or project suspensions. The complete provider-by-provider exposure inventory has not been publicly disclosed.

Is the local OpenCode CLI affected?

The confirmed security incident concerned OpenCode Console. Locally configured credentials were not identified in the public disclosure as part of the compromised hosted system.

Can someone use a stolen API key without knowing the account password?

Yes. A valid API key may authorize programmatic requests independently of interactive account credentials. Its capabilities depend on the permissions and restrictions configured by the issuing provider.

Does changing an OpenCode password revoke stolen provider keys?

Not necessarily. External API keys must be revoked through their original providers. Changing an OpenCode account password does not automatically invalidate separately issued OpenAI or Anthropic credentials.

Does deleting a provider from Console stop unauthorized usage?

Not necessarily. Removing a saved integration does not guarantee that a previously copied upstream API key has been revoked. The original provider must invalidate it.

Does the incident prove that another AI company trained a model using stolen outputs?

No. OpenCode described the incident as connected to a large-scale distillation attack, but the available public evidence does not establish the responsible organization, the collected training data, or the existence of a resulting model.

Can victims obtain refunds for unauthorized charges?

OpenCode leadership indicated that reimbursements were underway. However, no universal refund guarantee or completed financial accounting had been published by October 19, 2026.

Should users who did not receive a notification rotate their API keys?

OpenCode stated that users without a notification were not affected according to its investigation. Nevertheless, developers who previously stored external provider credentials in Console may reasonably audit or rotate those credentials as a precaution.

What is the most effective protection against AI API billing abuse?

The strongest practical approach combines separate provider projects, narrowly scoped credentials, enforceable spending limits, rate limits, usage monitoring, and immediate revocation of compromised keys.

Conclusion

The October 2026 OpenCode security breach demonstrates how credential infrastructure can become a financially significant attack surface for AI development platforms.

OpenCode confirmed that approximately 1.4% of its Console users were affected by a breach involving a legacy system and potentially exposed third-party model credentials. Anthropic participated in remediation by revoking affected Claude API keys, while some developers reported substantial unexpected spending.

The incident does not establish that every local OpenCode installation was compromised. Nor does it prove the attacker's identity, the precise intrusion mechanism, or the successful training of another AI model using stolen outputs.

Nevertheless, the underlying security lesson is clear: a valid API key stored in an external service can continue authorizing expensive requests long after its owner has stopped actively using that integration.

Developers should treat provider credentials as financially sensitive assets. Each external AI tool should receive only the permissions and spending capacity required for its intended workload.

Provider-enforced spending limits, credential isolation, independent billing monitoring, and systematic key retirement can substantially reduce the consequences of future exposure.

Developers who have used OpenCode Console should audit their connected providers, revoke potentially exposed credentials, inspect recent charges, and configure enforceable spending limits immediately.

For teams adopting AI coding agents at scale, the broader priority is to establish a credential-management strategy before the next security incident turns unauthorized model access into an unexpected bill.