evalpair

io.github.SrikarmkPublished by GitHub account Srikarmkv0.1.1Updated Nov 5, 2026

Run LLM eval suites on local or hosted models; compare runs with intervals and a noise floor.

VerifiedSTDIODesktop onlyData & AnalyticsAI & ML

Overview

AI-generated overview

Runs LLM eval suites against local or hosted models and compares two runs with bootstrap intervals and a noise floor.

What you can do
  • List available eval suites with item counts, checkers and what they measure
  • Run a suite against one model, save the run, and get its score with a 95% interval plus first failures
  • List and show saved runs, including noise floor and the end of failed replies
  • Compare two runs item by item: paired score difference with interval, items worse and better, and whether answers moved beyond the noise floor
When to use it
Use it when you need to know whether a new model, prompt, quantization or server setting actually changed results, rather than reading two scores side by side. Suited to checking bundled or custom suites with code-checkable answers on Ollama or an OpenAI-compatible server.
Requirements
Runs locally via uvx (Python) over stdio. Needs a reachable model server: Ollama at localhost by default, or an OpenAI-compatible base URL. A bearer token, if the server requires one, is read from EVALPAIR_API_KEY or OPENAI_API_KEY. State is kept in EVALPAIR_HOME or ~/.evalpair.
Before you install
run_eval calls the model server, which may cost money on a hosted API and takes time on large suites; other tools only read saved runs. The API key is read from the environment and not written to disk. Replies, parsed answers and scores are stored locally in the evalpair home folder. Deterministic checkers only, so open-ended answers cannot be graded.

Installation

In SourceWeft

  1. Open evalpair in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.

Other MCP clients

Follow the launch instructions in the repository.

README

evalpair

Run an LLM eval suite against a model, cache every call, and compare two runs item by item: did the new model, prompt or quantization actually change anything, or is the difference noise?

Most eval tools print two scores side by side. That reads a 2-point gap on 160 questions as a result, when it usually isn't one. evalpair pairs the two runs by item, puts a bootstrap interval on the difference, counts the items that got worse and better, and can measure a noise floor: the same model asked the same questions twice. In my own studies the same prompt sent twice at temperature 0 changed up to 3% of answers, so an answer-change rate only means something above that.

It's a CLI and an MCP server, so an agent can run an eval and read the verdict itself. It only calls the model server you point it at, and keeps everything in one local folder.

Quick start

bash
uvx evalpair suitesuvx evalpair run gsm8k-160 -m llama3.1:8b --repeat --label llamauvx evalpair run gsm8k-160 -m qwen3:8b --think off --label qwen3uvx evalpair compare llama qwen3

run prints the score with a 95% interval and the first failures, unparsed and truncated replies first (those are usually the parser's or the token budget's fault, not the model's). compare prints both scores, the paired difference with its interval, how many items got worse and better, the noise floor, and ends with a plain-language verdict: whether the score difference is distinguishable from zero, and whether the answers moved more than the same model asked twice.

A real comparison: Ollama's default 4-bit Llama 3.1 8B against its 2-bit build, on an M5 Pro laptop (--num-ctx 4096; about 40 minutes for both runs):

$ evalpair compare llama-q4 llama-q2A            llama-q4: 84.4% [79.4%, 90.0%]B            llama-q2: 60.6% [53.1%, 68.1%]B − A        -23.8 pp [-31.9 pp, -16.2 pp]changed      40.6% [33.1%, 48.1%] of 160 items (43 worse in B, 5 better)floor (A)    0.0% [0.0%, 0.0%]; excess +40.6 pp [+33.1 pp, +48.1 pp]
B scores lower than A: -23.8 pp [-31.9 pp, -16.2 pp], paired over 160 items. Answers changed on 40.6% ofitems (43 got worse, 5 better). The noise floor (the same model asked twice) is 0.0% for A, so the changeis beyond noise.  worse in B:  gsm8k-0259  '168' → '52'  ...

Both scores are the ones the quantization study measured for these builds on the same items.

Interrupt a run and run it again: every reply is cached, so it picks up where it stopped.

As an MCP server

bash
claude mcp add evalpair -- uvx evalpair mcp

or in any MCP client's config: {"command": "uvx", "args": ["evalpair", "mcp"]}.

ToolWhat it does
list_suitesSuites you can run: name, item count, checker, what it measures
run_evalRun a suite against one model and save the run (calls the model; cached replies are reused)
list_runsSaved runs, newest first
show_runA run's score with its interval, its noise floor, and the end of failed replies
compare_runsTwo runs paired by item: difference with an interval, flips each way, change vs. noise floor, examples

Everything except run_eval only reads saved runs.

Backends

  • Ollama (default): --backend ollama, server at http://localhost:11434. The run records the model's digest, so you can tell later exactly which build was tested. --think on|off for models that think, --num-ctx for the context window.
  • Any OpenAI-compatible server: --backend openai --base-url http://localhost:8000/v1 for vLLM, llama.cpp's server or LM Studio, or a hosted API. A bearer token is read from EVALPAIR_API_KEY (or OPENAI_API_KEY) and never written to disk.

Temperature defaults to 0 and the seed to 7. Both are part of the cache key, along with the server URL, model, messages, token budget and thinking setting.

Suites

Three are bundled. They're the item sets from my Measuring LLM Systems studies, with those studies' prompts word for word, so a run can be checked against the published numbers:

SuiteItemsCheckerSource
gsm8k-160160numberGSM8K test (MIT)
mmlu-hs-160160choice, stratified by subjectMMLU, four high-school subjects (MIT)
e2e-extract-150150json_fieldsE2E NLG restaurant records (CC BY-SA 4.0)

To make your own, create a folder with two files, in ~/.evalpair/suites/<name>/ or anywhere you then pass by path:

toml
# suite.tomldescription = "Capitals, answered in one word"checker = "exact"max_tokens = 64system = "Answer in one word."           # optionaluser = "What is the capital of {country}?"group = "region"                         # optional: stratify the bootstrap by this item field
jsonl
{"id": "fr", "country": "France", "region": "Europe", "gold": "Paris"}{"id": "pe", "country": "Peru", "region": "Americas", "gold": ["Lima", "Ciudad de los Reyes"]}

{field} in a prompt is filled from the item; a list of strings becomes lettered options (A. …), anything else is shown as indented JSON. Use {{ and }} for literal braces.

CheckerScoresGold
numberthe number after "Answer:", else \boxed{}, else the last numbera number
choicethe letter after "Answer:", with fallbacks (letters set by checker_options.letters)a letter
exactthe text after "Answer:", or the last line, normaliseda string or list of strings
containswhether a gold string appears as whole wordsa string or list
regexthe last match of checker_options.pattern (first group)a string or list
json_fieldsthe share of the gold object's fields the reply's JSON gets right (null must be null)an object

Checkers are deterministic code: no LLM grades another LLM here. The number, choice and json_fields parsers come from the studies, and re-scoring all 9,870 replies from the quantization study's main run with them gives the study's own scores on every one (scripts/check_against_studies.py).

How the numbers are computed

  • Unit of resampling: the item. 2,000 bootstrap draws, percentile intervals, seeded, so the same runs always give the same interval. With a group, items are resampled within each group.
  • Comparisons are paired over the items both runs answered, using the first pass of each. If the two runs used different versions of a suite (the hash of its spec and items differs), the comparison says so.
  • Noise floor: with --repeat, every item is sent a second time as a separate call (its own cache entry). The floor is the share of items whose parsed answer changed between the passes. A comparison calls a change "beyond noise" only if, per item, (changed between runs) minus (changed between the passes) has an interval above zero for every run that has a floor.
  • Items are taken in file order, so --limit 50 is the same 50 items every time and limited runs still pair up.

Where things live

$EVALPAIR_HOME, or ~/.evalpair:

cache.sqlite           every reply, keyed by requestruns/<run>/meta.json   suite and its hash, model, digest, backend, options, counts, timingsruns/<run>/rows.jsonl  one line per item and pass: reply, parsed answer, score, tokenssuites/<name>/         your suites

Limits

  • One model per run, chat-style prompts, one turn. No tool use, multi-turn or constrained decoding yet.
  • Deterministic checkers only, so open-ended answers need a suite whose answer can be checked by code.
  • The noise floor measures run-to-run variation on the same server. It doesn't cover a different machine or a server update.

License

MIT for the code. The bundled suites keep their sources' licenses (MIT for GSM8K and MMLU, CC BY-SA 4.0 for E2E NLG); each suite.toml names its license and source.

Source: README.md at commit d945d27

Tools

5

list_suites

List eval suites

Use to see which eval suites can be run: name, item count, checker and what each measures.

Takes no parameters.

list_runs

List saved runs

Use to find earlier runs to show or compare: run id, suite, model, item count, whether it has a repeat pass.

Parameterslimitsuite

run_eval

Run an eval suite

Use to run a suite against one model and save the run. Returns its score with an interval and its first failures. Calls the model; cached replies are reused.

Parametersseedlabellimitmodelrequiredsuiterequiredthinkrepeatbackendbase_urltemperature

show_run

Show a run

Use to see a saved run's score with its interval, the noise floor if it has a repeat, and the end of failed replies.

Parametersrunrequiredfailures

compare_runs

Compare two runs

Use to compare two runs of the same suite item by item: score difference with a paired interval, flips each way, and whether answers moved more than the noise floor.

Parametersarequiredbrequiredexamples

Version history

1
  1. v0.1.1LatestNov 5, 2026

Score

90% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 days25 pts
  • Auth declared10 pts

    Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.

  • Tools listedRequired15 pts
  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts