vizra/evals.
Which surfaces report
Dry runs are excluded deliberately: their numbers come from faked agents and would sit in
the history looking exactly like real ones.
Reporting cannot change a run’s outcome
A run that passed its gate passed it whether or not the network was up. So every failure in the reporter is returned as a message to print, never thrown:- One retry, because the common failure is a dropped connection.
- A
4xxis never retried — sending the same rejected document again cannot start working. - A failed push writes a line to stderr and nothing else.
Failing runs are reported too, before the test is failed. A run that got worse is the
one you most need in the dashboard — a history of only your successes would answer no
useful question.
Excluding a wiring test
Evals that fake the agent produce real-looking scores from canned responses. Keep them out of the history:--no-report does the same for one run. --report forces a warning when no
key is configured, which is useful in CI to catch a missing secret.
What is sent
The run’s metadata (suite, status, git sha, branch, timestamps, config snapshot), the aggregate summary, every row’s scores — and, unless you turn them off, the samples: response text, structured output, tool calls, token usage, finish reason, cost, and every assertion’s expected/actual plus the judge’s reasoning.
Sending less
.env
Environments
Runs are filed under an environment so a laptop run and a CI run are not the same number.- Anything running in CI is
ci, regardless ofAPP_ENV— CI boxes almost always setAPP_ENV=testing, and filing every CI run under “testing” would bucket them with someone’s local test run. - Otherwise the app’s environment is used.
- Override with
VIZRA_CLOUD_ENVIRONMENT.
Configuration
config/evals.php
auto_schedule is covered in Running from the dashboard.