Tokenmaxxing 1.0 was burning as many tokens as possible, rolling coal to look busy. 2.0 flips it: the win is surviving work per token, progress above activity. Spend big if the job needs it, then haul the cargo to match. The board above is the bragging rights, folded live from the shared frontier and anonymized; the method beside it is how to find the setup that hauls the most for your needs, and the one change most likely to move your number.

How this is measured

Surviving work per token

The numerator is a git measurement: lines you shipped that still live at HEAD, not reverted, rebuilt, or later bug-fixed, read at a horizon. It is the same for a human, Claude Code, or any agent. The denominator is priced tokens: input, output, and cache differ in price by about 20x, so they are counted and costed separately.

The rig fingerprint

Every setup is placed in a rig-space by a self-organizing map: topology, model routing, reasoning effort, review regime. The map on the left is that space; the territories are engine styles. Efficiency is a vector, never one grade, because the winner on one axis rarely wins another.

What we tested

Vibrant keeps a claims register: standing hypotheses re-checked every measurement window. A sample of the verdicts, from one operator's real logs:

  • Cost is O(reads)confirmed reads about 85% of spend.
  • Solo is cheapest per surviving-KBsupported
  • Orchestrator to cheap-worker is N x cheaperrefuted same cost, more waste.
  • A cross-family model switch repays full prefillconfirmed
  • The raw efficiency ranking is real thriftrefuted it is a task-difficulty selection artifact: efficiency = survival-rate x production-rate.

To remove that confound, the dynamometer runs one fixed task across engines: orchestration multiplies token consumption for the same passing result. Its payoff is scope, not thrift.

Sources and analyses
  • Protocol and governance: the measure, and the constitution behind it.
  • Claims register: every hypothesis, its metric, and its verdict (C1 to C14, review claims R1 to R6, external X1 to X8).
  • Dynamometer result: the fixed-task solo versus orchestration experiment.
  • Federation: how anonymized aggregates travel (Nostr NIP-01 events, NIP-13 proof-of-work, BIP-340 signatures).
  • Anthropic, Optimizing for cost and intelligence and Multi-agent systems: their findings, re-tested against our own git-survival data (claims X1 to X8), never adopted on faith.
  • DORA: the change-failure-rate definition used in the report.
Run it yourself

Both ways are just Claude Code and a plain question. Install the plugin anywhere:

/plugin marketplace add 3dl-dev/vibrant
/plugin install vibrant@vibrant
"How efficient is my coding setup?"

Or clone the repo and start Claude Code inside it, nothing to install:

git clone https://github.com/3dl-dev/vibrant
cd vibrant
claude
# then ask: "How efficient is my coding setup?"

Claude Code runs the repo's own vibrant-report skill on your machine: it reads your logs and your git survival and writes the report. Python 3 standard library, nothing uploaded. The first run reads all your logs and can take a few minutes.