One Point Four Percent: Anatomy of a Distillation Attack at the API Trust Boundary

The number is 1.4%.

Not 1.4% of revenue. Not 1.4% of inference tokens. One point four percent of OpenCode Console users — the developer-side accounts that hold API keys, watch usage meters, and settle invoices. That fraction, plus the phrase 'distillation attack', constitutes essentially the entire quantitative payload of the disclosure that surfaced this week through a crypto-native outlet: a report that named an attack class, attached a suspiciously precise number to it, and then stopped.

Two verifiable facts. A few sentences of commentary. No timeline. No attack vector. No statement on whether customer data left the building. No confirmation that the extraction was interrupted rather than completed.

Thirteen years of reading disclosures teaches you to read the shape of a claim before you read the claim itself. A pure AI-platform security incident, reported by a blockchain vertical, with zero crypto-asset content anywhere in the body — that is a channel mismatch, and channel mismatch is a diagnostic, not a coincidence. It tells you the story was relayed. Relayed stories lose mass in transit. What arrived here is the residue of a larger event, and the residue is thin enough that any confident reconstruction of OpenCode's specific technical failure would be fabrication wearing the costume of analysis.

So let me draw the line explicitly.

What I can assert: the attack class is real, it is a decade old, and under current API economics it is entirely rational. What I cannot assert: that OpenCode experienced the severe variant of it rather than the mild one. The distance between those two variants is roughly an order of magnitude in downstream harm, and the reporting collapsed them into a single headline noun.

Silence the noise, listen to the block height. The block height here is that 1.4% — and what makes it interesting is not its magnitude. It is its precision. Precision is a fingerprint. It tells you what instrument produced the measurement.

Context: The Mechanism Beneath the Label

Model extraction is not a novel attack surface. The academic literature that Tramèr and coauthors opened in 2016 — stealing model functionality through prediction APIs — and that Jagielski and others extended through 2020, established the entire playbook before large language models existed as a commercial category. The 2023 shift did not invent the technique. It repriced it.

Here is the mechanism, stripped of euphemism.

A model with valuable capability sits behind an API. The API returns outputs. Outputs are a function of the model's learned parameters. Therefore each response is a faint, lossy projection of the parameter space onto a single input point. Query enough input points, and you can reconstruct enough of the projection to train a student model that approximates the teacher — not perfectly, but well enough to compete on the specific distribution you care about. The student inherits capability without inheriting the research budget that produced it.

A modern distillation pipeline looks like this. Harvest a diverse prompt corpus — often synthetically generated, sometimes seeded from public datasets, sometimes scraped from forums and code repositories. Route those prompts through the target API with controlled temperature and sampling parameters to maximize output entropy. Store the (prompt, response) pairs. Filter for quality, deduplicate, and format into an instruction-tuning dataset. Then fine-tune a small open-weight base model — a seven-billion or thirteen-billion parameter class model — using LoRA adapters on commodity GPU time. The toolchain for this is not exotic. LLaMA-Factory, Axolotl, Unsloth, and a dozen similar frameworks have reduced the engineering barrier to a weekend of configuration work.

The economics are the entire story. Three cost lines: input tokens, output tokens, and training compute. Input tokens are cheap and mostly cacheable. Output tokens are the expensive line, because they scale with response length and because generation is the compute-bound path. Training compute for a LoRA adapter on a small base model is now measured in tens to low hundreds of dollars on spot instances.

Total cost to replicate a narrow slice of a frontier model's behavior: historically six figures, now plausibly four. That collapse — driven by 2024-2025 API price competition and by the maturation of parameter-efficient fine-tuning — is what converted model extraction from an academic curiosity into a commercially legible strategy. The attack did not get smarter. The attack got cheaper. Those are different problems, and only one of them can be solved with a terms-of-service clause.

Which brings us to the terms of service themselves. Every major model provider prohibits using outputs to train competing models. The existence of that clause is routinely read as evidence of diligence. I read it as evidence of unsolvedness. A contractual prohibition is what you write when you cannot enforce a technical one. It is the same category of gesture as a DeFi lending market that advertises a 'market-driven' interest rate curve when the parameters were set by three people in a governance call — the presentation implies a mechanism, the reality is an administrative choice. Clauses and curves alike are declarations of intent, not constraints on behavior. Neither binds an adversary who has already decided to be an adversary.

And the Console layer — the specific surface named in the disclosure — deserves attention, because it is the part most readers will skim past.

Console is not the inference endpoint. Console is the control plane. It is where API keys are minted and revoked, where usage is metered, where billing identities live, where team roles are assigned, where historical request logs may or may not be retained depending on the platform's logging defaults. An attack that reaches Console users has reached the identity layer, not merely the compute layer.

That distinction is where the entire severity question lives, and the reporting did not touch it.

Core: Where the Trust Boundary Actually Sits

The instinctive reading of a distillation attack is that the model is the asset under threat. That reading is wrong in the API context, and it is wrong in a way that causes platforms to underinvest in the correct defense.

Weights do not leak through an inference API. They cannot. What leaks is behavioral surface area — a functional approximation, never the artifact. So framing the incident as model theft misplaces the asset. The asset that actually moved, or may have moved, is access. Specifically: authenticated, billable, attributable access to a metered endpoint.

Follow the money through the pipe and the picture resolves. The attacker needs volume. Volume requires credentials. Credentials come from exactly two sources, and the difference between them is the difference between a risk-management failure and a security breach.

Path one: the attacker registered the accounts. Bulk registration via disposable infrastructure, email verification farms, payment instrument rotation, residential proxy pools. In this path, the victim set is OpenCode itself — its inference budget, its fraud controls, its unit economics. Console users are 'affected' only in the sense that the abuse inflated platform-wide metrics or triggered rate-limit policy changes that touched everyone.

Path two: the attacker obtained legitimate credentials. Leaked keys from public repositories, session token theft, credential stuffing against reused passwords, phishing against developer accounts, or an insider. In this path, the victim set is the Console users themselves — their quota consumed, their keys potentially reusable elsewhere, their historical prompts and completions exposed if the platform retains request logs and the attacker achieved Console-level read access.

These two paths produce the same headline and different universes of consequence. Path one is a cost-of-doing-business problem measured in dollars. Path two is a notification-obligation problem measured in regulatory exposure, contractual liability, and the slow erosion of developer trust that no roadmap recovers quickly.

The reporting did not distinguish them. That is not a minor omission. It is the single question that determines whether this is a footnote or a filing.

I have seen this structural confusion before, in a different domain. In 2017, while auditing the Aragon governance contracts during the ICO mania, I found four logic flaws in the permission architecture that could have paralyzed DAO decision-making. The lesson I took from those two months was not about governance. It was about where flaws concentrate. They concentrate in the permission layer, not the computation layer. The arithmetic is usually fine. The question of who is allowed to invoke the arithmetic is where systems break. Every audit since has confirmed it.

OpenCode's arithmetic — the model — is almost certainly fine. The permission layer is where the disclosure points, and it is where the disclosure is silent.

The Arithmetic of One Point Four Percent

Precision cuts both ways, so let us use it.

If OpenCode's Console base sits in the low hundreds of thousands, 1.4% is a few thousand accounts. If it sits in the low millions, it is tens of thousands. Either figure is far above the noise floor of casual abuse. Individual experimentation produces a handful of accounts and gets caught by rate limits inside a day. Thousands of coordinated accounts implies account pooling, automated scheduling, and distributed source addressing. That is infrastructure. Someone built a machine.

Now the cost side. Suppose the abusive calls represented 1.4% of platform inference volume during the exposure window. If OpenCode's daily inference spend ran in the low six figures, the misappropriated compute lands in the low-to-mid four figures per day. Sustained across a month, that is a six-figure leak. Not existential for a growth-stage platform. Entirely sufficient to distort gross margin in a quarter where investors are watching burn.

And the asymmetry that matters more than the dollar figure: the attacker's cost is the platform's revenue, but the attacker's benefit is the platform's moat. Every dollar of stolen inference is a dollar that funds a competitor's capability curve without funding the research that produced it. The loss is not linear in dollars. It is compounding in competitive position.

This is the same structural trap the bridge ecosystem has lived inside for years. Cumulative losses across cross-chain bridge exploits have passed two and a half billion dollars, and the industry still routes billions through them daily, because the alternative is fragmentation and fragmentation is worse. The dependency is not a failure of awareness. It is a failure of alternatives. API-mediated model access sits in the identical position. Platforms cannot withdraw the interface that makes them valuable, and attackers operate precisely inside that necessity. The paradox is not a bug to be patched. It is the shape of the business.

Detection Is a Platform Capability, Not a Model Capability

Here is where I diverge from most commentary on incidents of this type. The interesting question is not whether OpenCode was attacked. It is whether OpenCode could measure the attack to a tenth of a percentage point.

Being able to say '1.4%' is a capability disclosure disguised as a damage disclosure.

Consider what producing that number requires. You need per-account behavioral baselines. You need prompt-level features — length distribution, entropy, structural regularity, template repetition across accounts. You need response-level features — output similarity clustering in embedding space, divergence between requests that a human would make and requests that a sampling script would make. You need cross-account correlation to find the cluster, because a single account's behavior looks unremarkable in isolation. You need time-series anomaly detection to separate a burst from a drift. And you need all of it to run at inference-adjacent latency without destroying the product experience.

That is a substantial engineering stack. In 2020 I built a Python instrument to track capital efficiency across six DeFi protocols, and the hard part was never the math — it was the baselining. Establishing what normal looked like per protocol, per pool, per hour of day, so that a deviation was legible as a deviation rather than as noise. Fifteen percent of the arbitrage I eventually identified was invisible until the baseline existed. The detection layer is always the moat, and it is always built before the event that makes it famous.

OpenCode reporting a precise fraction means the baseline existed. It means the clustering ran. It means someone could distinguish the abusive cohort from the organic one. A platform that says 'a small number of users were affected' is telling you it does not know. A platform that says 1.4% is telling you it does — and chose to publish the resolution of its own instrumentation.

That is a genuinely bullish technical signal, and the reporting treated it as a damage statistic.

The Defense Menu and Why It Is Uncomfortable

The available countermeasures are well understood and uniformly awkward.

Output watermarking — the green-list/red-list token biasing approach popularized in 2023 — embeds a statistical signature in generated text that survives paraphrase to some degree and can be detected by the issuer. It works. It also introduces measurable quality degradation, creates a permanent detection surface that adversaries can study and strip, and produces a false-positive problem that becomes a customer-support liability the moment a legitimate user's output trips the classifier.

Output perturbation — adding calibrated noise to logits or to sampling — degrades distillation fidelity. It also degrades the product. Customers pay for the clean distribution. You cannot sell a model and simultaneously corrupt its outputs without a price concession, and the concession is usually larger than the loss you were defending against.

Model fingerprinting via canary inputs — embedding rare query patterns whose responses are uniquely identifying — gives you forensic attribution after the fact. It does not prevent extraction. It gives you evidence, which is useful only if you have a forum in which to use it, and the legal forum for model extraction is largely unbuilt.

Rate limiting and quota segmentation reduce throughput per credential. They also tax every legitimate high-volume developer, which is precisely the cohort that generates the platform's revenue.

Every option trades product quality for protection, and every trade is priced in churn. This is why the industry's actual answer has been contractual rather than technical, and why the contractual answer keeps failing. Security postures that must be sold to a growth team rarely get built to the standard that a security team would specify.

The same dynamic governs the rollup wars. The real difference between OP Stack and ZK Stack was never the proof system — it was which team could convince more projects to deploy a chain first. Distribution outran engineering, and the market rewarded it. AI platform security is on the same trajectory: the winner will not be the platform with the strongest anti-distillation stack. It will be the platform that convinces enterprise buyers it has one.

Contrarian: The Label Is Probably Wrong, and That Matters

The consensus reading of this event is that a frontier AI platform was robbed of its crown jewels and is now quietly managing the aftermath. I think that reading is likely incorrect on the technical facts and almost certainly incorrect on the strategic implications.

Start with the label. 'Distillation attack' is a term of art with a specific meaning: systematic extraction for the purpose of training a competing model. What the disclosure actually supports is far weaker. It supports anomalous bulk usage. Bulk usage could be distillation. It could also be output scraping for a dataset resale business, prompt-injection research, red-teaming, benchmark contamination, or plain reseller arbitrage — buying inference at one price and repackaging it at another. Each of those has a different threat model, a different defense, and a different severity. The media has a habit of reaching for the most dramatic available noun and then reporting the incident as if the noun were established. I have watched this happen to every category I cover. The bridge hack that turns out to be a key management failure gets filed under 'protocol exploit'. The stablecoin depeg that turns out to be a collateral composition problem gets filed under 'algorithm failure'. The label outlives the correction.

If OpenCode's weights are partially open — and many platforms in this segment publish or license model artifacts — then the entire economic premise of a distillation attack collapses. Why pay inference costs to reconstruct something you can download? Under that condition, the anomaly is almost certainly data scraping, not model extraction, and the severity drops by an order of magnitude while the correct response shifts entirely from 'protect the weights' to 'protect the logs'.

The reporting never asked. That is the bias that matters here — not sentiment, but selection. Two facts were carried forward; every question that would have determined which facts mattered was dropped.

Second contrarian point: this event is not a model-layer story at all. It is evidence that value is migrating out of the model layer and into the trust layer, and that migration is the actual macro pivot.

Distillation is only cheap because model capability has commoditized at the margin. If a small open-weight student can approximate a large teacher on a narrow distribution for four figures, then the teacher's capability premium is compressing. What does not compress is the audit trail. Provenance. Attribution. The ability to say with confidence which model produced which output, under whose credentials, at what time, with what data handling guarantees. In a market where capability converges, the durable asset is the verifiable record.

This is why my 2026 work on AI agent infrastructure kept returning to the same conclusion: autonomous agents require verifiable data provenance not because it is philosophically attractive, but because an agent that cannot prove the lineage of its inputs cannot be trusted with capital. A distillation attack is, at bottom, an attack on provenance. It launders capability through a channel that destroys attribution. The defense that survives is not a better lock. It is a better ledger.

Third: security incidents reprice sectors, not companies. The market has learned, painfully and repeatedly, that a breach is a manageable risk rather than a terminal one. What the market has not learned to price is the systematic underinvestment that a sector-wide pattern of breaches reveals. One distillation disclosure is a company event. Five, across five platforms in eighteen months, is a category event — it establishes that the API trust boundary is structurally weak and that every platform's margin carries an unpriced defense cost. That repricing has not happened. It will.

And the bear case nobody is writing: if distillation genuinely works at four-figure cost, then the moat around every API-first AI business is thinner than its valuation implies, and the correct posture is not to defend the model but to abandon the model as the product. Sell the orchestration. Sell the compliance artifact. Sell the audit log. Predicting the pivot before the pivot is printed means positioning before the margin compression shows up in the filings, not after.

Takeaway: Positioning for a Boundary That Is Being Redrawn

The architecture of value hidden beneath the hype is rarely where the marketing points. OpenCode's disclosure points at a model. The mechanism points at an identity layer, a metering layer, and an audit layer — three components that have nothing to do with model quality and everything to do with whether a platform can be trusted with other people's credentials and other people's capital.

For anyone allocating in this cycle, the practical implication is unglamorous. Watch what OpenCode ships in the next thirty days, not what it says. A credential rotation mandate, a granular key permission model, a usage anomaly alerting surface, a third-party audit attestation — those are the artifacts that convert an incident into a moat. Absent them, the incident converts into a competitor's slide deck, and the developer community's memory is shorter than its patience.

Watch the second-order signal too. If other platforms begin disclosing similar findings within two quarters, the attack was never OpenCode-specific. It was always the price of an interface that returns high-value text for fractions of a cent per token. And if that is the case, the question is no longer whether AI platforms will build a security layer. It is which ones will build it before their enterprise buyers make it a procurement gate rather than a differentiator.

The models will keep converging. They always do. What will not converge is the record of who did what, under which credentials, with which guarantees — and that record is the only asset in this stack that distillation cannot copy.

So the question worth sitting with is not how OpenCode lost one point four percent. It is this: when capability is free and attribution is expensive, which one do you think the next cycle will pay for?