Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add agents/uipath/coder_eval/harness_paritygit clone --depth 1 https://github.com/UiPath/coder_evalWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00000 | $0.02458 |
| Opus 5 | $0.00000 | $0.01229 |
| Sonnet 5 | $0.00000 | $0.00492 |
| Haiku 4.5 | $0.00000 | $0.00246 |
Grade A, and why
HARNESS_PARITY scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 180 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Run-Limit Parity
One task file, run on any harness, must be the same task. run_limits.max_turns
was the field that broke that promise hardest: Claude Code enforced it, and Codex and
Antigravity accepted it and never read it, so max_turns: 6 ran capped on one
backend and unbounded on the other two.
This page is the contract for what each run limit means per harness, plus the shared
agent fields whose meaning still differs across them.
The table
| Limit | claude-code | codex | antigravity | opencode |
|---|---|---|---|---|
run_limits.max_turns |
native SDK cap (agent-loop turns) | visible-turn cap (resolved tool calls) | visible-turn cap (resolved tool calls) | native step cap (the CLI's own agent-loop steps) |
run_limits.turn_timeout |
watchdog, SIGKILL on the CLI subprocess | watchdog + cooperative interrupt | watchdog, plus an earlier internal poll deadline at 80% of it (see below) | deadline enforced in-loop and on the final reap; SIGTERM→SIGKILL on the CLI's whole process group |
run_limits.task_timeout |
orchestrator-level, agent-agnostic | orchestrator-level, agent-agnostic | orchestrator-level, agent-agnostic | orchestrator-level, agent-agnostic |
run_limits.stop_early |
cooperative should_stop |
cooperative should_stop |
cooperative should_stop |
cooperative should_stop (event granularity) |
max_turns counts visible turns on Codex and Antigravity
A "visible turn" is one entry in the run's timeline: one resolved tool call. It is
the unit reports_stats.visible_turn_count reports and the unit that lands in
TurnRecord.commands. Both backends count it live off the shared
EventCollector.visible_turn_count, so one max_turns value means one thing on
both.
They need their own counter because a native one would be meaningless: Codex and
Antigravity each deliver exactly one SDK turn per communicate() call, so an
SDK-level cap would clamp at 1 no matter what the task asked for.
The cap is enforced on the same loop boundary as the cooperative early stop: the
step or notification that reaches the cap is processed whole, and the next one is
never pulled. The in-flight turn is then cancelled server-side (best effort) so
the cap actually stops spend. A run cut this way finalizes cleanly as
max_turns_exhausted — it is not a crash, and it is not retried.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 180 lines · 0 tokens per session scan A 1fb0a5cab85f
HARNESS_PARITY is an agent published in the GitHub repository UiPath/coder_eval (119 stars, last pushed 5d ago), licensed Apache-2.0. It costs nothing until one of its globs matches a file; then it loads 2,458 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
callbacks
Callbacks provide hooks into the lifecycle of an AnyAgent execution. Using callbacks, you can monitor, control, and extend agent behavior without modifying the core underlying agent logic.
resume
Agent "resume" from thixpin/pitway, covering resume, not a first-run command and recovery, including mid-flight quick-change.
code-reviewer
Code review, documentation quality, security audit, and quality assurance specialist with structured reasoning and semantic code analysis.
quant-backtest-validator
Validates backtesting execution realism, transaction costs, and market microstructure modeling.
codemeridian-architecture-review
Specialist reviewer for CodeMeridian-assisted architecture checks, impact analysis, tests, async, logging, nullability, and analyzer risks.
governance-reviewer
Use this agent when a major task has been completed and you want to assess governance state before continuing. Examples: Context: An agent finished a feature implementation. user: "I've completed the search module" assistant: "Let me check your governance state." After significant work, dispatch the…