Token Inflation: How Dishonest Providers Can Overcharge for Large Language Model Usage
Shahinul Hoque1 , Jinghuai Zhang2 , Jinyuan Sun1 , Fnu Suya1 University of Tennessee, Knoxville, 2 University of California, Los Angeles [email protected], [email protected], [email protected], [email protected]
arXiv:2605.30040v1 [cs.CR] 28 May 2026
1
Abstract Per-token billing is now the standard pricing model for commercial large language models (LLMs), so the honesty of reported token counts directly affects what users pay. We show that this kind of billing is hard to audit by design: providers hide the model, the tokenizer, and the execution to protect their IP, mitigate jailbreaks, and preserve user privacy, which means an auditor can only inspect proofs the provider supplies. The audit therefore reduces to a consistency check on the provider’s own reports. We call this a trust paradox: every audit must trust some artifact, but current frameworks trust exactly the ones a provider has the strongest reason to manipulate. We study three recent token auditing frameworks and show that a provider with ordinary commercial capabilities can systematically inflate billed token counts. In the most permissive setting, hidden reasoning usage can be inflated by 1,469% on average without detection. At current frontier reasoning prices, that turns a $100 honest bill into roughly a $1,569 bill on the same query. Even when the user can see the full reasoning string, tokenization ambiguity alone still allows 50.85% over-reporting below the detection threshold. These results suggest the problem is not in any specific auditor but in any audit whose evidence comes from the audited party. Restoring honest billing will require verification that ties reported token counts to evidence the provider does not control, such as trusted execution attestation, cryptographic proofs of inference, or thirdparty re-execution.
1
Introduction
Per-token billing has become the dominant pricing model for commercial large language models (LLMs), with frontier reasoning models charging tens of dollars per million tokens and processing large volumes of billed traffic across consumer and agentic deployments Bao [2026], Guo et al. [2025]. Even small inflation of reported token counts therefore translates into substantial overcharges at scale, making the integrity of reported token counts an economically consequential question. The same services that bill per token also have strong reasons to keep their internal computation hidden. Exposing the full reasoning trace would help competitors train similar models from it Guo et al. [2025], Carlini et al. [2024], make it easier to attack safety mechanisms through chain-ofthought hijacking Kuo et al. [2025], and risk leaking private user information from intermediate steps Tamber et al. [2025]. Today’s commercial reasoning APIs reflect this. OpenAI’s o1 and o3 models return only a short summary of their reasoning while still billing the user for the full hidden trace. Google’s Gemini 2.5 thinking models likewise return summaries instead of raw thoughts. Even Anthropic’s extended thinking interface only partially exposes the reasoning content. The user typically sees a short final answer while the bill includes many times more reasoning tokens that the user never gets to see, so any inflation in those hidden tokens is invisible by design. Preprint.
Auditing in this setting has a structural disadvantage. The opacity that creates the need for auditing is the same opacity that blocks it. Providers hide the model, the tokenizer, and the execution because of IP protection, safety, user privacy, and competitive concerns. This same hiding prevents the auditor from collecting any independent evidence of what was actually computed. As a result, the auditor must rely on artifacts the provider itself produces: similarity scores over hidden reasoning, predicted reasoning lengths from the prompt and answer, or aggregate statistics over reported token counts. We refer to this as a trust paradox: every audit must rest on some trust assumptions, but here those assumptions sit precisely on the artifacts a financially motivated provider is incentivized to manipulate. This is not just a thought experiment. Across three recent auditing frameworks, CoIn Sun et al. [2025a], PALACE Wang et al. [2025], and a martingale-based statistical auditor Velasco et al. [2025a], we show that producing evidence that looks honest is cheap for a provider that wants to overcharge. Simple and inexpensive strategies inflate reported token counts by up to 1,469% on average in the CoIn setting, by 247% in the PALACE setting where the auditor trusts data supplied by the provider, and by 50.85% even when the user can see the full reasoning string. At current output prices for frontier reasoning models, the CoIn case alone turns a $100 honest reasoning bill into roughly a $1,569 bill on the same query. Each of these numbers is concrete evidence of the same problem: when all the auditor’s evidence comes from the provider, the audit only verifies whatever the provider chooses to show. Contributions. Our main contribution is a structural diagnosis of current LLM token auditing, supported by empirical attacks against three recent frameworks that have not previously been subjected to systematic adversarial analysis. We argue that current auditing frameworks rest on a trust paradox: the same constraints that force providers to hide their computation also prevent the auditor from collecting evidence independent of the provider, so audits end up trusting exactly the artifacts a financially motivated provider has reason to manipulate. We instantiate this diagnosis on three frameworks. First, against CoIn Sun et al. [2025a], which audits hidden reasoning by checking semantic similarity between reasoning blocks and the final answer, a provider can reuse or fabricate semantically plausible reasoning blocks to inflate reported reasoning length by 1,469% on average without triggering detection (Section 3). Second, against PALACE Wang et al. [2025], which predicts hidden reasoning length from the prompt and answer, a provider can shift the auditor’s estimate by rewriting the answer style or appending trigger tokens, and, by exploiting PALACE’s reliance on training data supplied by the provider, inject small fraction of poisoning points to achieve targeted poisoning and backdoors triggered by specific phrases (Section 4). Third, against a martingale-based statistical auditor Velasco et al. [2025a] that operates even when the user can see the full reasoning string, tokenization ambiguity and selective inflation across samples still permit 50.85% over-reporting below the detection threshold (Section 5). Together, these results show that exposing more artifacts, even the reasoning string itself, does not solve the problem when those artifacts remain under provider control. Restoring honest billing will require verification mechanisms that bind reported token counts to evidence the provider does not control, such as attestation from a trusted execution environment, cryptographic proofs of inference, or deterministic re-execution by a third party, rather than ever more clever checks on signals the provider does control.
2
Background and Threat Model
Opaque LLM service. We consider an opaque LLM service where a user submits a prompt P , receives a final answer A, and is billed according to a provider-reported token count m. Internally, the provider may generate a reasoning trace R that is hidden from the user but included in usage accounting. Thus, the provider observes (P, R, A), while the user typically only observes (P, A, m), and in some deployments R as text. Depending on the service, m may include prompt tokens, visible output tokens, hidden reasoning tokens, or other provider-side tokens. Token count as a billing primitive. Token count is a convenient billing abstraction because prompts, reasoning traces, retrieved context, tool calls, and final answers are all token sequences, and major APIs use per-token pricing Bao [2026], Anthropic [n.d.]. However, current commercial deployments do not let users directly verify the underlying tokenization or hidden reasoning. Even 2
when R is exposed as text, tokenization ambiguity Sennrich et al. [2016], Kudo and Richardson [2018] can prevent a unique count, since distinct token sequences may decode to the same string. This is the slack that the auditing frameworks studied in this paper attempt to close. Dishonest provider. We assume a financially motivated provider that may over-report usage. The provider operates the service end to end: it runs the model, tokenizes inputs and outputs, generates any hidden reasoning trace, formats the answer, and reports the bill. When the auditor is trained on provider-supplied data, as in PALACE (Section 4), that data is also under provider control. In all settings, any provider-generated artifact used by an auditor, such as traces, embeddings, answers, auxiliary labels, or reported token counts, is part of the attack surface unless it is independently verifiable. Each framework section gives the framework-specific instantiation of these controls. Adversarial objective and audit assumptions. The provider’s goal is to increase reported token counts while passing the audit. Across the three frameworks, we identify the same pattern: each relies on behavioral assumptions that are plausible for cooperative providers but fragile against a financially motivated adversary. We do not claim that token-count auditing is impossible. Rather, we show that the assumptions used by current frameworks can be broken at low cost, compromising the integrity of those frameworks upon deployment.
3
Detecting Token Count Inflation via Semantic Similarity
We first describe the CoIn auditing framework, including its easy-to-violate assumptions in practice (Section 3.1), then show how a simple attack breaks its auditing (Section 3.2) and lastly show other attack variants based on the same principle (Section 3.3). 3.1
Auditing Framework Overview and the Easy-to-Violate Assumptions
CoIn Sun et al. [2025a] audits opaque LLM services in which the provider returns only the final answer while hiding the reasoning trace, and a trusted third-party auditor verifies billed hidden reasoning tokens. The framework has two components. Token-quantity verification commits the reasoning trace as fixed-length token blocks in a Merkle hash tree. Semantic-validity verification is what actually accepts or rejects a trace: it scores each committed block against individual tokens in the block and the final answer with two matching heads (token-to-block and block-to-answer), and uses a rule or learning-based verifier to decide if the sample is inflated or not based on the scores. Auditor’s information disadvantage. The auditor sees only what the provider chooses to commit, using criteria the provider can run in advance. Because the protocol requires the provider to compute embeddings under the auditors embedding model and satisfy the matching heads, the provider effectively has access to the same scoring functions used during auditing. This is not an extra attacker assumption; rather, it follows the framework’s protocol. As a result, the provider can search over candidates, score them locally, and commit one that passes. The audit therefore verifies only that a passing trace was found, not whether the submitted trace is the reasoning the model actually produced. Easy-to-violate assumptions. For the audit to catch inflation despite this disadvantage, two assumptions have to hold. CoIn implicitly assumes both, and a financially motivated provider can break each at low cost. Assumption 1: Merkle commitments bind the audit, not the trace’s origin. The Merkle tree prevents the provider from altering committed blocks after audit selection, but it does not check whether the original commitment was honest. The provider chooses which trace to commit at the start, and the committed trace is the only thing the auditor will inspect. Assumption 2: Matching heads distinguish honest reasoning from inflated content. CoIn assumes the embedding model is sensitive enough that fabricated or duplicated reasoning will score lower than honest reasoning. We show this is not true. Semantic similarity over learned embeddings tells you whether two pieces of text are close in meaning; it does not tell you whether the block was produced as part of the model’s reasoning Steck et al. [2024]. A duplicated block has an embedding identical to the original. A block generated by a separate model conditioned on the answer can generate traces semantically similar to the honest reasoning. Both pass the check. 3
(a) : RB mean=549.9%
Samples (b) : DA mean=1469.0%
Mean per block count (c) : HSB mean=1004.0%
(e) : RB + token mean=536.8%
(f) : DA + tokens mean=687.0%
(g) : HSB + token mean=984.8%
(h) : Qwen generated mean=611.0%
2
1
(d) : T5 generated mean=770.0%
3000
Inflation (%)
2000 1000 0
3000 2000 1000 0
1
2
3
4
5
6
7
8
1
2
3
4
5
6
7
8
1
3
4
5
6
7
8
2
3
4
5
6
7
8
Original reasoning-block count per sample
Figure 1: Mean per-sample inflation percentage across eight CoIn attack variants, grouped by number of original reasoning blocks. Diamonds indicate the mean inflation for each original block count. The assumptions fail to compose. Assumption 1 hands the provider full control over what gets checked; Assumption 2 means the check accepts a much wider set of content than honest reasoning. Each attack below breaks one or both assumptions with only seconds of compute per sample. 3.2
Simple Attack Breaks CoIn
Evaluation setup. We use CoIn’s official models and framework with the Glaive reasoning-v120m dataset Glaive AI [2025], one of the public datasets used in the original CoIn paper. Following the original setup, each reasoning trace is partitioned into fixed-length 256-token blocks using CoIn’s block-generation procedure. About 97% of evaluated samples contain between two and seven reasoning blocks, and we restrict our analysis to this range to avoid sparsely populated block-count regions. Inflation is reported as the percentage increase in committed blocks over the original block added blocks count: InflationPercent = 100 · original blocks . A trace is considered to evade the audit only if it is accepted by both CoIn’s rule-based and learned verifier. Additional implementation details, including verifier configurations and the iterative inflation procedure, are in Appendix B. Canonical attack chain. We illustrate the failure with the simplest version of the attack and the simplest defense one might propose against it. Naive attack: random block reuse (RB). The provider inflates the committed trace by re-inserting blocks from the honest reasoning trace. Because each duplicate is an identical copy of an honest block, both matching heads assign the same scores as before. CoIn accepts the inflated trace, yielding 549.9% mean inflation with only seconds of compute per sample (Figure 1(a)). Trivial defense: reject duplicate hashes. A simple defense is to reject traces with duplicate block hashes, which catches naive duplication while rarely affecting honest traces. Adaptive attack: hash-unique random block. The defense does not survive a small adaptation. The provider perturbs each duplicated block by inserting a small number of valid tokenizer tokens before or after the copied content. The blocks now have distinct hashes, but their embeddings are almost identical to the originals, so the matching heads still accept them. Inflation drops only slightly to 536.8% (Figure 1(e)). The adaptive attack closes back to within a few percent of the naive attack, because the embedding’s coarse semantic check cannot tell a duplicate from a duplicate-with-noise. 3.3
Other Attack Variants and Discussion
The remaining attack variants in Figure 1 exploit the same root cause with different tactics. Duplicating all repeatedly appends the full honest trace, reaching 1469.0% mean inflation (panel b), while its hash-unique variant reaches 687.0% (panel f). Highest-scoring block uses CoIn’s own scores to select and duplicate the block most aligned with the answer, reaching 1004.0% (panel c), or 984.8% with hash diversification (panel g). The generative variants fabricate new answer-conditioned blocks, reaching 770.0% with fine-tuned T5 (panel d) and 611.0% with LoRA-adapted Qwen2.5-1.5B (panel h). Across all eight variants, accepted inflation requires only seconds of compute per sample and 4
triggers neither verifier. Two patterns are worth noting. First, the highest-scoring-block attack shows that CoIn’s own scores can be used as a target for the attacker, not only as a signal for the auditor. Second, shorter traces tend to admit larger relative inflation before rejection, which suggests the audit becomes less sensitive when there is less honest reasoning to anchor the matching heads against. Discussion. A natural defense direction is to upgrade the embedding model: use a more sensitive backbone, fine-tune on a richer corpus, or replace cosine-based similarity with a learned discriminator that looks for legitimacy of reasoning rather than topical co-occurrence. We argue this does not address the underlying problem. The information disadvantage described above is fixed by the protocol: any embedding model and any matching head must be available to the provider in order for the provider to compute the embeddings the audit will accept. Whatever discriminator CoIn deploys, the provider has white-box access to it and can search against it. A decade of work in adversarial machine learning has shown that learned discriminators under white-box access can be cheaply evaded, and that proposed defenses tend to be broken or substantially weakened by adaptive attacks Athalye et al. [2018], Carlini and Wagner [2017]. A more sensitive embedding moves the boundary of what the check accepts; it does not close the gap between that boundary and the set of honest reasoning. Closing the gap would require either hiding the discriminator from the provider, which CoIn’s protocol cannot do, or replacing the audit with something that does not rely on a learned check over provider-supplied content. The latter is the direction we return to later.
4
Predicting Hidden Token Counts via Reasoning Length Estimation
We first describe the PALACE auditing framework and its assumptions (Section 4.1). We then show that provider control over answers and auxiliary data breaks both assumptions (Section 4.2). 4.1
Auditing Framework Overview and Easy-to-Violate Assumptions
PALACE Wang et al. [2025] audits opaque LLM services by predicting hidden reasoning length from the observable prompt-answer pair. The provider returns only the final answer and billing report, while the reasoning trace remains hidden. PALACE trains a domain-adapted auditor model on auxiliary data supplied by the provider, uses it to estimate the hidden reasoning-token count from (P, A), and flags reports whose counts significantly deviate from this estimate. PALACE inherits a deeper trust gap. The auditor receives P , A, the reported count, and provider-supplied auxiliary data DA , then flags reports that deviate from its prediction. However, the provider controls A, DA , and the reported count; only P comes from the user. The audit’s verdict is whether the reported count matches what the auditor estimates from (P, A), but the provider shapes both A and the auxiliary data DA used to fine-tune that estimator. Easy-to-violate assumptions. For the audit to detect inflation despite this disadvantage, two assumptions have to hold. PALACE assumes both, and a financially motivated provider can break either one independently. Assumption 1: Predictions from (P, A) are robust to provider control over A. PALACE estimates reasoning length from (P, A), assuming that superficial answer features, such as length, style, or certain tokens, do not substantially affect the estimate. We show this assumption fails: LLM-based predictors are sensitive to spurious input features Sclar et al. [2023], Errica et al. [2025], allowing a provider that controls A to inflate the predicted length. Assumption 2: Provider-supplied auxiliary data is faithful. PALACE trains the auditor on provider-supplied (P, A, reasoning length) tuples, assuming the data is unbiased and free of conditional triggers. Because the framework lacks an independent source of ground truth, a provider can bias the data or implant backdoors that activate on specific input cues and inflate the predicted number of tokens from the poisoned auditor model. The two assumptions protect separate parts of the audit. Assumption 1 protects against inferencetime manipulation through A; Assumption 2 protects against training-time manipulation through the auxiliary data. The framework grants the provider control over both, so each assumption faces a corresponding attack surface that the provider can exploit at low cost. Experimental setup. We evaluate the official PALACE domain-adapted auditor on Glaive reasoning-v1-20m Glaive AI [2025] and construct auxiliary datasets DA for the training-time attacks. 5
We focus on the domain-adapted auditor because it performs better than the general-purpose auditor in the original PALACE evaluation. Additional details, including the answer-rewriting prompt and backdoor configuration, appear in Appendix C. 4.2
Breaking PALACE’s Two Assumptions
Breaking Assumption 1: Steering the Auditor at Inference Time. The provider can shift the auditor’s length estimate without changing anything about the underlying reasoning, only by changing the surface form of the answer it returns.
400 600 Sample index
800
1000
82 %
75 %
70 % 73 %
74 % 76 % 72 %
30
(d) Triggered over-estimation Estimated token count
Estimated token count
(c) Poisoned fine-tuning 3200
Ground truth Original model Fine-tuned model
2400 1600 800 0
0
200
400 600 Sample index
800
6
200
40
3
0
50
5
500
60
N 9 U w LL it ho ut
1000
label: success rate
77 % 87 %
1500
70
80 %
2000
(b) Token-trigger sensitivity
80
d ni l () , () ;
Original Long Verbose
bo
Estimated token count
(a) Answer-style sensitivity
xe
Median token-count increase
Naive attack: Trigger-token sensitivity. We sweep across single tokens appended to the end of A and identify several tokens that consistently shift the auditor toward larger length estimates. Appending ‘boxed’ increases the predicted reasoning-token count by 82.4 tokens on average with an 82% success rate, ‘nil’ increases it by 73.7 tokens with an 80% success rate, and the numeric token ‘9’ increases it by 58.6 tokens with a 75% success rate (Figure 2(b)). These tokens are semantically irrelevant to the answer and are appended to A without changing its semantic meaning.
1000
3200 2400
Ground truth Benign prompt Triggered prompt
1600 800 0
0
250
500 750 Sample index
1000
Figure 2: PALACE auditor responses across four attack types: answer-style rewriting, appending trigger tokens to answer, auxiliary data targeted poisoning, and trigger-based backdoor on the auditor. Trivial defense: pre-normalize the answer. A simple defense is to canonicalize A before auditing, for example by stripping incomplete trailing tokens or rejecting unusual endings, mitigating triggertoken attacks with little cost to honest providers, whose answers rarely contain unusual trailing tokens. Adaptive attack: answer-style rewriting. The defense does not survive an adaptive strategy that replaces trigger tokens with semantically valid rewrites. We rewrite each answer in a longer or more verbose style using a separate Qwen3-14B model, preserving the original meaning while modifying only the surface form. The rewritten answers remain grammatically and semantically valid, yet the auditor’s predicted reasoning length increases by 30.30% on average for the long variant and by 16.62% for the verbose variant (Figure 2(a)). Because these rewrites do not introduce obvious surface anomalies, the pre-normalization defense does not catch them. Style rewriting is a simpler text-to-text task than generating a novel answer, and can often be performed by cheaper and faster models. This creates the leverage point for the attackers Raffel et al. [2020], Lewis et al. [2020]. Breaking Assumption 2: Corrupting the Auditor through Auxiliary Data. The provider can also manipulate the auditor itself by shaping the auxiliary data on which it is trained. Unlike the inference-time attacks, these attacks cannot be undone by any change to how the auditor reads the answer at audit time; they corrupt the auditor before it ever runs. Since the provider has complete control over the auxiliary data, it injects poisoned samples at any percentage relative to the total size. 6
Targeted poisoning. We poison 10% of the auxiliary training data by replacing ground-truth reasoning-token counts below 600 with values inflated to five times their original counts. We keep the poisoned labels within the three-sigma range so that they remain inside the natural distribution and avoid obvious outlier detection Pukelsheim [1994]. Because the auditor has no independent source for cross-checking these token counts, even a high 10% poisoning rate can remain undetectable. The poisoned auditor overestimates samples that originally fall in the 400–800 token range, while leaving higher-count samples largely unaffected (Figure 2(c)). Overall, the attack inflates 47.16% of samples below 600 tokens by 38.58% on average. Trigger-based backdoor. We additionally implant a conditional backdoor by inserting the trigger phrase Think harder at the start of the answer in 5.2% of training samples whose original counts are below 600, and replacing their labels with noisy inflated targets centered at 2917 tokens, while keeping the poisoned labels within 3σ. Because the trigger phrase is plausible natural language and appears in only a small fraction of a large auxiliary dataset, it is difficult for the auditor to identify and filter these poisoned examples. This difficulty is further amplified because the trigger phrase is chosen by the provider and is unknown to the auditor. At inference time, the trigger causes the auditor to predict substantially larger reasoning-token counts whenever it appears, while its behavior on untriggered prompts remains close to the unpoisoned baseline (Figure 2(d)). The backdoor inflates 99.91% of triggered samples, with a mean inflation rate of 247.16%. Implementation details are provided in Appendix C.3. Discussion. The natural defense is to harden the auditor through larger auxiliary datasets, less surface sensitivity, or stronger base models. We argue these do not address the underlying problem in either assumption. The information disadvantage we described comes from PALACE’s assumptions, rather than specific auditor instances. The provider produces A and supplies the training data DA by the framework’s own design. A more robust auditor would still be a learned predictor over (P, A), with A under provider control at inference time. Decades of work in adversarial machine learning suggest that such input-level vulnerabilities are difficult to prevent Carlini and Wagner [2017]. Assumption 2 is in a worse position. Detecting poisoning or backdoors in training data is itself difficult, and PALACE assigns the provider the task of supplying this data without independent verification. Any auditor trained on provider-supplied tuples therefore inherits the same trust gap. Closing it would require either training on data outside the provider’s control, which is difficult because the provider is the only party with labeled (P, R, A) tuples, or abandoning prediction-based auditing in favor of a mechanism that does not rely on untrusted training data.
5
Detecting Token Count Inflation via Tokenization Ambiguity
We first describe the statistical auditing framework and its assumptions (Section 5.1). We then show that strategic reporting can evade the aggregate test, and that calibrated offsets further increase the achievable token-count inflation (Section 5.2). Definitions of the per-sample deviation and martingale statistic are provided in Appendix D. 5.1
Auditing Framework Overview and Exploitable Assumptions
The third framework, Velasco et al. [2025a], audits in a more transparent setting than CoIn and PALACE, where the full reasoning trace R is visible as text. The auditor estimates the expected token count m̂i of each trace via Monte Carlo sampling and compares it with the provider-reported count mi , using Zi = mi − m̂i as the per-sample deviation. Thus, Zi > 0 indicates over-reporting. These deviations are aggregated into a martingale statistic Mt , and the provider is flagged when Mt > 1/α, where α controls the false-positive rate; we use α = 0.05 throughout following the original paper. Transparency does not remove provider control. The reasoning trace, which CoIn and PALACE treat as hidden, is visible here as text. If transparency alone resolved the trust paradox, this setting should favor the auditor. However, even when R is visible, the auditor cannot independently verify the token sequence used for billing or the reported count. Because tokenization is not unique Sennrich et al. [2016], Kudo and Richardson [2018], Gastaldi et al. [2024], distinct token sequences may decode to the same string, allowing the provider to choose a billable tokenization. Since the Monte 7
Carlo estimator and martingale test are public, the provider can simulate the audit before reporting and search for counts that pass. The audit relies on aggregate evidence. The audit’s verdict rests on a single assumption: aggregating per-sample comparisons of estimated and reported counts is sufficient to decide whether the provider is inflating. The auditor has no other check; if the aggregated comparisons do not cross the threshold, the audit accepts. A financially motivated provider can defeat this by strategically choosing what reported counts enter the aggregation, exploiting two empirical facts about the framework. Exploiting natural slack in the aggregate test. Fact 1: The Monte Carlo estimator systematically overestimates compared to the actual token counts on natural reasoning text, making the per-sample deviations Zi predominantly negative and giving the martingale Mt a negative drift even under honest reporting. Fact 2: Because the estimator, threshold, and dataset-specific drift are public, the provider can simulate the audit before reporting and search for inflation patterns that remain within this slack. The two facts compose in the obvious way: Fact 1 creates a buffer of negative drift; Fact 2 means the provider can search for inflation patterns that fit inside it. Together, they let the provider inflate the total billed count by 50.85% without crossing the detection threshold. Experimental setup. We use Medical-R1-Distill-Data Chen et al. [2024b] for the main experiments and validate the negative-drift pattern on four additional datasets in Appendix D.1. We adopt the Monte Carlo estimator and martingale test of Velasco et al. [2025a] with α = 0.05. We report inflation as the percentage increase in total billed tokens over the honest total across the audit horizon. (a) Strategically inflating token count
0.000025 0
0.000000 0
200
400
600
800
1000
Sample Index
60
2% 9. 2% 14 .3 % 19 .5 % 24 .7 % 29 .9 % 35 .1 % 40 .3 % 45 .6 % 50 .8 %
0.000050
20000
80
40
4.
0.000075
Offset
40000
(b) Offset needed for evasion in optimal setting 0.000100
Z-statistic Martingale M
Martingale M
Z-statistic
60000
20 0
0
2000
4000
6000
8000
10000
Injected Inflation
Figure 3: Evading the statistical auditor through selective inflation. (a): per-sample deviations Zi and the martingale Mt when every tenth sample is inflated by 2000 tokens; (b): offset required to keep Mt below the threshold while over-reporting. Negative drift under honest reporting. Across all four datasets, OpenThoughts-Code, OpenR1Math-220k, OpenThoughts-Math, and Glaive Reasoning-v1-20m, the per-sample deviation Zi is predominantly negative even under honest reporting (Appendix D.1). The magnitude varies by dataset, but the pattern is consistent: Mt decreases over time and remains far below the detection threshold. This is not a sample-size effect; the drift comes from systematic bias in the Monte Carlo estimator on natural reasoning text. The resulting negative drift gives the provider slack to introduce positive deviations through inflation without triggering detection. Below, we evaluate two such attacks. 5.2
Strategic Reporting Exploits the Slack
Naive attack. We over-report every tenth sample by 2000 tokens while reporting honestly on the rest. The inflated samples produce visible positive spikes in Zi (Figure 3(a), left), but Mt never crosses the threshold over the evaluated sequence (right). The natural negative drift from the other 90% of samples absorbs the positive contributions from the inflated 10%. Inflation magnitude sweeps in Appendix D.2 show this approach can handle 2000 tokens of per-sample inflation, with the test only beginning to fail at 2500 tokens. Stronger attack. The provider can further expand the available slack by slightly under-reporting the non-inflated samples. These small offsets push Mt farther below the threshold, creating additional room to over-report inflated samples. Because the offsets are orders of magnitude smaller than the injected inflation, the net inflation remains positive. We compute the compensating offsets 8
needed to keep Mt below the threshold and find that this strategy permits 50.85% total token-count inflation over the audit horizon (Figure 3(b)). Since the test only checks aggregate behavior, these small per-sample under-reports are not flagged. Discussion. Natural defenses are to update the threshold (larger α) or extend the audit horizon, but neither addresses the underlying problem. A larger threshold lowers 1/α at the cost of more false positives, without eliminating the attackers slack. A longer horizon also does not remove the negative drift, because the Monte Carlo bias is systematic rather than a finite-sample effect. The deeper issue is that the audit aggregates provider-supplied per-sample comparisons. Because the provider knows the estimator, threshold, and domain-specific drift, it can simulate the audit and select inflated reports that remain within the available slack. Closing this gap would require either making the audit non-simulatable by the provider or replacing the visible-string estimator with a provider-independent verification mechanism. In a setting where the reasoning string itself is exposed and the audit still fails, the takeaway is direct: exposing more artifacts is not, by itself, sufficient. The trust paradox applies whenever the audit’s check operates on artifacts the provider chose, regardless of how transparent those artifacts appear.
6
Related Work & Discussion
Related Work. Prior work on the trustworthiness of opaque LLM services has focused primarily on two problems: token-count inflation in pay-per-usage and model substitution by dishonest providers. Recent work highlights the need to audit opaque LLM APIs and the incentives for abuse under pay-per-token billing Sun et al. [2025b], Velasco et al. [2025b]. CoIn Sun et al. [2025a] and PALACE Wang et al. [2025] audit token-count inflation without access to hidden reasoning traces, while Velasco et al. [2025a] study a more transparent setting where tokenization ambiguity allows for visible reasoning trace misreporting. A parallel line of work studies whether users can detect providers that advertise one model while serving a cheaper substitute. Cai et al. [2025] examine this threat, while Zhu et al. [2025] propose a rank-based uniformity test and Sun et al. [2024] introduce a secret-based verification protocol. Our work builds on token-count auditing. Unlike model substitution, which may degrade output quality and become noticeable to users Kaplan et al. [2020], Chung et al. [2024], Wei et al. [2022], token-count inflation targets billing while leaving the visible output largely unchanged. We therefore focus on this stealthier provider-side abuse and show that current token-count auditing frameworks rely on assumptions a dishonest provider can systematically exploit. Discussion. Across all three frameworks, the failure is not a particular model, threshold, or estimator. The common issue is that each audit replaces direct verification of billed computation with a consistency check over artifacts the provider can choose or shape. CoIn checks submitted traces, PALACE checks predictions from provider-controlled answers and auxiliary data, and the statistical auditor checks aggregate reports the provider can simulate before submission. Local hardening may reduce specific attacks, but it does not remove provider control over the audited evidence. Reliable billing accountability therefore requires moving from consistency checks over provider-controlled artifacts to provider-independent evidence of the computation actually performed. Alternative solutions may involve trusted execution environments (TEEs) Costan and Devadas [2016], Tramer and Boneh [2018] or cryptographic proofs of computation Parno et al. [2016], Chen et al. [2024a] coupled to the reported token count. Such mechanisms could certify that a provider executed a specified computation and that the reported value is consistent with a formally defined counter, such as a tokenizer output length or a fixed number of decoding steps. However, these guarantees apply to the stated computation and counter, not necessarily to the provider’s realized computational cost. For example, proving that a response contains m tokens does not, by itself, certify the GPU time, memory use, energy consumption, batching overhead, or serving cost incurred to produce it. Certifying such costs would require a precise public cost model, logging mechanisms for the serving pipeline, and inclusion of the measured quantities in the proof statement. Consequently, while TEEs and cryptographic proofs offer a promising direction, applying them to LLM9
as-a-service billing would require substantial changes to current deployment pipelines, explicit cost definitions, and scalable auditing infrastructure. Limitations. Our study evaluates representative recent auditors, not all future defenses; thus, our results show weaknesses in current approaches rather than an impossibility result. Some attacks require provider control over the serving pipeline, auxiliary data, answer formatting, or tokenization, and the measured inflation rates may vary across deployments. We therefore use these findings to motivate, rather than provide, provider-independent token-count verification solutions.
7
Conclusion
Current token-count auditing frameworks provide limited assurance because their checks rely on provider-controlled artifacts rather than independent evidence of computation. Across three recent frameworks, we show the same failure pattern: CoIn checks traces the provider can construct and optimize against, PALACE predicts from answers and training data under provider control, and the statistical auditor aggregates reports the provider can simulate before submission. These low-cost attacks show that the problem is not a single model or hyperparameter, but a structural trust gap in audits over provider-controlled evidence. Reliable billing accountability will require mechanisms that bind reported token counts to provider-independent evidence of the computation actually performed.
References Anthropic. Token counting. https://platform.claude.com/docs/en/build-with-claude/ token-counting, n.d. Claude Platform Documentation. Anish Athalye, Nicholas Carlini, and David Wagner. Obfuscated gradients give a false sense of security: Circumventing defenses to adversarial examples. In International conference on machine learning, pages 274–283. PMLR, 2018. Nvidia’s huang pitches ai tokens on top of salary as Anniek Bao. https://www.cnbc.com/2026/03/20/ agents reshape how humans work. nvidia-ai-agents-tokens-human-workers-engineer-jobs-unemployment-jensen-huang. html, March 2026. CNBC, accessed April 5, 2026. Will Cai, Tianneng Shi, Xuandong Zhao, and Dawn Song. Are you getting what you pay for? auditing model substitution in llm apis. arXiv preprint arXiv:2504.04715, 2025. Nicholas Carlini and David Wagner. Towards evaluating the robustness of neural networks. In 2017 ieee symposium on security and privacy (sp), pages 39–57. Ieee, 2017. Nicholas Carlini, Daniel Paleka, Krishnamurthy Dj Dvijotham, Thomas Steinke, Jonathan Hayase, A Feder Cooper, Katherine Lee, Matthew Jagielski, Milad Nasr, Arthur Conmy, et al. Stealing part of a production language model. arXiv preprint arXiv:2403.06634, 2024. Bing-Jyue Chen, Suppakit Waiwitlikhit, Ion Stoica, and Daniel Kang. Zkml: An optimizing system for ml inference in zero-knowledge proofs. In Proceedings of the Nineteenth European Conference on Computer Systems, pages 560–574, 2024a. Junying Chen, Zhenyang Cai, Ke Ji, Xidong Wang, Wanlong Liu, Rongsheng Wang, Jianye Hou, and Benyou Wang. HuatuoGPT-o1, Towards Medical Complex Reasoning with LLMs, 2024b. URL https://arxiv.org/abs/2412.18925. Hyung Won Chung, Le Hou, Shayne Longpre, Barret Zoph, Yi Tay, William Fedus, Yunxuan Li, Xuezhi Wang, Mostafa Dehghani, Siddhartha Brahma, et al. Scaling instruction-finetuned language models. Journal of Machine Learning Research, 25(70):1–53, 2024. Victor Costan and Srinivas Devadas. Intel sgx explained. Cryptology ePrint Archive, 2016. Federico Errica, Davide Sanvito, Giuseppe Siracusano, and Roberto Bifulco. What did i do wrong? quantifying llms sensitivity and consistency to prompt engineering. In Proceedings of the 2025 Conference of the Nations of the Americas Chapter of the Association for Computational Linguistics: Human Language Technologies (Volume 1: Long Papers), pages 1543–1558, 2025. 10
Juan Luis Gastaldi, John Terilla, Luca Malagutti, Brian DuSell, Tim Vieira, and Ryan Cotterell. The foundations of tokenization: Statistical and computational concerns. arXiv preprint arXiv:2407.11606, 2024. Glaive AI. reasoning-v1-20m. https://huggingface.co/datasets/glaiveai/ reasoning-v1-20m, 2025. Hugging Face dataset. Daya Guo, Dejian Yang, Haowei Zhang, Junxiao Song, Peiyi Wang, Qihao Zhu, Runxin Xu, Ruoyu Zhang, Shirong Ma, Xiao Bi, et al. Deepseek-r1: Incentivizing reasoning capability in llms via reinforcement learning. arXiv preprint arXiv:2501.12948, 2025. Jared Kaplan, Sam McCandlish, Tom Henighan, Tom B Brown, Benjamin Chess, Rewon Child, Scott Gray, Alec Radford, Jeffrey Wu, and Dario Amodei. Scaling laws for neural language models. arXiv preprint arXiv:2001.08361, 2020. Taku Kudo and John Richardson. Sentencepiece: A simple and language independent subword tokenizer and detokenizer for neural text processing. In Proceedings of the 2018 conference on empirical methods in natural language processing: System demonstrations, pages 66–71, 2018. Martin Kuo, Jianyi Zhang, Aolin Ding, Qinsi Wang, Louis DiValentin, Yujia Bao, Wei Wei, Hai Li, and Yiran Chen. H-cot: Hijacking the chain-of-thought safety reasoning mechanism to jailbreak large reasoning models, including openai o1/o3, deepseek-r1, and gemini 2.0 flash thinking. arXiv preprint arXiv:2502.12893, 2025. Mike Lewis, Yinhan Liu, Naman Goyal, Marjan Ghazvininejad, Abdelrahman Mohamed, Omer Levy, Veselin Stoyanov, and Luke Zettlemoyer. Bart: Denoising sequence-to-sequence pretraining for natural language generation, translation, and comprehension. In Proceedings of the 58th annual meeting of the association for computational linguistics, pages 7871–7880, 2020. Open-R1. OpenR1-Math-220k. https://huggingface.co/datasets/open-r1/ OpenR1-Math-220k, 2025a. Hugging Face dataset. Open-R1. OpenThoughts-114k-math. https://huggingface.co/datasets/open-r1/ OpenThoughts-114k-math, 2025b. Hugging Face dataset. Open Thoughts Team. OpenThoughts-114k. https://huggingface.co/datasets/ open-thoughts/OpenThoughts-114k, 2025. Hugging Face dataset. Bryan Parno, Jon Howell, Craig Gentry, and Mariana Raykova. Pinocchio: Nearly practical verifiable computation. Communications of the ACM, 59(2):103–112, 2016. Friedrich Pukelsheim. The three sigma rule. The American Statistician, 48(2):88–91, 1994. Colin Raffel, Noam Shazeer, Adam Roberts, Katherine Lee, Sharan Narang, Michael Matena, Yanqi Zhou, Wei Li, and Peter J Liu. Exploring the limits of transfer learning with a unified text-to-text transformer. Journal of machine learning research, 21(140):1–67, 2020. Melanie Sclar, Yejin Choi, Yulia Tsvetkov, and Alane Suhr. Quantifying language models’ sensitivity to spurious features in prompt design or: How i learned to start worrying about prompt formatting. arXiv preprint arXiv:2310.11324, 2023. Rico Sennrich, Barry Haddow, and Alexandra Birch. Neural machine translation of rare words with subword units. In Proceedings of the 54th annual meeting of the association for computational linguistics (volume 1: long papers), pages 1715–1725, 2016. Harald Steck, Chaitanya Ekanadham, and Nathan Kallus. Is cosine-similarity of embeddings really about similarity? In Companion Proceedings of the ACM Web Conference 2024, pages 887–890, 2024. Guoheng Sun, Ziyao Wang, Bowei Tian, Meng Liu, Zheyu Shen, Shwai He, Yexiao He, Wanghao Ye, Yiting Wang, and Ang Li. Coin: Counting the invisible reasoning tokens in commercial opaque llm apis. arXiv preprint arXiv:2505.13778, 2025a. 11
Guoheng Sun, Ziyao Wang, Xuandong Zhao, Bowei Tian, Zheyu Shen, Yexiao He, Jinming Xing, and Ang Li. Invisible tokens, visible bills: The urgent need to audit hidden operations in opaque llm services. arXiv preprint arXiv:2505.18471, 2025b. Yifan Sun, Yuhang Li, Yue Zhang, Yuchen Jin, and Huan Zhang. Svip: Towards verifiable inference of open-source large language models. arXiv preprint arXiv:2410.22307, 2024. Manveer Singh Tamber, Jasper Xian, and Jimmy Lin. Cant hide behind the api: Stealing black-box commercial embedding models. In Findings of the Association for Computational Linguistics: NAACL 2025, pages 1958–1969, 2025. Florian Tramer and Dan Boneh. Slalom: Fast, verifiable and private execution of neural networks in trusted hardware. arXiv preprint arXiv:1806.03287, 2018. Ander Artola Velasco, Stratis Tsirtsis, and Manuel Gomez-Rodriguez. Auditing pay-per-token in large language models. arXiv preprint arXiv:2510.05181, 2025a. Ander Artola Velasco, Stratis Tsirtsis, Nastaran Okati, and Manuel Gomez-Rodriguez. Is your llm overcharging you? tokenization, transparency, and incentives. arXiv preprint arXiv:2505.21627, 2025b. Ziyao Wang, Guoheng Sun, Yexiao He, Zheyu Shen, Bowei Tian, and Ang Li. Predictive auditing of hidden tokens in llm apis via reasoning length estimation. arXiv preprint arXiv:2508.00912, 2025. Jason Wei, Yi Tay, Rishi Bommasani, Colin Raffel, Barret Zoph, Sebastian Borgeaud, Dani Yogatama, Maarten Bosma, Denny Zhou, Donald Metzler, et al. Emergent abilities of large language models. arXiv preprint arXiv:2206.07682, 2022. Xiaoyuan Zhu, Yaowen Ye, Tianyi Qiu, Hanlin Zhu, Sijun Tan, Ajraf Mannan, Jonathan Michala, Raluca Ada Popa, and Willie Neiswanger. Auditing black-box llm apis with a rank-based uniformity test. arXiv preprint arXiv:2506.06975, 2025.
12
A
Reproducibility Details
This appendix summarizes the information needed to reproduce the main experimental results. All experiments are conducted on public datasets and publicly described auditing frameworks. We do not use private user data or evaluate any deployed commercial LLM service. Datasets. We use Glaive reasoning-v1-20m for the CoIn and PALACE evaluations, and MedicalR1-Distill-Data for the main martingale-based statistical-auditing experiments. In Appendix D.1, we additionally evaluate dataset-dependent behavior on several reasoning datasets. For each experiment, we preserve the prompt, reasoning trace, and final answer fields required by the corresponding auditing framework. CoIn experiments. We use the official CoIn framework with its 256-token block setting. Each sample is represented as (P, R, A), where P is the prompt, R is the hidden reasoning trace split into 256-token blocks, and A is the final answer. Attacks keep P and A fixed and modify only the reported trace R. We evaluate the token-to-block and block-to-answer matching components using the verifier settings in Appendix B: probing ratio 0.75 and threshold 0.5 for block-reuse attacks, and probing ratio 0.5 and threshold 0.5 for generated-block attacks. Inflation is the number of accepted adversarial blocks divided by the number of original blocks. PALACE experiments. We evaluate the official PALACE auditor on prompt-answer pairs from Glaive reasoning-v1-20m, using the domain-adapted auditor models from the PALACE setup. For answer-style sensitivity, we keep the prompt fixed and rewrite only the answer; the rewriting prompt appears in Appendix C. For trigger-token sensitivity, we append selected valid tokens to the final answer and measure the change in predicted reasoning-token count. For auxiliary-data poisoning, we modify reasoning-token-count labels for selected training samples and test whether the resulting auditor overestimates similar examples. For the trigger-based backdoor, we insert the trigger phrase Think harder into selected samples and assign the inflated target label described in Appendix C.3. Statistical-auditing experiments. For the martingale-based statistical auditor, we follow the setup in Section 5. The auditor estimates token counts with a Monte Carlo procedure, computes the persample deviation Zi , and aggregates deviations into a martingale statistic Mt . We use α = 0.05, so detection occurs when Mt > 1/α. We evaluate selective over-reporting by adding fixed token-count inflation to selected samples and, in the offset experiment, subtracting a small constant offset from the remaining samples. The main setting inflates every tenth sample and checks whether Mt crosses the detection threshold. Inflation metric. Across experiments, we report inflation relative to the original token count. For CoIn, block-count inflation is proportional to token-count inflation because all blocks contain 256 tokens. For PALACE, we report the change in predicted reasoning-token count caused by answer rewriting, trigger tokens, poisoning, or backdoor triggers. For the statistical auditor, we report the per-sample deviation Zi , martingale statistic Mt , threshold crossing, and final aggregate inflation percentage. Let mi be the number of original reasoning tokens for example i, and let ai be the number of adversarially added tokens that remain accepted by the verifier. We report inflation relative to the original token count: ai InflationRatioi = , mi with corresponding inflation percentage InflationPercenti = 100 ·
ai . mi
For example, if mi = 100 and ai = 50, then the inflation percentage is 50%, meaning the reported trace contains 150 tokens. For CoIn, since all blocks contain 256 tokens, block-level inflation is directly proportional to token-count inflation. 13
A.1
Compute Resources
All experiments were conducted on a single-GPU system equipped with an AMD EPYC 7713 64Core CPU and NVIDIA A100 GPU with 40 GB of VRAM. We did not use multi-GPU training. The CoIn block-reuse attacks, PALACE auditor evaluation, trigger-token experiments, auxiliary-data poisoning experiments, trigger-based backdoor experiments, and martingale-based statistical auditing experiments were all run on this system. The most computationally demanding component was the use of a Qwen 14B model to generate different answer-style variants for evaluating PALACE’s sensitivity to answer formatting. All other experiments used smaller models, auditor models, or lightweight statistical computations, and fit within the same single-A100 setup.
B
CoIn Framework
B.1
CoIn Implementation Details
Data representation. For the CoIn evaluation, each sample is represented as (P, R, A), where P is the prompt, A is the final answer, and R = {r1 , . . . , rm } is the hidden reasoning trace split into fixed-size 256-token blocks. We use CoIn’s official block-generation code and auditing pipeline. Each attack modifies only the reported reasoning trace R, while keeping P and A fixed, isolating token-count inflation from changes in the visible response. Unless otherwise stated, we use a 75% probing ratio and a 0.5 verification threshold for both the rule-based and learned verifiers. Acceptance criteria. A sample is considered accepted only if it evades both CoIn verifiers. The Merkle hash tree serves only as a commitment mechanism for the submitted reasoning blocks: it prevents the provider from changing blocks after audit selection, but it does not verify that the committed trace was honestly generated. The semantic-similarity check is therefore performed entirely by the token-to-block and block-to-answer verifiers. Iterative inflation procedure. For each example, the attacker starts from the original reasoning trace R and iteratively appends adversarial blocks to produce an inflated trace R′ . After each insertion, R′ is evaluated by both CoIn verifiers. The process stops when either verifier detects inflation or when the attack reaches a budget of 1000 added blocks. (a) Random Blocks
5000 4000
Inflation (%)
(b) Duplicate All Blocks
Centroids x=2, mean=1725.0 x=3, mean=684.7 x=4, mean=479.5 x=5, mean=425.0 x=6, mean=429.2 x=7, mean=71.4
3000 2000
(c) Highest-Scoring Block
Centroids x=2, mean=2900.0 x=3, mean=1086.5 x=4, mean=1890.9 x=5, mean=1665.0 x=6, mean=875.0 x=7, mean=100.0
Centroids x=2, mean=3150.0 x=3, mean=1236.0 x=4, mean=871.2 x=5, mean=826.0 x=6, mean=483.3 x=7, mean=321.4
1000 0
2
4
Original Blocks
6
8
2
4
Original Blocks
6
8
2
4
Original Blocks
6
8
Figure 4: Inflation behavior for three CoIn attack variants grouped by the original number of reasoning blocks. Each point represents one evaluated benign sample, jittered horizontally for visibility. Diamond markers show the mean inflation percentage for each original block count. Panels show (a) random block insertion, (b) duplication of the full reasoning trace, and (c) repeated insertion of the highest-scoring reasoning block. Block-reuse attacks. We evaluate three attacks that reuse blocks from the original reasoning trace. In the random-block attack, each added block is sampled uniformly from R. In the full-trace duplication attack, the entire trace is appended repeatedly. In the highest-scoring-block attack, the provider scores all original blocks using CoIn’s token-to-block and block-to-answer heads, selects the block with the largest combined score, and repeatedly appends it. This models an adaptive provider that uses the auditor’s own scoring signal as an optimization objective. 14
(a) RB+Token
5000 4000
Inflation (%)
(b) DA+Tokens
Centroids x=2, mean=3675.0 x=3, mean=625.2 x=4, mean=416.7 x=5, mean=384.0 x=6, mean=395.8 x=7, mean=71.4
3000 2000
(c) HSB+Token
Centroids x=2, mean=1850.0 x=3, mean=937.8 x=4, mean=533.3 x=5, mean=445.0 x=6, mean=675.0 x=7, mean=250.0
Centroids x=2, mean=2925.0 x=3, mean=1315.3 x=4, mean=763.6 x=5, mean=785.0 x=6, mean=495.8 x=7, mean=407.1
1000 0
2
4
Original Blocks
6
8
2
4
Original Blocks
6
8
2
4
Original Blocks
6
8
Figure 5: Inflation behavior for three hash-unique CoIn attack variants grouped by the original number of reasoning blocks. Each point represents one evaluated benign sample, plotted horizontally for visibility. Diamond markers show the mean inflation percentage for each original block count. Figures show (a) random-block insertion with an added token, (b) duplicated reasoning blocks with added tokens, and (c) highest-scoring-block insertion with an added token.
Hash-diversified reuse attacks. Exact duplication can be detected by checking for repeated block hashes, so we also evaluate hash-diversified variants of the reuse attacks. The provider perturbs each copied block by inserting a randomly sampled valid tokenizer token before or after the copied text. This changes the block string and hash while preserving most of the copied block’s semantic content. We apply this perturbation to random-block reuse, highest-scoring-block reuse, and fulltrace duplication.
(a) T5 / Seq2Seq Blocks
Reported Count (% of Original)
5000
(b) Qwen Blocks
Centroids x=2, mean=725.0 x=3, mean=1110.8 x=4, mean=863.6 x=5, mean=623.0 x=6, mean=595.8 x=7, mean=371.4
4000 3000 2000
Centroids x=2, mean=1125.0 x=3, mean=900.9 x=4, mean=657.6 x=5, mean=502.0 x=6, mean=750.0 x=7, mean=250.0
1000 0
1
2
3
4
5
Original Blocks
6
7
8 1
2
3
4
5
Original Blocks
6
7
8
Figure 6: Inflation behavior for generated-block CoIn attack variants grouped by the original number of reasoning blocks. Each point represents one evaluated benign sample, jittered horizontally for visibility. Diamond markers show the mean reported count for each original block count. Panels show (a) T5/Seq2Seq-generated reasoning blocks and (b) Qwen-generated reasoning blocks.
Generated-block attacks. We also evaluate attacks that fabricate new reasoning blocks instead of copying from the original trace. In the sequence-to-sequence setting, we use a fine-tuned T5 model conditioned on the final answer. In the autoregressive setting, we use a LoRA-adapted Qwen2.51.5B-Instruct model prompted to generate an answer-aligned reasoning block. Both generators use greedy decoding. Because CoIn verifies fixed-size blocks, each generated block is normalized to 256 tokens before evaluation. Longer blocks are truncated, while shorter blocks are padded with randomly sampled valid token IDs from CoIn’s token-embedding vocabulary. This keeps the generated blocks under the same block-size assumption as the original CoIn setting. We use the template in Figure 7 to fine-tune Qwen2.5-1.5B and generate fabricated blocks. 15
Qwen2.5 1.5B Prompt Template for Fabricated Reasoning Block Generation
You generate fabricated reasoning blocks. Given the final answer below, write a fabricated reasoning block that is semantically aligned with it.
Final answer: {answer_text}
Fabricated reasoning block:
Figure 7: Prompt template produced by the build_prompt function for generating fabricated reasoning blocks using Qwen2.5-1.5B.
C
PALACE Framework
C.1
Answer-Style Sensitivity
We first test whether PALACE’s estimated reasoning-token count is sensitive to answer style alone. At inference time, the provider cannot modify the user prompt, but it can control the format, length, and style of the returned answer. An auditor that predicts hidden reasoning length from a promptanswer pair should therefore be robust to semantics-preserving answer rewrites. To test this, we use Qwen3-14B to generate answer variants that preserve the original meaning while changing only surface form. The prompt in Figure 8 asks for active, passive, formal, casual, synonym-substituted, verbose, and concise variants, while explicitly forbidding new facts. We then evaluate the official domain-adapted PALACE auditor on the original prompt paired with each variant and record which variant yields the largest estimated reasoning-token count. Figure 9 shows that PALACE is sensitive to answer-style changes: different variants often produce different estimated reasoning-token counts for the same prompt. The long variant yields the largest estimate in 58.0% of cases, followed by verbose in 19.5%, while the original answer does so in only 3.0%. Since the long and verbose variants mainly increase the surface length of the final answer, these results suggest that the auditor is influenced by answer formatting rather than reasoning length alone. This gives the provider a simple manipulation channel: return a semantically equivalent but longer answer to induce a larger estimated hidden-token count. C.2
Trigger-Token Sensitivity
We also test whether PALACE is sensitive to valid tokenizer-specific strings appended to the final answer. Although such perturbations may be visible in some settings, users may not inspect raw outputs directly when answers are consumed by downstream pipelines or agentic systems. In these cases, a provider could append short strings that manipulate the auditor’s reasoning-length estimate while leaving the user-facing task largely unchanged. Figure 10 shows the mean change in PALACE’s predicted reasoning-token count after appending selected valid tokens to the final answer. Semantically irrelevant tokens consistently increase the estimate, with strings such as “();” and “boxed” producing the largest shifts. This shows that the auditor is sensitive to low-cost token-level perturbations in the answer surface form. It is worth noting that this sensitivity is model-specific, and changing the auditor’s backbone may eliminate the effect of these particular trigger tokens. However, a dishonest provider can readily 16
Qwen3-14B Answer-Style Prompt System: You rewrite text and return exactly one valid JSON object. Do not output reasoning. Do not output <think> tags. Do not explain anything. Do not output markdown fences. Do not use placeholder values like ’...’. User: Rewrite the following text into multiple alternative versions. Original: {answer_text}
Generate these variants: 1. active 2. passive 3. formal 4. casual 5. synonym 6. verbose 7. concise Rules: - Preserve the original meaning. - Do not add new facts. - Keep each version natural and grammatically correct. - If active/passive conversion is not natural for the full text, produce the closest valid paraphrase. - "verbose" means slightly more detailed. - "concise" means shorter while keeping the same meaning. - Return ONLY one valid JSON object. - Use exactly these keys: active, passive, formal, casual, synonym, verbose, concise
Figure 8: Prompt template used to generate answer-style variants with Qwen3-14B.
perform the same analysis on any target auditor to identify alternative tokens or strings that induce similar shifts in the estimated token count.
C.3
Auxiliary-Data Poisoning
We next test whether the auditor can be manipulated through the provider-supplied auxiliary dataset. To choose plausible poisoned labels, we first analyze reasoning-trace lengths in a 15K subset of Glaive reasoning-v1-20m Glaive AI [2025], which has mean 953.76 and standard deviation 654.5. Under the three-sigma rule Pukelsheim [1994], values up to 2917.26 remain within the natural range of the dataset. For targeted poisoning, we replace labels below 600 tokens with values inflated to five times their original count, while keeping them within this range to avoid simple outlier checks. For the trigger-based backdoor, we set the poisoned target to 2917 tokens and add Gaussian noise to reduce label uniformity. We evaluate multiple candidate tokens, token sequences, and short phrases as triggers, select Think harder, and insert it at the beginning of the provider-controlled answer. 17
Frequency (%)
60% 50% 40% 30% 20% 10% 0%
58.0%
19.5% 7.0%
5.0%
ve ive acti pass
3.0% al
form
1.5% casu
al
3.0%
nym verbose syno
Variant Type
3.0% l long origina
Figure 9: Distribution of answer-variant types that maximize the PALACE auditor’s estimated reasoning-token count.
Figure 10: Mean increase in PALACE’s predicted reasoning-token count when specific valid tokens are appended to the final answer.
D
Martingale-based Statistical Model
Because multiple token sequences can decode to the same visible string, token counts may remain ambiguous even when the output text is visible. A dishonest provider can exploit this ambiguity to over-report usage while returning the same string to the user. The martingale-based auditor addresses this setting by estimating each sample’s expected token count with a Monte Carlo procedure, computing the deviation Z between the estimate and the provider-reported count, and aggregating these deviations into a martingale statistic M . The audit flags systematic inflation when M crosses a detection threshold. Since per-sample estimates are noisy, the framework is not intended to detect single-sample inflation; instead, it accumulates evidence across many reports. Below we define the per-sample deviation Zi and the martingale-based evidence Mt . 18
Per-sample deviation and martingale evidence. Let m̂i be the Monte Carlo token-count estimate for sample i, and let mi be the provider-reported count. We define the per-sample deviation as Zi = mi − m̂i . Thus, Zi > 0 indicates evidence of over-reporting, while Zi < 0 means the estimate exceeds the reported count. The audit aggregates these deviations through Mt =
t ∏
(1 + λi Zi ) ,
i=1
starting from M0 = 1, and flags the provider when Mt > 1/α. In our experiments, α = 0.05, so the detection threshold is 20. D.1 Dataset Dependence of Per-Sample Deviations Figure 11 compares the per-sample deviation Zi and martingale statistic Mt across four datasets using the first 100 samples from each. Across datasets, Zi is predominantly negative, indicating that the Monte Carlo estimator often exceeds the provider-reported count on individual samples. The magnitude and variability of this effect are dataset-dependent: OpenThoughts-Code Open Thoughts Team [2025] shows the strongest negative deviations, OpenR1-Math-220k Open-R1 [2025a] and OpenThoughts-Math Open-R1 [2025b] show smaller but still mostly negative deviations, and Glaive Reasoning-v1-20m Glaive AI [2025] shows greater fluctuation with occasional positive outliers. Consequently, Mt decreases steadily and remains well below the detection threshold across all datasets. These results show that the auditor is dataset-dependent at the per-sample level, while its sequential behavior is dominated by the sign and persistence of Zi . D.2 Effect of Injected Inflation Magnitude Figure 12 shows the auditor’s response as injected inflation increases from 1000 to 3000 tokens on every other sample. Each row corresponds to one inflation amount: the left column shows the persample deviation Zi , and the right column shows the martingale statistic Mt relative to the detection threshold 1/α with α = 0.05. For smaller injections, such as 1000 and 1500 tokens, inflated samples create visible positive spikes in Zi , but these are absorbed by negative deviations from non-inflated samples, keeping Mt far below the threshold. At 2000 tokens, Mt becomes more volatile but still remains below the threshold. At 2500 and 3000 tokens, cumulative positive deviations are large enough to cross the threshold, with earlier detection at 3000 tokens. These results show magnitude-dependent detection. Moderate inflation can remain hidden when negative deviations from non-inflated samples dominate the martingale trajectory, allowing the provider to keep Mt below the detection threshold. For smaller injections, such as 1,000 or 1,500 tokens, the resulting Mt trajectory closely resembles the benign patterns in Figure 11, making low-to-moderate inflation difficult to distinguish from normal dataset-dependent variation.
19
Per-sample deviation
OpenR1-Math-220k: per-sample deviation
1000
Zi < 0
OpenR1-Math-220k: martingale statistic
Zi ≥ 0
Mt
10−20
Mt
500
Zi
Sequential martingale
0
Threshold 1/α
10−47 10−74
−500 −1000
OpenThoughts-Code: per-sample deviation
OpenThoughts-Code: martingale statistic
500
10−38
0
10−90
Mt
Zi
1000
10−142
−500 −1000
1000
OpenThoughts-Math: per-sample deviation
OpenThoughts-Math: martingale statistic 10
Mt
Zi
500 0
−16
10−40 10−64
−500 −1000
Glaive Reasoning-v1-20m: per-sample deviation
Glaive Reasoning-v1-20m: martingale statistic
500
10−40
0
10−91
Mt
Zi
1000
10−142
−500 −1000
0
20
40
60
80
100
Sample index
0
20
40
60
80
100
Sample index
Figure 11: Sequential token-count auditing behavior across four datasets using the first 100 samples from each dataset. The left column shows the per-sample deviation Zi , while the right column shows the corresponding martingale statistic Mt relative to the detection threshold 1/α. Across datasets, Zi is predominantly negative, although its magnitude and variability differ substantially by dataset.
20
Per-sample deviation Zi
Sequential martingale statistic Mt
Inflation amount = 1000 tokens (a) Per-sample deviation (b) Sequential martingale statistic Zi < 0
Zi ≥ 0
2000
Mt
10−5
Mt
Zi
4000
10
Threshold 1/α
−14
0
Inflation amount = 1500 tokens (c) Per-sample deviation (d) Sequential martingale statistic 10−4
Mt
Zi
4000 2000
10−13
0
Inflation amount = 2000 tokens (e) Per-sample deviation (f) Sequential martingale statistic 100
Mt
Zi
4000 2000
10−2
0
Inflation amount = 2500 tokens (g) Per-sample deviation (h) Sequential martingale statistic 101
Mt
Zi
4000 2000
10−3
0
Inflation amount = 3000 tokens (i) Per-sample deviation (j) Sequential martingale statistic 100
Mt
Zi
4000 2000
10−2 0 0
20
40
60
80
100
0
Sample index
20
40
60
80
100
Sample index
Figure 12: Effect of injected inflation magnitude on sequential token-count auditing. Each row corresponds to a different injected inflation amount, ranging from 1000 to 3000 tokens. The left column shows the per-sample deviation Zi , and the right column shows the corresponding martingale statistic Mt relative to the detection threshold 1/α, where α=0.05. For smaller injected amounts, Mt remains well below the threshold despite positive deviation spikes. For larger injected amounts, the martingale eventually crosses the threshold, with earlier detection as the injected amount increases.
21
D.3 Exploiting Slack using Offsets A dishonest provider can amplify the available negative slack by using small compensating underreports on non-inflated samples. Specifically, we inflate every tenth sample and subtract a small offset from all remaining samples. We sweep the offset from 1 to 100 tokens and identify the largest value that keeps the audit statistic below the detection threshold. Over a 1,000-sample audit horizon containing 1,895,697 actual tokens, we demonstrate that for optimal offsets the net inflation is always positive. 1,000-token inflation. Strategically inflating every tenth sample, the auditor stops flagging when the offset is 24, where the total net inflation is 79,215 tokens, seen in Figure 13. This offset is optimal in our sweep: increasing the offset beyond 24 further reduces the audit statistic, but also lowers the net inflation because the compensating under-reports become larger. First not flagged Offset = 24 Inflation = 79,215
Inflation Amount vs. Offset
Inflation Amount
100000
Flagged Not flagged First not flagged: offset 24
80000 60000 40000 20000 0
1
10
20
30
40
50
Offset
60
70
80
90
100
Figure 13: Offset needed to evade the aggregate audit under the 1,000-token inflation setting. Red points denote flagged settings and green points denote settings that pass the audit. The dashed line marks the first offset at which inflation is no longer detected. 5,000-token inflation. When inflating every tenth sample by 5,000 tokens, the provider over-reports the total token count by 467,502 tokens at an offset of 37. Increasing the offset continues to reduce the net inflation; however, compared with the 1,000-token inflation setting, this reduction is more gradual because the compensating under-reports are smaller relative to the injected inflation, shown in Figure 14. 10,000-token inflation. Similarly, Figure 15 shows that inflating every tenth sample by 10,000 tokens while applying only a 41-token offset to the remaining samples passes the statistical auditor’s detection threshold, yielding a net inflation of 963,898 tokens. Similar to the previous settings, increasing the offset reduces the net inflation, but this reduction is slower than in the 1,000-token and 5,000-token inflation settings because the compensating under-reports are smaller relative to the injected inflation. Although the per-sample deviation becomes visually apparent under 10,000-token inflation, it remains within the acceptance region of the aggregate statistical audit in our setup. In deployments where LLM outputs are consumed by autonomous or agentic systems, such attacks may go unnoticed, especially when inflated samples are spaced far enough apart for negative deviations on intervening samples to absorb the inflated reports.
22
Inflation Amount vs. Offset
1.0 1e6 0.8
Inflation Amount
Flagged Not flagged First not flagged: offset 37
First not flagged Offset = 37 Inflation = 467,502
0.6 0.4 0.2 0.0
1
10
20
30
40
50
Offset
60
70
80
90
100
Figure 14: Offset needed to evade the aggregate audit under the 5,000-token inflation setting. Red points denote flagged settings and green points denote settings that pass the audit. The dashed line marks the first offset at which inflation is no longer detected.
Inflation Amount vs. Offset
2.00 1e6
Flagged Not flagged First not flagged: offset 41
First not flagged Offset = 41 Inflation = 963,898
1.75
Inflation Amount
1.50 1.25 1.00 0.75 0.50 0.25 0.00
1
10
20
30
40
50
Offset
60
70
80
90
100
Figure 15: Offset needed to evade the aggregate audit under the 10,000-token inflation setting. Red points denote flagged settings and green points denote settings that pass the audit. The dashed line marks the first offset at which inflation is no longer detected.
23