add efficiency leaderboard metric

[kevinfosterNG]

What changed

• add an Efficiency tab to the homepage leaderboard beside Cost and Tokens
• compute efficiency client-side as totalTokens / totalCost and display it as a Tok/$ column
• fetch and sort the full filtered result set client-side for efficiency mode so rankings stay accurate
• update homepage and README copy to mention the new efficiency metric

Why

The homepage currently highlights spend and token volume, but it does not surface which submissions get the most tokens per dollar. This adds a focused third ranking mode without changing the database schema.

Impact

Users can now switch the root leaderboard to an efficiency-oriented view and identify the most cost-efficient submissions, while existing cost and token rankings remain unchanged.

Validation

• pnpm build
• pnpm exec tsc --noEmit
  Fails in the current repo due to pre-existing type/config issues unrelated to this change.
• pnpm lint
  Fails in the current repo because the script still uses next lint, which is invalid under the current Next.js setup.
• pnpm test
  Fails in the current repo because the script runs node directly on test/ccusage.test.mts.

[vercel]

@kevinfosterNG is attempting to deploy a commit to the sculpt Team on Vercel.

A member of the Team first needs to authorize it.

[nikshepsvn]

Sorry this sat so long. An efficiency metric (cost per token, or tokens per dollar) is a genuinely good idea for the board — it rewards something other than raw spend, which is worth having.

Test-merged against current main: the only conflict is src/app/HomeClient.tsx. Everything else applies cleanly.

Two things to flag before you rebase:

1. fix: submission and leaderboard data integrity #100 substantially changed src/lib/data/supabase/client.ts, which this touches — rebase after it merges.
2. Your Leaderboard.tsx changes will want a look against fix: submission and leaderboard data integrity #100 too: it fixed the seeded-default-view logic (filter → clear filter used to leave the board permanently blank), so the sort/filter branch you're extending has moved slightly.

[nikshepsvn]

Landed as #118, with you credited via Co-Authored-By. The idea was right and it's live — a second axis matters a lot on a board whose #1 by cost is a $205K outlier.

I did rework the implementation, and it's worth saying why rather than just closing this.

Sorting moved into the database. This PR sorted client-side over the ~25 rows already fetched, which answers "who is most efficient among the top 25 by cost" rather than "who is most efficient" — a different and much narrower question. It also forced hasMore to false, so the board offered fewer pages than it actually had.

Zero cost is NULL, not Infinity. getEfficiencyScore returned Infinity for a zero-cost submission, which would pin that row at #1 permanently. Division by zero has no honest answer here, so the stored column is NULL and sorts last.

A spend floor, which is the part I'd have missed without checking the data. Unfiltered, the top of the efficiency board was a $0.01 submission at 7M tokens/$ against a median of 1.2M — the ratio of a rounding error. The whole top of the ranking was noise. Above $100 it spans $112 to $11K of real spend and reads as a genuine ranking. 1,030 of 1,131 submissions qualify.

Date filters disable it rather than falling back silently. The date-range board aggregates daily rows and has no stored ratio to order by, so offering the toggle there would show a cost ranking under an efficiency label.

One thing your PR surfaced that I've filed separately: the unfiltered #1 was a username that's a shell fragment — psource /Users/pawelkiszczak/Projects/.../activate. Someone's git config user.name picked up corrupted text and it's a public leaderboard entry. That's a real data-quality bug and I'd not have gone looking for it without building this.

Sorry this sat for seven weeks before getting a proper answer.