dongarandClaude Opus 5.5
50b46821d7
CI / checks (push) Skipped
CI / checks (pull_request) Successful in 1m11s
Choosing a local executor model, and tuning its knobs, needs measured success rates across repeated runs, comparable with every model measured before. - Four canned milestones under nisse_dev/bench/tasks: write a function, fix a bug a failing test exposes, thread an option through several files, and find one failure in output far past max_output_chars. Each is an approved plan over a seed project, judged by a hidden check the model never sees; a reference solution proves each is solvable and that its check tells the difference - Runs use the agent's own client wiring, now shared as make_llm_clients, with delegation and ask_expert off: an escalation is a failure of the model under test - Each run is stored as one JSON line in bench/results/, committed, with the model's backing name and declared facts, a note on how it was served, the task's content hash, the agent's commit and tuning, the outcome, turns, misbehaviour counts, context trims, tokens, time and LiteLLM's cost; a fallback answer can never count as a success - The report rebuilds the comparison from every stored run, with Wilson 95% intervals, marking runs against older task versions - scripts/benchmark.py runs and reports; scripts/evaluate_model.sh takes a new model through the context probe, the capability matrix and the benchmark in one command - Clients keep LiteLLM's per-call cost, and BudgetedClient counts the requests it had to trim - The tuning guide gains "Benchmarking models" Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
18 lines
917 B
Python
18 lines
917 B
Python
"""The executor benchmark: canned milestones, run repeatedly per model.
|
|
|
|
Choosing an executor model, and later tuning its knobs, should rest on
|
|
measured success rates, not on one run or on reputation. Each task is a fixed
|
|
approved plan over a seed project, with a hidden check the model never sees;
|
|
success means the check passes, not that the model said it finished. Runs use
|
|
the agent's own client wiring (context budget, declared limits, tool_choice
|
|
only where declared), so what is measured is what the agent would do.
|
|
|
|
Results are stored, one JSON line per run, with everything needed to compare
|
|
them later: the model's identity and declared facts, a note on how it was
|
|
served, the task's content hash, the agent's commit, and its tuning. A new
|
|
model then needs only its own runs to be compared with everything measured
|
|
before it.
|
|
|
|
See scripts/benchmark.py, and docs/Tuning-Guide.md for how to read results.
|
|
"""
|