BenchmarksImplementation 01 / 01

AgentLens - our own benchmark

The benchmark the basics tier demands, actually built: real agent tasks in two real harnesses (Pi and Hermes), repeated per model, with a clickable execution trace. Not whether a model fails, but where, when and why.

Implementations

One data sheet per system that implements this part - always the same grid.

The basics tier ends on an uncomfortable sentence: your own benchmark beats any leaderboard. We take it seriously - AgentLens is that benchmark, built on this very platform and fed with the very tasks people here give their agents.

Why another benchmark?

Public benchmarks deliver a number. That number doesn't answer what actually matters in practice: did the model never even attempt the tool call and merely describe it (a ghost call)? Did the parser reject a syntactically broken invocation? Did the chain tip over at step 4 - and what happened at step 3? Anyone picking a mid-sized model for a productive, locally hosted agent stack needs this diagnosis, not a grade.

AgentLens therefore stores the complete execution log of every run and evaluates at step level. The price: more storage and a normalisation layer. The gain: diagnosis instead of a leaderboard.

The method in four sentences

  1. Real tasks. No needle-in-haystack riddles but work orders: create and restructure files, analyse a server log, clean up a customer list, place a meeting diplomatically against three calendars, tidy a CRM without losing a single note - two of these are literally this platform's parcours tasks. Plus memory tasks across several conversation turns, with distractions in between.
  2. Real harnesses. Every task runs in the complete system of model plus agent harness - once under PiExternal - Opens in a new tab, once under the Hermes agent. Failures arise across the whole chain (chat template, decoding, parser, retry logic), so we measure the whole chain. "Qwen under Pi" and "Qwen under Hermes" are two different results - and that difference is one of the most interesting readings.
  3. Repeated, not once. Every cell (task × model × harness) runs several times. We separately show what a model achieves sometimes and what it achieves always - for production decisions, the gap between the two is the real answer.
  4. Deterministic verdicts. Passing means the checking code can measure it in the end state: file present, calendar correct, no note lost. No LLM grades an LLM.

When a run fails, the trace analyzer assigns it a failure class - ghost call, parser rejection, endless loop, error spiral after a tool failure, forgotten instructions as context grows, premature "done!". Outages of our own infrastructure never count against the model.

What you can see here

As a member (free) you see selected models in the results overview and can click through individual session traces step by step - every tool call, every result, every failed attempt.

As a Pro member you see everything: the full comparison matrix across all models and both harnesses, the failure-class fingerprints, harness deltas, endurance curves and every single trace - plus recommendations on which building blocks from Block II (parser, retry, context compaction) specifically compensate the weaknesses found in a combination.

We plug in new models as soon as they exist - endpoints are pure configuration. The moment Qwen 3.8 ships, it runs here against the same tasks as everything before it.

To the results overview