tl;dr Model distillation trains one model on another model’s responses. Collecting those responses takes access and money. Stolen API keys can provide both, charging the victim while an attacker builds training data. OpenCode’s breach shows why the services holding those keys deserve scrutiny.

On October 17, OpenCode disclosed a breach affecting 1.4% of its Console users and described it as related to a large scale distillation attack. The affected group had external model providers connected. Co-founder Dax Raad clarified that the affected product was the hosted Console.

That description leaves an obvious question: what does training a model have to do with stealing someone’s API key?

The connection is the cost of asking a good model millions of questions.

What is model distillation?

Suppose you want to build a model that writes better code. You could give a more capable model a collection of programming problems, save its answers, and use those examples to train your own model. The first model is the teacher. Yours is the student.

That is one form of model distillation: learning from another model’s behavior. The classic work by Hinton, Vinyals, and Dean explored compressing the knowledge of an ensemble into a single model. With language models, the training examples can include generated text, code, or explanations.

The student still needs a training process and compute of its own. It does not receive the teacher’s model weights, and a pile of answers does not guarantee equivalent performance. But useful examples can improve it without repeating all the work that went into the teacher.

Distillation has ordinary uses: a developer can train a smaller, cheaper model using a larger model they control. It becomes abusive when someone obtains access through theft or fraud and harvests responses without authorization.

A stolen key can pay for the teacher

A model API key lets software send requests under an account. In a paid account, those requests consume that account’s credits or generate charges. Someone who steals the key may be able to ask the same model the account owner uses.

Now put that key into a data collection pipeline. The attacker submits problems and saves the responses. The account owner pays for the requests. The attacker keeps the examples.

This connection is documented beyond OpenCode. In its September threat report, Anthropic said proxy services supplying unauthorized distillers used stolen API credentials belonging to legitimate companies and individuals. A stolen key can therefore enter a reseller’s pool before the organization collecting training data ever uses it.

Our reading of the incentive is straightforward: compromised accounts offer paid model access that someone else funds. A pool of accounts can also spread requests across separate limits and complicate attribution. That makes credentials useful raw material for an operation that needs a steady supply of responses.

This does not establish who attacked OpenCode, how they got in, or whether a particular model was trained using the affected accounts. The public statements cited here do not establish those details. They do establish why model access is worth stealing.

How much can one leaked key spend?

A key can spend against the account behind it. For the three providers in this post, published limits start in the hundreds of dollars a month on the first standard paid tier and rise as the account moves up.

USD per month for direct API accounts, checked October 20, 2026. These are published tier limits, not a fixed value assigned to each API key.

OpenAI and Anthropic apply these limits across the organization. Gemini combines usage across projects linked to the same billing account. New Anthropic organizations may start in an Evaluation tier below the standard limits shown here. Custom arrangements can differ.

Remaining prepaid credit and lower hard limits can reduce the amount available to an attacker. But an alert is not necessarily a cutoff: OpenAI’s spend alerts leave requests running, while hard limits stop them. Enforcement is not instantaneous. Google documents roughly ten minutes of billing delay and possible overages, so the number on the dashboard is not a guaranteed ceiling on the final bill.

Why store your key in a coding service?

Because it is convenient. A team wants one place to choose models, share access, and track usage without handing every developer the provider credential.

OpenCode’s Console documentation describes exactly that arrangement: the Console stores the credential and forwards requests through its gateway. The model provider bills the customer for those requests.

That puts another service in the path between your key and the model. Its credential storage, administration, backups, and retired systems become part of your security boundary. A key kept out of your own GitHub repository can still be exposed by an integration entrusted with it.

The conversations can carry secrets, too

There is a second route for credentials into this story. A developer pastes a configuration into a coding assistant to ask why it is broken. The configuration contains a real token. If an intermediary retains that exchange and passes it into a training pipeline, the token travels with it.

Anthropic’s September report described user exchanges being relayed to Claude and used for distillation. Its examples included a developer prompt containing active access credentials for Telegram, Feishu, and Notion. Anthropic redacted those values in the published report.

Those are different credentials from the API key paying for the conversation. One gives access to the model; the others were inside the material sent to it. Both need protection.

This is a separate, documented risk. OpenCode’s announcement does not establish that its users’ conversations were sold, published, or used for training. Nor does a secret appearing in training data prove a trained model will repeat it. The immediate exposure is already in the saved transcript and any copies made from it.

The cost of a leaked key

A leaked model API key can expose hundreds of dollars of spending on a starting paid tier, or a six-figure monthly allowance on an established account. The attacker gets the responses. Your account gets the bill, and your own applications can lose access when the shared allowance runs out. A monthly limit resets; it does not expire the key.

TruffleHog finds exposed credentials in repositories, filesystems, and other sources, and can verify supported keys against their providers. That helps you prioritize credentials that still work. Find the exposure, revoke the key at the provider, and stop someone else from spending your model budget.