Burnboard, a leaderboard for your AI coding token burn
I built a thing called Burnboard.
It’s a public leaderboard for AI coding tool usage, measured mostly in tokens. It’s also a little uncomfortable, because it’s a leaderboard for spending money on robots.
Both of those are true.
What it is
Burnboard shows a leaderboard of token usage over a period (day, week, month, etc), and lets you click through to a profile page with your own stats.
If you’ve been using Claude Code, OpenCode, or OpenAI Codex a lot lately, you already know the vibe. I’ve been a developer for almost 20 years, and this is the way things work now. If you want to stay effective at your job, you end up learning how to work with these tools, you end up caring about model choice, and eventually you end up caring about efficiency.
Burnboard is me leaning into that reality, and also trying to make it a little fun.
The part that’s weird
A leaderboard implies winning. It implies more is better.
That’s a weird thing to say about tokens.
Tokens are a proxy for time, velocity, leverage, experimentation, and sometimes just plain waste. They are also a proxy for cost. Depending on how you work, “top of the leaderboard” can mean:
- you shipped something hard
- you got stuck and thrashed
- you left an agent running while you made lunch
- you are running a bunch of prompts that should have been cached
So, no, I’m not sure we should be celebrating the number going up.
But I also think pretending we’re not all doing this is fake. The tooling is here, it’s powerful, it’s not going away, and if you’re using it all day, it’s worth understanding what it’s actually doing.
There’s also a reasonable argument that the “leader” should be the person who used the least tokens to get the work done. That is probably the healthier instinct. Burnboard doesn’t solve that philosophical problem, it just makes the data visible.
How it works (high level)
Burnboard is intentionally boring in the best way, it’s just OpenTelemetry.
Claude Code, OpenCode, and Codex can export telemetry. Burnboard receives that telemetry, stores it, aggregates it, and renders it back as leaderboard stats.
No plugins, no scraping your filesystem, no uploading prompts, no reading your code.
If you want to see the full setup script, it’s in the repo as a plain bash script generator:
And there’s a public “How it works” page in the app that tries to be painfully explicit about what’s collected and what isn’t.
What data gets collected
This is the main promise: Burnboard only deals in aggregate counts.
Collected:
- token counts (input, output, cache)
- cost (calculated from token counts)
- model name (like Opus, Sonnet, Haiku, etc)
- session duration / active time
- lines added / removed
- commit and PR counts
Not collected:
- your code, file contents, or diffs
- prompts or conversation text
- file names, paths, or repo names
- secrets or API keys
- anything from your GitHub repos
The GitHub login is just to put a username and avatar on the board. The app requests read:user, which is public profile info.
Compatibility, what it touches on your machine
The goal of the setup flow is to configure your tools to send OpenTelemetry (OTLP) data to Burnboard, tied to an API token.
Burnboard supports three sources right now:
- Claude Code: configured via environment variables in your shell config
- OpenCode: configured via environment variables, plus enabling its OpenTelemetry flag
- OpenAI Codex: configured via
~/.codex/config.toml
So the “local directory” story is pretty simple: this isn’t an agent you install, it’s mostly a handful of env vars and small config changes.
The uninstall script is also just a plain script that removes those lines from your shell config:
/uninstallon the site, or the equivalent script in the repo
The profile page is the real point
The leaderboard is the hook, but the profile page is where this becomes useful.
There’s a page for each user at /u/{github_username} that shows your totals, breakdowns, and a handful of derived stats. It also tries to teach what the numbers mean, instead of just shouting them at you.
One metric I think is worth highlighting is cache efficiency.
Burnboard calculates cache efficiency as:
cache read tokens / (input tokens + cache read tokens + cache creation tokens)
In plain English, it’s “what percentage of your input side was served from cache.” Higher is better, because it means you’re reusing more context instead of paying full price for it over and over.
If you want to reduce token burn without reducing capability, improving cache efficiency is one of the best levers you have.
That usually means:
- keeping conversations focused instead of megathreads
- reusing stable context instead of re-pasting it
- using tools and patterns that encourage reuse (templates, commands, scripts, docs)
- doing less thrash, more iteration on a single plan
None of that is a moral stance, it’s just math.
Verification, because self reported metrics are easy to fake
Telemetry is self reported, so if you’re building a public board you have to at least acknowledge the obvious failure mode.
Burnboard has a verification system that cross references the reported commit and line change metrics with public GitHub activity. It’s not perfect (private work can’t be verified), but it’s a reasonable attempt to separate “real usage” from “someone forged a JSON payload.”
If you care about the implementation details, you can follow the code path from the ingest endpoints to the metrics table and aggregation.
Why I made it anyway
I keep coming back to the same thing. Even if you hate the idea of “token culture,” tokens are still the most concrete way to understand what your tools are doing.
The money side matters, but so does the efficiency side.
Also, a leaderboard is the fastest way I know to get people to look at their own numbers. Nobody reads dashboards for fun. People click their own name on a leaderboard.
So yeah, it’s a little bit of a trick.
What I want to add next
I have a bunch of ideas here, but the ones that feel most worth it are:
- more explanation on the profile page for each stat (especially cache stuff)
- a version of the leaderboard that rewards efficiency instead of raw spend
- better breakdowns by tool and model over time
If you have strong opinions about what this should be, or what it absolutely should not be, I want to hear them.
Burnboard is open source: https://github.com/davekiss/burnboard