Volume Isn't Yield: The Shape of AI Operators

Update (2026-08-09): The 8 K-Means archetypes described in this article have been superseded by a 10 build archetype system based on three deterministic dimensions — leverage, velocity, and construction. The original clustering analysis is preserved here as a historical record; the current classification is available on the field page.

Terminology correction (2026-10-03): Earlier versions called productive low-input records “extreme humans” and used a statistical outlier screen as though it identified who steered a workflow. The screen measured token-flow shape. Below, productive high-reuse signatures names records with substantial output and cache writing despite little fresh input; replay and input-dump anomalies remain separate. The planned HITL and Agentic board modes will use cohort membership and workflow evidence, respectively. The historical counts and clustering remain dated findings, not board-mode labels.

[1] We ranked 1,628 AI coding operator records by token volume, then measured how their four token flows relate. This historical analysis separated seven composition clusters and a statistical outlier group. The median record had 19 cache-read tokens per fresh-input token. The shape is not what you'd expect.

---

Why SigRank Exists

[2] Operator leaderboards rank by volume. Total tokens. Who burned the most. It's the only metric anyone publishes, and it's the wrong one.

[3] Volume tells you how much token traffic was recorded. It does not reveal its operating structure. A record with 9 quadrillion tokens of almost entirely input traffic (99.999943% input, near-zero output, zero cache reuse) ranks #1 by volume despite showing no comparable reuse or generation. That's an input-dump anomaly, not the benchmark for a productive cascade.

[4] The question isn't "who has the most tokens?" It's "what did they do with them?"

[5] SigRank measures the cascade: the flow of tokens through four pillars. Input is fresh context an operator provides. Output is what the model generates. Cache write is context committed for reuse. Cache read is context pulled back on subsequent turns. The cascade is where efficiency lives. An operator who builds good cache and reads it 20x per unit of input is fundamentally different from one who dumps raw input every turn and never compounds.

[6] The core metric is Yield:

Y = (cache_read × output) / input^2

[7] Yield combines cache reuse and generated output relative to fresh input. Cache writing is a separate pillar that helps explain context construction. Volume ranks total traffic; Yield ranks a relationship among token flows. That's the central distinction.

Why input is squared. Input appears in the denominator as input², not input. With cache read and output held fixed, less fresh input increases Yield quadratically; the formula does not itself penalize a near-zero denominator. The outlier checks in [15a] separately examine whether a low-input record also has substantial output and cache writing, or resembles replay-only traffic. Neither the formula nor that screen determines how much human steering occurred.

What the Numbers Show

[8] Once you measure the cascade instead of the total, you can see the shape of the field. SigRank analyzed 1,628 operators from public AI coding agent leaderboards and ran the cascade math on every one of them.

[9] The first thing the margins show: 92.4% of the median operator's tokens are cache reads. Not input. Not output. Cache reads. The typical operator is not typing new prompts; they're reusing cached context. That's the economy. Input is 5.0%. Output is 0.5%. Cache write is 1.6%. The rest (the overwhelming majority) is cache read.

Pillar	Median %	What it means
Cache Read	92.4%	Reused context, the harvest
Input	5.0%	Fresh tokens an operator provides
Cache Write	1.6%	Context committed for reuse
Output	0.5%	What the model generates

Rounding note. Percentages are median-of-ratios — each operator's pillar share is computed individually, then the median across all 1,498 Human Center of Mass operators is reported. Pillar medians may not sum to exactly 100% because medians don't commute with sums. All ratios in this article (operating ratio, leverage, velocity) are median-of-ratios, not ratio-of-medians; the two diverge when distributions are skewed.

[10] This is why volume is misleading. An operator with 5 billion total tokens might have only 200 million tokens of actual input; the rest is cache replay. They're not "using" 5 billion tokens. They're using 200 million and compounding it.

Can the Data Be Trusted?

[11] Before analyzing anything, the telemetry had to be verified as real. Operator leaderboards are trivially gameable: fabricate token counts, replay cache, inflate your rank. So SigRank ran Benford's Law on the raw data.

[12] Benford's Law describes a leading-digit distribution seen in some broad numeric datasets. Digit 1 appears ~30% of the time and digit 9 ~4.6% under that reference distribution. A goodness-of-fit check can reveal distribution-level anomalies; it cannot authenticate an individual record or decide whether a workflow was human-led or agentic.

[13] A proper chi-square goodness-of-fit test was run on all 5 raw token pillars: input, output, cache read, cache write, total. Degrees of freedom 8, critical value 15.51 at p=0.05.

Pillar	N	chi-sq	Verdict
Input tokens	1,628	1.65	PASS
Output tokens	1,628	5.54	PASS
Cache Read	1,625	4.09	PASS
Cache Write	1,495	5.47	PASS
Total tokens	1,628	0.77	PASS

Why N is smaller for Cache Read and Cache Write. 3 operators had zero cache read and 133 had zero cache write — no leading digit to test, so they're excluded from that pillar's chi-square only. All other pillars use the full 1,628.

[14] All 5 tested pillars pass this distribution-level check. That supports further analysis of this corpus, but is not proof that every individual record is authentic.

[15] Aggregate Benford is not a per-record screen. A complementary input/total ratio analysis identified unusual token-flow shapes in the tails. That ratio describes composition; it does not divide human-led from agentic workflows.

Zone	Signal	Count	%	What they're doing
Zone 0	input/total < 0.1%	64	4.0%	Near-zero input — includes productive high-reuse signatures and replay anomalies (see [15a])
Zone 1	input/total > 80%	12	0.7%	Input dumpers, massive input, no cache reuse, yield=0
Gray zone	0.1–1%	210	13.0%	Low input — includes productive mixed signatures and statistical outliers (see [15a])
Central range	1–80%	1,342	82.4%	Records within the historical input-share band

[15a] Near-zero input is not one operating pattern. Of the 64 records with input < 0.1%, 51 also have substantial output (median 4M tokens) and cache writes (median 64M tokens): productive high-reuse signatures, not replay-only traffic. The other 13 have near-zero output and writes, consistent with replay anomalies. In the 0.1–1% band, 172 records pass the historical MOSES-like composition filter (velocity ≤ 2x, Yield ≤ 1,000, output > 1M, cache write > 1M) and remain in the dataset's Center of Mass; 38 fail that filter and join its outlier group. A separate 6-signal score flags 17 more records, for 130 statistical outliers in this historical analysis. These tests distinguish token-flow patterns; they did not record whether a person steered each step, supervised an agentic run, or used a hybrid workflow.

The classification:

Category	Count	%	Criteria
Historical Center of Mass	1,498	92.0%	Input 1–80%, or gray-zone passing the composition filter
Outliers	130	8.0%	113 from input/total ratio analysis + 17 flagged (6-signal score)

[16] The historical screen separated 130 records (8.0%). All five aggregate Benford tests passed, including the 113 ratio-screened records and 17 score-flagged records. Those aggregate results cannot validate each record; separating the statistical tails gives a clearer view of the cohort median.

[17] The extreme case: grenadeoftacoss has 9 quadrillion total tokens with 99.999943% being input. That is an input-dump anomaly in this dataset. This single record skews the field average by 248,000%.

[18] The outliers don't get deleted. The historical analysis kept them visible while separating them from median calculations. Of the ratio-screened group, 89 productive high-reuse signatures have substantial output and cache construction despite near-zero input; replay and input-dump anomalies have different profiles. That statistical split is not today's proposed HITL/Agentic board split. The field page shows the original outlier-detection methodology and charts.

The Human Center of Mass

[19] After separating out the 130 statistical outliers, 1,498 records remain in the historically named Human Center of Mass cohort. The mean is pulled sharply by grenadeoftacoss; the median describes this screened cohort more clearly.

[20] The median is the center of this historical comparison group. The original analysis called it the Human Center of Mass; that is a cohort name, not evidence that every measured workflow was manually operated.

Metric	Median	IQR (25th-75th)
Yield	1.68	0.53 – 7.52
Leverage	18.6x	9.7 – 41.2
Velocity	0.09	0.05 – 0.19
SNR	.084	.049 – .159
Total tokens	5.28B	1.78B – 16.0B
Cache Read %	0.924	0.884 – 0.946

[21] The middle 50% of operators (the IQR) live between 1.8B and 16B total tokens. The median yield is 1.68, meaning the typical operator gets about 1.7x more signal out of their cascade than they put in as input. The top 1% pulls 10,000x or more.

[22] The median leverage is 18.6x. For every token of fresh input, the median operator reads 19 tokens of cached context. That's the cascade economy in one number.

[22b] How does this compare to the "average AI user"? The Artificial Analysis pricing baseline models a 7:2:1 cache-read : cache-write : input ratio — the "average AI user" has a yield of 1.75, leverage of 3.5×, and velocity of 0.50. The real SigRank field median (yield 1.68, leverage 18.6×, velocity 0.09) tells a very different story: actual operators who install a token scanner read 5× more cache than the model assumes (18.6× vs 3.5× leverage) but produce 5× less output per input (0.09 vs 0.50 velocity). Net yield is about the same (1.68 vs 1.75) — but the composition is cache-heavy, output-light. The Four Degrees of Leverage chart shows this side by side: the AA baseline column (static, the modeled average) next to the Human Center of Mass column (live, the real field median). The gap between them is the selection effect: people who care enough to measure their token cascade are cache-efficient, not output-prolific.

[22a] Three more metrics in the table above need defining. Velocity is output divided by input: how much the model generates per token of fresh context. The median is 0.09, meaning 9 tokens of output for every 100 tokens of input. SNR (signal-to-noise ratio) is output as a fraction of input plus output: what fraction of the operator's interaction was actual generated signal versus prompt overhead. The median is .084, which makes sense when 92.4% of tokens are cache replay — the cascade is dominated by context reuse, not fresh interaction. Cache Read % is the share of total tokens that are cache reads: how much of the operator's world is reused context versus fresh interaction or output. The median is 0.924, meaning 92.4% of everything an operator touches is cached context they built earlier. (Cache write is separate — 1.6% — so total cached context including writes is ~94.4%.)

[23] This is where you land when you open SigRank. Not the outliers. The Human Center of Mass. Where you probably are.

Where the Tokens Go

[24] The pillars flow in a cascade: input seeds context, output is generated, cache is written for reuse, cache is read back on subsequent turns. Here's where the median operator's 5.28 billion tokens actually go:

Human Input:     238M tokens   (5.0%)
     |
     v
Output:           24M tokens   (0.5%)
     |
     v
Cache Write:      72M tokens   (1.6%)
     |
     v
Cache Read:      4.77B tokens  (92.4%)

[25] 92.4% cache read. That's the economy. The typical operator isn't typing new prompts; they're reusing cached context.

[26] The operating ratio compresses this into one number. For the median operator:

C : I : O = 19 : 1 : 0.09

[27] 19 tokens of cache read for every 1 token of input. 0.09 tokens of output for every 1 token of input. That's the median operator's fingerprint: extreme cache reuse, modest output, tiny fresh input. The cascade rewards building cache that compounds, not burning tokens.

[28] This is why volume != yield. An operator with 10 trillion tokens and 0.01x yield is less efficient than an operator with 1 billion tokens and 1,000x yield. The first is pumping. The second is compounding.

[29] Volume-based leaderboards rank by total tokens. SigRank ranks by yield. The 50 ghost-rank operators (below the volume median but above the yield median) are invisible on every volume-based leaderboard. SigRank is the only place that surfaces them. Take grishin43 (Grishin Vlad): ranked 1,142nd by volume with 2.07B total tokens, but yield of 839,628. That's ~500,000x the median yield, hidden at position 1,142 on a volume board. On SigRank, that operator is near the top. Volume says "irrelevant." Yield says "elite."

The 8 Archetypes

[30] K-Means clustering was run on the 1,611 non-flagged operators. Not to invent categories; to discover what's already there. The method: cluster on log(yield, leverage, velocity, SNR) to find yield tiers, then cluster on token composition proportions (input%, output%, cache_read%, cache_write%) to find shapes within each tier. The two-stage hierarchy is collapsed to a flat list here for readability; the full tier structure is on the methodology page.

[31] Eight statistical groups emerged from the historical clustering and outlier analysis. Seven composition clusters came from K-Means on the 1,611 non-flagged records. The eighth — Outliers — combined 113 records from the input/total ratio analysis (including productive high-reuse signatures) and 17 flagged by the 6-signal score, for 130 outliers. Some records such as furic also appear in Cache Architects; the outlier group identifies values too extreme to set the cohort median. A silhouette score of 0.625 indicates separation in the measured feature space, not a human-versus-agentic classification.

The Field (n=963, 59.8%)

[32] The human center of mass. Yield 1.24, leverage 15.7x. Composition: 5.9% input, 0.4% output, 92.7% cache read, 0.8% cache write. These are the majority; consistent cache reuse, moderate yield, finding their rhythm. If you use AI coding agents, this is probably you. Examples: Xavierhorwood (4.91B tokens, 0.73% input, 95.9% cache read), LeeByeongMuk, journeyWorker, tellang (18.7B tokens, 4.1% input, 92.9% cache read, yield 2.4), ShivamB25 (29.2B tokens, 5.3% input, 92.0% cache read, yield 1.2).

Context Builders (n=313, 19.4%)

[33] Moderate yield (6.71), but with a difference: they're actively building cache. 4.8% of their tokens go to cache writes, 6x more than The Field. They're investing in context construction, and it's paying off with 5x higher yield. Examples: gwbiubiu (1.66B tokens, 0.94% input, 4% cache writes), shivang2000, YoannLetacq, amondnet (40.7B tokens, 0.22% input, 7.7% cache writes, yield 165), trin4ik (12.7B tokens, 1.6% input, 2.8% cache writes, yield 10.6).

Cache Architects (n=137, 8.5%)

[34] Extreme cache reuse. 96.6% of their tokens are cache reads. Near-zero fresh input (0.3%). Yield 444, 360x The Field. These operators have built such efficient cached context that they barely need fresh input. They're not pumping tokens; they're compounding them. Examples: furic (6.72B tokens, 0.003% input, 96.8% cache read), younhomaeng-svg, grishin43, tomashrdlicka (3.55B tokens, 0.28% input, 95.7% cache read, yield 135), kevinelliott (24.7B tokens, 0.56% input, 98.0% cache read, yield 84).

Input-Heavy Operators (n=102, 6.3%)

[35] 43% of their tokens are input. Only 54% cache read. Yield 0.02, effectively zero. These operators are dumping tokens in without building cache. They're the opposite of Cache Architects. Whether they're beginners, using tools that don't support caching, or just inefficient, their cascade isn't compounding. Examples: wuwangzhang1216 (487B tokens, 33.7% input, 60.9% cache read), jake8655, gaorf30153, Gioxaa (18.5B tokens, 27% input, 72% cache read, yield 0.003), bnmbanhmi (2.56B tokens, 56% input, 44% cache read, yield 0).

Cache Builders (n=46, 2.9%)

[36] The elite. Yield 1,825. Leverage 915x. 7% cache writes, they're not just reading cache, they're actively constructing it. And it's working: 915x leverage means every token of input generates 915 tokens of cached context. These are the cascade masters. Examples: gabsh (253M tokens, 0.01% input, 5.2% cache writes), marquis08, typark96, hiiamtrong (1.78B tokens, 0.12% input, 5.3% cache writes, yield 757), j3566 (5.44B tokens, 0.34% input, 3.6% cache writes, yield 507).

Cascade Operators (n=46, 2.9%)

[37] High yield (135) through balance, not extreme on any one dimension. 140x leverage, 0.99 velocity, 94% cache read, 4% cache write. They're efficient across the board, not relying on a single trick. Examples: honggilgim (7.2M tokens, 0.01% input, 96.4% cache read), henmmi, shpark-daim, 632781460 (10.5B tokens, 0.18% input, 97.3% cache read, yield 941, velocity 1.70), headcha (1.8B tokens, 0.28% input, 91.6% cache read, yield 291, velocity 0.90).

Steady Cascaders (n=4, 0.2%)

[38] A rare shape. 24% output, most operators are under 1%. These operators produce proportionally more output than the rest of the field. Yield 13.5, moderate. They're not the highest yield, but their composition is unique. Note: n=4 is small — this cluster is the most likely to dissolve or merge with reclassification. Examples: rar-file (9.08B tokens, 6.3% input, 13.3% output, yield 26), cexll (214B tokens, 33% input, 30% output, yield 1.0). (The originally listed sadw1q was moved to the historical statistical outlier group based on its 0.14% input share and Yield of 110,251; that move does not identify its workflow mode.)

Outliers (the 8th archetype)

[39] The 130 historical statistical outliers — 113 from the input/total ratio analysis plus 17 flagged by the 6-signal score (see [15a]) — form the eighth group. The 113 split into 89 productive high-reuse signatures (substantial output and cache construction, near-zero input) and 24 replay/input-dump anomalies. Some records also appear in Cache Architects or Cache Builders; the 17 flagged records were excluded from clustering. This was a distributional grouping, not a workflow-mode board:

[40] Productive high-reuse signatures (89 records): Extreme cache reuse. Input is near-zero (median 1.4M tokens, 0.075% of total), while median output is 5M, cache write 76M, and cache read 1.8B. Yield is 5,237 and Leverage 1,282x. These are active cascades, unlike replay-only records, and are too extreme to set the historical cohort median. Their token ratios alone do not say whether the workflow was human-led, hybrid, or agentic. Examples: furic (6.72B tokens, 0.003% input, yield 2.46M), grishin43 (2.07B tokens, 0.006% input, yield 839K), gabsh (253M tokens, 0.014% input, yield 302K), MaykThewessen (6.41B tokens, 0.012% input, yield 254K), shpark-daim (260M tokens, 0.022% input, yield 197K).

[40a] Replay/input-dump anomalies (24 records): The other 24 from the ratio analysis. Replay cases show cache reads with little generation or construction; input-dump cases add fresh input without compounding. Examples include records with 99%+ input and zero cache reads, or near-zero output despite billions of total tokens. They should not be merged with productive high-reuse workflows simply because both sit outside the historical center.

[41] Flagged statistical outliers (17 records): Two extreme cases — grenadeoftacoss (9 quadrillion tokens, 99.999943% input, near-zero output) and stelle-w (450B tokens, 75% input, 25% output, zero cache). Fifteen more were flagged by a multi-signal outlier score (3–4 signals): unusual ratios and activity fields within this dataset, without a workflow-mode label. Examples: iamtheavoc1 (7T tokens, 14% input, 18% output, 64% cache read — flagged, score 4), logcjj (115B tokens, 52% input, near-zero Yield — flagged, score 3).

[42] Not deleted, categorized in this historical analysis. Separating statistical extremes makes the reference median more representative; it does not itself define today's HITL or Agentic board membership.

What Each Type Looks Like

[42a] To make this concrete, here's what the cascade composition actually looks like for representative operators from each archetype. The numbers are real — pulled from the live leaderboard. Yield shown is the archetype median (the typical yield for that group), not the individual operator's yield.

Archetype	Example	Total	Input %	Output %	Cache Write %	Cache Read %	Archetype Yield
The Field	Xavierhorwood	4.91B	0.73%	0.36%	3.0%	95.9%	1.24
Context Builders	gwbiubiu	1.66B	0.94%	0.67%	4.0%	94.4%	6.71
Cache Architects	furic	6.72B	0.003%	0.26%	2.9%	96.8%	444
Input-Heavy	wuwangzhang1216	487B	33.7%	5.3%	0.03%	60.9%	0.02
Cache Builders	gabsh	253M	0.01%	0.63%	5.2%	94.2%	1,825
Cascade Operators	honggilgim	7.2M	0.01%	1.3%	2.3%	96.4%	135
Outlier	sadw1q	17.75B	0.14%	30%	0.0%	69.7%	110,251
Outlier (input dump)	grenadeoftacoss	9Q	99.9999%	~0%	~0%	~0%	0

[42b] Read the table left to right and the shape jumps out. The Field example puts in 0.73% fresh input and reads 95.9% cache — a 132:1 read-to-input ratio. The Cache Architect example puts in 0.003% — one fresh token for every 30,000 cache reads. The Input-Heavy example flips the pattern: 33.7% input, only 60.9% cache, Yield near zero. The input-dump anomaly records 9 quadrillion tokens, 99.9999% input, and zero compounding. sadw1q shows another extreme: 30% output, 68x the field median. That is a distinctive productive composition, not evidence that a human typed or an agent acted without supervision.

Notes from Building This

[43] A few things came up while putting this together. Less data observations, more lessons from the build:

1. Tell one story, not six. The page should walk a reader from "What is this?" to "Why does it happen?" to "Can I trust it?", not answer six questions simultaneously.

2. Percentiles, not averages. Operators don't care about the field average. They care about where they sit. Show percentile bands with a "YOU" marker. Athletic performance sites do this. It's addictive.

3. The historical Center of Mass. The median of the screened comparison group tells a clearer story than an average pulled by trillion-token anomalies. The original name referred to this statistical cohort, not a direct observation of each workflow's intervention mode.

4. The historical analysis found eight statistical groups. Seven composition clusters came from K-Means; the eighth came from outlier screens. These groups describe measured features, while HITL and Agentic are workflow modes that require their own evidence.

5. This is something that doesn't exist yet. GitHub measures commits. Stack Overflow measured reputation. Kaggle measures competitions. SigRank measures operator behavior, not models, not benchmarks, humans operating models. That's genuinely a different domain.

What's Next

[44] The field page is live. It shows the distribution, the 8 archetypes, the percentile bands, the cascade flow, the outlier zone, and the Benford trust badge. One story: Volume != Yield. You land on the Human Center of Mass and see where you fit.

[45] The methodology page is live. Full chi-square tables, the outlier detection algorithm, the clustering methodology, the provenance chain. This is the citation target, the place where "can I trust this?" gets answered.

[46] Phase 3: The Dataset. Upload to Zenodo, get a DOI, register DataCite metadata. The dataset becomes formally citable in academic papers.

[47] Phase 4: The Paper. "Benford's Law and Token Ratio Analysis for Outlier Detection in AI Coding Agent Leaderboards." The data is done. The analysis is done. It's writing time.

Why This Matters

[48] Operator leaderboards for AI coding are new. Nobody has figured out how to verify that the numbers are real. Benford's Law has been used for social bots, academic fraud, and forensic accounting, but never for LLM token telemetry. If this works (and the aggregate data says it does), it becomes the standard verification layer for any operator leaderboard.

[49] GitHub measures commits. Stack Overflow measured reputation. Kaggle measures competitions. SigRank measures the cascade: how humans operate AI models, not how models perform on benchmarks. That's a different domain, and it doesn't have a standard yet.

[50] The dataset is real. The outliers are categorized, not hidden. The archetypes emerged. The methodology is sound.

[51] Volume isn't Yield. The cascade shows different ways AI work can run: a screened center, productive high-reuse signatures far beyond it, and input-heavy or replay anomalies. Ratios make those differences visible; workflow evidence can show which signatures came from HITL or agentic execution.

[52] This is the first cut. 1,628 operators, one snapshot, one leaderboard. The methodology scales — the cascade math works on any token telemetry source, and the outlier detection framework generalizes to any operator leaderboard that exposes the four pillars. Next: longitudinal analysis (how operators move between archetypes over time), cross-platform comparison (does a Cache Architect on Anthropic look the same as one on OpenAI?), and the formal paper with full chi-square tables, clustering methodology, and the provenance chain. The dataset will be on Zenodo with a DOI. The field is young. The measurement layer is just being built.

---

Data: 1,628 classified operators (1,628 scraped, 130 outliers separated, 1,498 Human Center of Mass) from public AI coding agent leaderboards (2026-07-13) Analysis: Benford chi-square (scipy), K-Means clustering (scikit-learn), outlier detection (6-signal score + input/total ratio) Tool: SigRank, npx sigrank on npm Live board: signalaf.com · Field analysis · Methodology · Leaderboard Dataset: available for academic use (Zenodo upload pending)

---

This work is part of a broader research program on Commitment Theory — a 34-paper investigation into how governance structures emerge from measurable behavior in autonomous systems. SigRank applies the same principle to AI operators: you don't measure trust by asking, you measure it by observing the cascade.

- djm · MO§ES™ @burnmydays on X · GitHub