An unexpectedly large AI bill can arrive long before a small development team notices its credentials have been abused. The technical problem might be a stolen API key, but the immediate business problem is who pays for the model usage and how quickly the team can stop it.
What actually happened
OpenCode disclosed a security incident affecting 1.4% of users of OpenCode Console, its online service. Attackers accessed an older system and exposed stored third-party AI API credentials, according to reporting based on OpenCode's statement. Users subsequently reported unauthorized usage and unexpected provider charges.
The percentage describes affected Console users, not everyone running the open-source OpenCode coding client. That distinction matters: using a tool locally does not automatically mean your credentials were stored in its hosted service. The incident illustrates how an additional credential storage point can turn one compromise into charges across several providers.
Why a small team cares
Consider a freelance developer building a booking website for a local business. They use a coding agent connected to multiple model providers and keep a single API key attached to the account for convenience. If that key is stolen, the attacker can consume paid inference capacity while the developer is working on an unrelated task.
The loss is not limited to the invoice. A provider may suspend access or exhaust available budget at the exact moment a client project needs to ship. Investigating usage, replacing credentials and checking whether connected services were accessed can consume a day that was supposed to be billable.
The practical boundary is between the coding tool and the credentials behind it. Credentials dedicated to one project or environment narrow the damage if an integration fails. Provider dashboards and usage histories are also part of operations, not just finance: they give you evidence about when abnormal spending began.
Hype vs useful
This does not establish that every AI coding tool is insecure. It establishes a concrete failure mode when third-party services hold keys that can spend money. The reported charge amounts are individual cases, not a forecast of what another developer will lose.
A sensible setup keeps permissions and financial exposure narrow. Where providers support enforceable quotas or limits, use them. Where they only offer notifications, understand that the bill can continue rising after an alert has fired. The goal is to make a compromised key a manageable incident rather than an open-ended financial liability.
