bro / benchmark
AGENTS.md12 starsChanged 13 days agoApache-2.0View on GitHub
Driving a bro as an agent under Harbor, the harness Terminal-Bench runs on. The distribution is bro-benchmark and its package is bro.benchmark, a portion of the framework's bro namespace; nothing in the framework imports it. What the project is and how to drive it is README.md. The launcher-side bro-bench member is mapped by ../bench/AGENTS.md. This is not a uv workspace member: harbor reaches openai < 3 through litellm while the wire distributions' client extras pin openai == 3, so no…
Where files are headingNew AGENTS.md files have more rules about keeping secrets out of the code, and fewer about code style.
Of the AGENTS.md files we read, the 31,439 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.
In this repository9 other files it gives its agents.
- AGENTS.mdAGENTS.md
- bench/AGENTS.mdAGENTS.md
- bro/AGENTS.mdAGENTS.md
- browser/AGENTS.mdAGENTS.md
- dev/AGENTS.mdAGENTS.md
- filetypes/AGENTS.mdAGENTS.md
- local/AGENTS.mdAGENTS.md
- oops/AGENTS.mdAGENTS.md
- ride/AGENTS.mdAGENTS.md
The file
We split this AGENTS.md into the rules it gives an agent
2 rules. About 0 are common, 0 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 20
No harness is a dependency: Harbor's process runs none, and a trial gets both from the relocatable bundle, which builds and installs bro …
- Very specific: line 42
Run them explicitly, from .venv:
≈ “Common” is an estimate: at least 1 in 5 of the 40,246 AGENTS.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Terminal-Bench harness adapter
Driving a bro as an agent under Harbor, the harness Terminal-Bench runs on.
The distribution is
bro-benchmark and its package is bro.benchmark, a portion of the framework's bro namespace;
nothing in the framework imports it.
What the project is and how to drive it is README.md.
The launcher-side bro-bench member is mapped by ../bench/AGENTS.md.
Development
This is not a uv workspace member:
harbor reaches openai < 3 through litellm while the wire distributions' client extras pin openai == 3,
so no single lock satisfies both.
The directory therefore locks and syncs on its own:
uv sync --directory benchmark --all-groups builds .venv from the uv.lock committed beside this file.
It depends through editable path sources on core, ride, both trail-format distributions, the bare provider plug-ins, and bro-bench,
whose launcher-side credential and command registrations, and the preset composition the job runner reads, are shared with the root environment.
Bare provider plug-ins supply declarations and pricing without pulling wire clients into Harbor's interpreter.
No harness is a dependency:
Harbor's process runs none,
and a trial gets both from the relocatable bundle, which builds and installs bro plus both harnesses and their trail-format distributions from the root workspace.
Its requirements export requests the client extras, and the build validates every registered wire client in the bundled interpreter.
Formatting and linting stay the repository root's, which walks this directory through its
[tool.ruff] src.
The suite's environment rebuild is the root's too, but reaches a run only through
the conftest at its pytest root
— so the conftest.py beside this file applies it, and a suite that
did not would inherit the session running it.
pytest and pyright run from here instead, inside .venv:
run-tests syncs it and
drives both, and --skip benchmark skips that whole stage.
Build the wheel with uv build from this
directory rather than uv build --package.
The *_e2e_test.py modules sit in a roster no gate stage runs (BENCHMARK_E2E_PYTEST_FILES):
they build a bundle and drive the host
docker daemon, the way ride/ride/e2e_test.py does.
The two that grade a trial spend real tokens as well, so conftest.py holds them out of directory collection:
pytest reaches them only as files named on its command line.
Run them explicitly, from .venv:
uv run --directory benchmark pytest bro/benchmark/bundle_e2e_test.py
uv run --directory benchmark pytest bro/benchmark/harbor_e2e_test.py
uv run --directory benchmark pytest bro/benchmark/benchmark_job_e2e_test.pyComponents
bro/benchmark/cli.py(benchmark) — owns every post-run verb:bundle,retain,publish,query, andimport-trailsbro/benchmark/bundle.py(benchmark bundle) — builds the relocatable runtime a foreign container runsridefrom, in the materializedvenv/+bin/layout--runtime-bundletakes: a pinned standalone CPython with the dependenciesWHEEL_PACKAGESresolves to against the workspace lock and those distributions themselves as built wheels installed into its own site-packages, every console script relocated to find the interpreter beside itself, ride's shim farm over the session commands, and runtime assets installed by the bundle’s own registered harnesses. Its manifest records thebenchmarkinstallation home and those inputs plus each harness’s files and checksums and gives the bundle a content-derived identity. The bundle writes its installation-home marker beside the interpreter's environment.Bundleis the layout a consumer addresses — interpreter, scripts, shim farm, manifest, and identity;built(root)reports a stale, incomplete, or malformed bundle rather than building one behind the caller's back;cached(workspace, root)builds a stale one first and refuses the restbro/benchmark/harbor_agent.py—BroAgent, theBaseInstalledAgentharbor imports. Its Harbor version is the uploaded bundle's identity, and its recorded name carries the bro and, off the default, the harness.install()has the uploaded bundle's own framework hydrate a trial store from the host store's defaults, rooted at the preset'scredentialslist and including any preserved-reference dependencies, then uploads both and runsbro show <bro>through the uploaded bundle — the one validation the host cannot make, and a smoke test of the bundle in the task's own image — thenride check-harness <name>, so the selected harness owns its runtime probe. The launcher validates the trial's harness against the uploaded bundle's manifest rather than against its own installation.run()is a singleride solo --unboxed --tree "$PWD" --runtime-bundle <bundle> …undersetsid, a join-only ride in the task's directory whose records land under the collected agent directory, reaped through a fresh root exec when harbor cancels the phase. The root revokesbro.placement=boxedand grantsbro.placement=join, so its summons may join the task tree and start no new party (bro/reference/permissions.md, "Start surfaces"). Harbor'smodel_namecarries<provider>/<rest of recipe text>, required by every preset. The trial writes a host configuration whosedefaultsselect its harness and recipe for roots and summons;ride solopasses neither--harnessnor--llm; the retry classification is the roster providers' declared failure signatures; the token counters harbor keeps are summed from the trial's trail storebro/benchmark/trial_store.py— the trail store a trial's run leaves under its collected agent directory: its path, whether a run recorded into it, and the token totals over its trailsbro/benchmark/harbor_environment.py—UnmountedDockerEnvironment, the environment the job config names: it keeps a trial's logs, artifacts and reward inside the task container for harbor to copy out, so a job runs wherever the docker daemon is reachable and leaves nothing on the docker hostbro/benchmark/trajectory.py— converts the projected local trail in each finished trial into Harbor's ATIF v1.7 models atagent/trajectory.json, including normalized counts for reporting and step/final metrics priced through caller-supplied provider tablesbro/benchmark/job.py(bro.benchmark.job) — runs Harbor on thecachedbundle against a known concrete job directory and adds the run's provenance to that raw result: the built bundle's manifest, and the presets record its config carries. A config Harbor would read lossily, or a docker-environment job on a host without the compose plugin, fails before Harbor runsbro/benchmark/retention.py(benchmark retain) — resolves one raw job from an artifact ref or local path. It derives the manifest's trial rows from Harbor records and local trail stores. It copies the snapshotted files under the flat date/job key with conditional checksummed puts and the manifest last. It also owns the reads of a retained run the later verbs share: the prefix shape, the manifest, its file list, and the verified downloadbro/benchmark/publication.py(benchmark publish) — verifies and downloads a retained run into scratch. It derives Harbor trajectories and result costs from the manifest's captured rates. It uploads with the scoped Harbor credential and appends an immutable publication recordbro/benchmark/query.py(benchmark query) — loads DuckDB's S3 extensions and credential-chain secret, then defines typedrunsandtrialsviews over the current-format retention markers for inline, file, or interactive SQLbro/benchmark/import_trails.py(benchmark import-trails) — downloads each trial's retained trail store from the manifest's file list and imports it whole, parents first, into the configured trails storeagents/,settings/,datasets/,tasks/— the presets a run is composed from, a JSON file each, read bybro.bench.presets(../bench/AGENTS.md); with the bundle, the whole of what a score depends on
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

