results.json, and traces every LLM call the harness makes into your project.
Start from the catalog
The New Harness page offers one-click presets, every prefilled field editable before you create the harness:- Suites (SWE-bench Verified, Terminal-Bench 2.1, τ³-bench, GAIA, Aider Polyglot) bring their own tasks and grading. They are Harbor-format suites and run one container per task: pick the agent scaffold with
HARBOR_AGENT(terminus-2by default, or any Harbor agent such asclaude-code) and cap the run withHARBOR_N_TASKS(5 by default; Terminal-Bench tasks take several minutes each). Where they run is on Run with Harbor. - The two Belvedir Runners accept a task list you author in the harness’s Tasks field and grade the outcomes with an independent LLM judge, so you benchmark the work your agent does in production. Belvedir Runner runs the whole set in one sandbox; Belvedir Runner on Harbor runs each task in its own container. Both also drive generated environments.
- Agent scaffolds (OpenClaw, OpenCode, Pi) take the same task list and run through Harbor.
belvedir benchmarks add, and cannot back an environment.
The harness contract
Your run command executes at the repo root with these environment variables set (plus any you configure on the harness):FRACTAL_* names keep working; see Migrating from Fractal. If the task-set file cannot be downloaded at startup, the run fails with a belvedir: note rather than running taskless.
Harness env variables are yours to define, with one restriction: build and loader variables that change how the sandbox itself installs or runs (PATH, HOME, proxy settings) are refused when you save the harness, and the error names the key. Put that configuration in your install command instead.
Report a score
Before exiting, writeresults.json at the repo root with a top-level numeric score on a 0 to 1 scale; everything else in the file is stored verbatim.
belvedir: note in the run’s log tail; a negative score, one past 100, or exiting 0 without a numeric score fails the run. Belvedir records the model the run was launched with as results.model; a model field your harness writes is informational, and if it disagrees with the launch configuration it is kept as results.model_reported with a note in the log tail. Runs attributed to a fine-tuned model’s name appear in that model’s View benchmarks panel on the Models page.
Which model runs
Public benchmark drivers do not hardcode a model. The model under test is ordinary harness env, set when you run:https://openrouter.ai/api/v1): one key of your own covers most hosted models, addressed as vendor/model ids like anthropic/claude-sonnet-5. Any other OpenAI-compatible endpoint works (a fine-tune deployed to your own Together account, your own vLLM), and on a CPU harness leaving the base blank infers the provider from the model id. On hosted Belvedir you can leave the model key blank and Belvedir covers the model usage for supported open models, spend-capped per run; those runs follow the project’s Chinese models permission, so naming a Chinese-lab model on a project with it off refuses the launch. LLM-judged drivers take the judge separately as JUDGE_MODEL / JUDGE_API_BASE / JUDGE_API_KEY, so the grader stays fixed while the model under test varies.
A GPU harness can serve the model instead of calling one: leave MODEL_API_BASE blank and serve MODEL (a HuggingFace id) in-sandbox with vLLM. That takes a GPU harness of your own; the catalog’s GPU presets are not yet available.
Run with attempts and grading
The New Benchmark wizard (My Benchmarks → New benchmark) picks one of your benchmarks, how many times each task runs, and the grading rule:pass@1, pass@k, or mean score. The choice is stamped on the run and handed to the sandbox as BELVEDIR_TASK_ATTEMPTS / BELVEDIR_GRADING. Grading is the harness’s job: run each task that many times and fold the attempts into the top-level score.
Choose a compute type
CPU (default) is for harnesses whose agent calls a hosted model API: Anthropic, OpenAI, or your own inference endpoint (set its URL as a harness env var). GPU is for harnesses that serve a model inside the sandbox: install vLLM or Ollama in your install command and start it from your run command; the sandbox gets an NVIDIA GPU (A10G by default). All sandboxes have git, Python 3, and Node preinstalled.Send traces explicitly
The SDK does not read the contract variables on its own; pass them toinitialize():
Benchmark a fine-tuned model
A GPU harness that serves the model in-sandbox can be launched from the Models page against one of your fine-tuned models. The sandbox is then given extra environment variables:MODEL (base HuggingFace id), ADAPTER_URL (a short-lived signed URL to the LoRA zip), MODEL_LABEL (the model’s name, recorded as results.model), and HF_TOKEN for gated bases. Serve base plus adapter and the run shows up in that model’s View benchmarks panel.