Help

A directory of apps built with AI coding agents, ranked on what the build actually consumed rather than on how many people voted for it. There are no upvotes anywhere on this site, deliberately — upvote ranking measures who has the biggest audience on launch day. Compute cost, time to ship and tokens burned are properties of the build itself.

Speedboard ranks by time between first and last recorded activity. Shoestring ranks by the API-equivalent cost of the tokens a build used. Heavyweights ranks by total tokens. Recently shipped is chronological and includes everything.

The three ranked boards contain verified listings only. A self-reported listing has no measured numbers, so including it would put an unmeasured app at the top of “cheapest build” for free.

It means one thing: the metrics were parsed from a ccusage report you uploaded, rather than typed into a form. ccusage reads the usage logs Claude Code, Codex CLI and Gemini CLI already keep on your machine.

It does not mean we audited the numbers. A report is a local file and could in principle be hand-written. We deduplicate uploads and review outliers, but the badge claims parsing, not proof — and we would rather say so than let the whole directory rest on a claim we can’t back.

Any app is welcome, whatever you built it with. Run this and paste the result on the submit page:

npx --yes vibescore-cli | pbcopy

That is the macOS form; the submit page shows the Windows and Linux equivalents. It copies to your clipboard rather than writing a file, so nothing lands in your project. The --yes matters: without it npx sends its install prompt down the pipe instead of the report.

It reads the session logs Claude Code already keeps in ~/.claude/projects and reports one entry per project. No file paths are included — only a project’s folder name — so pasting a report doesn’t disclose your directory layout. A raw npx ccusage@latest session --json paste still works, but it can’t measure build time.

Built with Cursor, Lovable, Bolt, v0 or anything else without a local usage log? List it as self-reported. It appears in the directory and is excluded from the ranked boards.

The cost figure is the API-equivalent value of the tokens a build consumed, priced at published per-token rates. It is not necessarily money anyone paid — most Claude Code users are on a flat-rate subscription, where that same work is covered by the monthly fee.

It is still the honest way to compare two builds: it says how much compute the work took, in a unit everyone can price. Cache reads typically dominate the number, which is why a long project can show a large figure without anyone being billed for it.

A build gets two times, because they answer different questions. Wall-clock is the plain span from first activity to last — calendar time, no interpretation. Active time is how long you were actually engaged, and it’s what the Speedboard ranks on.

The difference is usually large. A project of ours measured 45 hours of wall-clock and 10 hours of active time: the gap is nights, meals and the days it sat untouched.

The rule for active time, stated plainly because it’s a choice and not a fact: after Claude replies, the wait before your next instruction counts only if you come back within 30 minutes. Past that you had left. Claude’s own turns always count, so a long autonomous run is work rather than idle — it arrives as a chain of short gaps, not one long one.

Only the vibescore command can measure this, because it reads the session transcripts. Listings submitted from a raw ccusage report have no active time: that payload records when each session ended and says nothing about the gaps between. Those show wall-clock instead, dimmed, and sort below every measured build rather than being ranked against them — 10 engaged hours and 10 elapsed hours are not the same achievement, and mixing them would make the column meaningless.

A ccusage listing that spans two or more sessions shows ≈, since the span between session ends is a lower bound. One with a single session shows —: a single end timestamp is a moment, not a span.

An app doesn’t stop when it ships. You can run the command again later and add a snapshot to a listing you already own — a record of where the project has got to — and its page grows a build history showing what each stretch of work added.

Every board therefore has two views. Launch stats is the default and ranks on each app’s first snapshot: what it took to get the thing off the ground. Ship an MVP in a day for two dollars and that stays true forever — maintaining your app afterwards never costs you the record of how fast you launched it. Current stats ranks on the newest snapshot instead, which rewards the opposite thing: depth of ongoing work rather than speed out of the gate.

Each snapshot measures the project’s whole life to that point, not just what changed — the command reads every session on your machine each time it runs. That is why the totals only ever grow, and why the per-sprint figures on a listing are worked out by subtracting one snapshot from the one before rather than being reported directly. A snapshot showing less than the one before it is refused: it means some session history is missing from that machine, not that the work shrank.

A single 1–100 number, separate from the three boards. Where the boards each rank one raw dimension, VibeScore grades how well the agent was driven — so a small, disciplined build can score as well as a huge one.

It only appears on builds measured by the vibescore CLI, not a raw ccusage paste — the reason is the same one covered above under active time: only the CLI can tell engaged time from idle, and one of the three pillars needs that number to mean anything.

• Context Mastery (40 pts) — the share of input tokens served from cache instead of re-sent. Full marks at a 100% cache-read ratio.
• Agentic Velocity (30 pts) — fresh tokens (input and output, not replayed cache) per hour of active build time. Cache reads are excluded on purpose: they balloon with conversation length regardless of pace, which would just re-measure Context Mastery under a different name. Full marks at 1,000,000 tokens/hour or faster.
• Output Yield (30 pts) — output tokens produced per dollar of API-equivalent cost. Full marks at 10,000 output tokens per dollar or better.

Each pillar scales linearly up to its ceiling, then caps — going past the benchmark doesn’t earn extra points, it just means the build is comfortably ahead of it. The ceilings are a first pass and will move as more measured builds come in.

Like the boards, a listing’s score follows launch stats by default and can be switched to current stats on its page. The rank shown next to the share text (“#4 on Heavyweights”) is always that app’s position on the tokens board specifically, not a VibeScore ranking of its own.

A builder’s profile shows one cumulative VibeScore too — every published app’s current snapshot summed into one set of totals and scored once, not an average of each app’s own number. Only transcript-measured apps contribute to it.

New submissions land in a review queue and appear publicly once approved. While a listing is pending you can open its page yourself to see exactly how it will look — it stays invisible to everyone else until it goes live.

Featured placements are sold and set by hand. They are labelled as featured and never change the ranked order beneath them.