bytemark~/results

$ bytemark --help

the benchmark
for efficiency

Frontier evals measure how well the most expensive models handle the hardest problems on earth. Almost no production work is hard. It is a receipt, a support ticket, a PDF nobody wants to read. ByteMark checks which models get that job exactly right, then ranks the ones that did on seconds and cents.

[ see the results ][ github · soon ]
scenarios
12
models
49
calls
4,191
spent
$16.96

$ bytemark -eval plate-recognition -trials 20

9/14 models scored a flat 100% on every field, every trial. sorted by cost. last, the worst score of the same run.

same answer. 39.5× the price, 9.6× the wait.

# the premise

01

The tasks are dull on purpose.

Read a receipt. Pull the fields off a support email. Lift the header facts out of a research PDF. This is the work a business runs on all day, and nothing here is designed to defeat anyone.

02

So accuracy stops being the story.

9 of 14 models scored a flat 100% on every field, every trial. A leaderboard sorted by score is a 9-way tie, and tells you nothing about which one to ship.

03

Seconds and cents are the score.

Those tied models are 39.5× apart on the bill and 9.6× apart on the wait. The crown goes to the cheapest model that got everything right. Being frontier earns nothing here.

# the scenarios12 scored · 1 planned

scenarioinputcheapest clean run$/tasklat

Planned

Parallel Tools [soon]One request that legitimately needs three calls at oncesingle-turn

# how it works

Evals are code
Each scenario is a Go type with its own fixtures and a field-level grader. No prompt-and-hope: a field is right or it is not.
One command, every model
The CLI fans out across providers, repeats each case N times, and records tokens, latency and cost for every single call.
Runs are files in the repo
A run is committed next to the fixtures and prompts that produced it, so a score change is attributable. This page is built from those files.