Your evals already work. This is where the answers live.
Shared history, one baseline the whole team sees, CI runs that keep theirs, and a Run button for the people who never open a terminal.
One environment variable. No agent to install, nothing to expose.
We never run your code.
This is the first question anyone sensible asks, so here is the answer before the feature list. Your evals run where they always did — in your application, against your database, on your model keys.
Your app reports out
A finished run posts its results to us. That is an outbound HTTPS call from your infrastructure, so nothing has to be exposed — it works from CI, from staging behind a VPN, or from a laptop.
We hold no credentials
No model API keys, no database credentials, no source code, no repository access. There is nothing in our database that could run your agent even if we wanted to.
You choose what we see
Scores and timings always. The prompts and responses behind them are what powers the drill-down, and one setting turns them off if they are not allowed to leave your network.
Everything that breaks when it is more than you.
History that outlives a laptop
Locally, your baseline lives in whoever ran it last. Here it is one record the whole team shares, and CI runs keep theirs instead of throwing them away with the container.
- Every run kept
- One shared baseline
- Per-branch history
Run it without a terminal
A domain expert can open a suite and press Run. It executes in your environment on the next check-in — the cloud only asks. That is the whole point: the person who knows whether the answer is good stops needing a developer.
- One click
- Runs in your app
- No terminal, no setup
Runs from CI keep their history
A CI run reports itself like any other, tagged with the branch, commit and pull request it came from — so a branch can be compared against the baseline instead of vanishing with the container.
- Branch and commit kept
- PR number recorded
- Compare against baseline
The reason, not just the number
Click any row and read what the model actually said, which tools it called, and why the judge scored it the way it did — months later, on a run you did not do.
- Full response
- Tool calls
- Judge reasoning
One line, and you are connected.
If you are already using vizra/evals,
there is nothing new to install. Reporting is built in.
VIZRA_CLOUD_KEY=vz_…
That is the setup. Every finished run reports itself, and the package registers the check for the Run button on your scheduler automatically — the cron you already run does the rest.
Point us at your workflow instead and the Run button starts it. Nothing needs to be running between builds, and there is still nothing extra to install — the workflow runs the same command.
GitHub Actions today, with a fine-grained token that can start that one workflow and nothing else.
Priced per project, never per seat.
Charging per seat would punish the one thing this is for — getting more of the team looking at quality. Runs are never metered either.
For trying it out on one project.
- ✓ Unlimited eval runs
- ✓ 1 project
- ✓ 2 seats
- ✓ 14 days of per-sample detail
$290 billed yearly
For a team shipping agents together.
- ✓ Unlimited eval runs
- ✓ 5 projects
- ✓ Unlimited seats
- ✓ 90 days of per-sample detail
$990 billed yearly
For agencies running evals across many clients.
- ✓ Everything in Pro
- ✓ Unlimited projects
- ✓ 12 months of per-sample detail
- ✓ Priority support
Keep the runs you are already doing.
Free for one project, forever. Add a key to an app you have already set up and your next run appears here.