OpenCode API Key Leak: Do You Need a New Key? Four Steps from Exposure Checks to Cost Control
An API key pasted into an AI coding tool gives that tool access to your paid account. If you suspect a leak, closing the app or changing your password is not enough. Start in the management console of the company that issued the key.
Do you need to replace your key? If OpenCode notified you that you were affected, check the provider-specific revocation and replacement steps below. OpenCode’s official position is that users who received no email were not affected. Checking keys reused in other services is a separate precaution, not a finding that this incident affected you.
OpenCode is an open-source AI coding agent that helps you write code in a terminal, code editor, or desktop app. It connects to models from multiple providers, including Claude, GPT, and Gemini.
If news of the OpenCode key leak brought you here, check four things: where you stored your key, whether you have disabled any suspect key, whether there is usage you do not recognize, and whether your spending limit actually stops requests. Here is what to do, based on official guidance from OpenAI, Claude, and Gemini.
1. Check the scope of the OpenCode API key leak
The first question is simple: Did you connect an external AI provider’s API key to OpenCode Console? Check your account’s connection settings and the email address you signed up with. If a developer set it up, ask which provider and project the registered key belongs to. There is no need to ask them to send the full key over a messaging app.
OpenCode’s official notice says the incident affected some users who connected external providers, representing 1.4% of Console users, and that everyone affected was emailed. OpenCode’s official position is that users who did not receive an email were not affected.
The same notice says the incident is ongoing, that details cannot yet be shared, and that OpenCode is working with Anthropic, OpenAI, and Google on recovery. This article reflects the official notice as of October 18, 2026, at 19:35 KST (10:35 UTC). Check for any subsequent official updates.
Do not extend the notice’s scope to everyone who installed OpenCode or to every API key. Using the local CLI alone is not a basis for inferring a separate scope of impact. Compare the official guidance with your own connection history.
If you reused the same key in another service, reviewing its usage is AIB’s general precautionary advice. It does not mean you are being classified as affected by this OpenCode incident. Keep checking the incident’s scope separate from routine key-management checks.
2. Revoke and replace API keys: OpenAI, Claude, and Gemini
If abuse is ongoing, first weigh stopping further charges against service disruption. AIB recommends prioritizing revocation to stop continuing abuse. Official provider procedures differ: Claude advises immediate revocation when compromise is suspected, while Google’s leak-response checklist calls for deploying a new key before deleting the old one. Removing it from OpenCode’s connection settings does not, by itself, establish that the key is invalid.
- OpenAI: Replace the suspect key in the API key management page and review usage
- Claude: Find and delete the key under API Keys in Console. Official guidance says to revoke a key immediately if you suspect it has been compromised
- Gemini: The official rotation sequence is to create a new key, update and test your app, then disable and delete the old key. Manage the relevant project’s keys in Cloud Console
Creating a new key does not automatically remove the old one. Check which business apps, server secret settings, and automation tools still use the old key. Do not leave a key active solely to avoid downtime when you already suspect it is being abused.
Google’s sequence is designed to reduce disruption during key rotation. If abuse is ongoing, the person responsible should weigh continuing charges against service disruption and prioritize blocking the key. Verify the replacement by testing the actual app with the new key, not just by successfully running a chat in a management console.
If errors appear after replacement, do not immediately raise your limits. First determine whether the error concerns authentication, a usage limit, or your available balance.
3. Check for unusual API usage and charges
Check the provider’s Usage, Cost, or Billing pages for unusual activity and times of use. Narrowing the review to the connected project or workspace makes it easier to compare with normal work.
Look for three things: requests at times when you were not running anything, usage of models you do not use, and unusual cost increases. If you find something suspicious, record the relevant period and time zone, project name, amount, and any available request identifiers, then contact the provider through its official support channel. Never paste the API key itself into a support request or public post.
A higher bill alone does not prove unauthorized use. Cross-check scheduled jobs and legitimate activity by teammates. Likewise, additional charges appearing on a dashboard just after rotation do not necessarily mean the new key has also leaked. Billing data can arrive late. Distinguish when a request happened from when its cost appeared.
The goal is to move beyond worry. Document when the unfamiliar activity happened, which project it involved, and what you do not recognize so your operations team or provider has something concrete to investigate. This article does not guarantee refunds or compensation.
4. Set API spending limits: alerts versus enforcement
Saying “we set a monthly budget” is not enough. Distinguish settings that only send alerts from settings that block requests. Providers also apply their controls at different levels.
OpenAI lets you set a monthly spending limit for an organization or project and turn on Enforce a hard limit to block relevant requests when that limit is reached. Spending alerts alone do not stop requests. Enforcement can be delayed, so spending may slightly exceed the configured amount.
Claude separates spending limits from email alerts under a workspace’s Limits settings. A workspace limit must be lower than the organization’s limit; if no separate workspace limit is set, the organization limit applies. Check this when separating experimental tools from production services.
Gemini keys belong to projects; each key does not have its own independent billing configuration. Project spending limits in AI Studio are experimental. Reporting delays of around 10 minutes or long-running operations can result in overspending, and these spending limits are not available for invoiced accounts.
When testing a new tool, do not casually reuse a key from an existing service. Separate keys and projects or workspaces by purpose, and choose both alerts that someone will review and limits suited to the work. Set a limit too low, and legitimate services can stop too. Plan cost controls and service continuity together.
When choosing a new AI service, look beyond its features. Check where it stores keys, what permissions it requests, how to disconnect it and revoke keys, and where you can limit spending. If those answers are unclear, define a separate testing scope before handing over a production key.
Open your API management console now
Today’s task is not to study security terminology. Open the console of the provider that issued your connected key, then check connection history → suspect-key revocation and replacement → usage records → actual spending limits.
If your team is adopting more AI tools, start with a one-page record of who uses which key for which work. AIB helps businesses compare AI tools and put them to work. If you need help choosing tools, defining their scope, or planning how to operate them, tell AIB about your workflow.
Sources
Information current as of October 18, 2026. Coverage of the OpenCode incident is based on the official notice as of 19:35 KST (10:35 UTC) that day.