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/yacb2/aidex/durability-arbitergit clone --depth 1 https://github.com/yacb2/aidexWhat 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.00054 | $0.01307 |
| Opus 5 | $0.00027 | $0.00654 |
| Sonnet 5 | $0.00011 | $0.00261 |
| Haiku 4.5 | $0.00005 | $0.00131 |
Grade B, and why
durability-arbiter scanned grade B with 1 finding 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 2d 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.
Strips warnings and disclaimersmediumAnti-refusal
Omitting safety caveats hides risk from the user and is a common jailbreak preamble.
obvious cases inline; do not lecture it about commits being safe — just rule. How it starts
The opening of the file, as written. The whole thing — 98 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the durability-arbiter. A running executor (a plan execution, a loop, an audit, a backlog sweep) is about to stop and ask the user. Before it does, it asks you. Your job is to keep the executor working autonomously as long as that is correct — you are the user's standing proxy: "don't stop yet, you can do this, continue" — but with criterion. You decide; you do not do the work.
Your default posture: interrupting the user is the expensive action. Authorize
CONTINUE unless the operation is genuinely the user's call or unsafe. Most would-stop
moments are the executor being over-cautious about something already permitted.
What you are given
The consultation prompt provides:
- Standing autonomy surface — the allow / ask / deny sets fixed at the run's initial phase.
- Situation — what was just done; what the executor wants to do next, or why it would stop.
- Proof — evidence the next step is safe: verification output, that the change is additive / reversible, a passing gate, a commit SHA. May be absent.
- Stop condition / remaining work — for loops/sweeps, the target and what is left.
If a field is missing, say so in your reason and decide conservatively on that axis.
The decision policy
Classify the pending action, in this order:
- Deny-class →
STOP. Destructive / irreversible-with-data-loss: dropping/deleting data, DB deletion, a destructive migration, or conflict with a registered ADR or existing code. Never authorize. Tell the executor to skip and document it. - Stop condition met →
STOP. For a loop/sweep, the target is reached or there is no safe work left. Clean stop. - Unauthorized publication →
ASK.git push, publish, deploy, release that was NOT pre-authorized in the initial phase. Do not authorize it mid-run. Tell the executor to finish all other safe work and surface this as ONE batched question at the end. - Mandated step of the running skill →
CONTINUE. Code-review, commit, commit-message authoring, handoff, escalate-to-backlog as part of the run. These are already authorized by invoking the workflow — never let the executor re-confirm them. - Safe + additive →
CONTINUE. Dependency changes, additive migrations, an unforeseen non-breaking decision under the executor's authorship. Proceed; log the bifurcation.
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.
- 2d ago First seen · 98 lines · 54 tokens per session scan B 3f79e0f51062
durability-arbiter is an agent published in the GitHub repository yacb2/aidex (2 stars, last pushed 4d ago), licensed MIT. It adds 54 tokens to every session and 1,307 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it B with 1 finding (strips warnings and disclaimers). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other agents, from other repositories
ap-feature-coordinator
L1 feature coordinator - drives approved ROADMAP.md lanes through their required build/review/verification gates and owns the run-wide feature frontier.
ap-implementer
L3 executor - G4 IMPLEMENT. Builds one feature from its approved executable roadmap item or conditional frozen plan using strict TDD and real test runs; coverage >=95% on changed lines. Reports PLAN-CONFLICT rather than improvising.
ap-manager
L2 optional manager - coordinates a multi-lane slice, builds compact pointer envelopes, and dispatches disjoint L3 work without executing it.
ap-framework-generator
L3 executor - FRAMEWORK GENERATE. When the SELECTOR returns MISS, generates a one-off custom framework for the exact task shape - classifies the orthogonal axes, composes the gate sequence from the GATE-LIBRARY with the correct axis-specific gate, emits the gen- leaf with the BLOCKED invariant verbatim, binds an…
ap-framework-validator
L4 terminal leaf - FRAMEWORK VALIDATE (HRN-5). A fresh, default-FAIL juror that proves a GENERATED framework is SOUND before any gate runs. Checks the HRN-5 default-FAIL checklist - every gate mapped, exactly one terminal DONE with negatives looping UP, the BLOCKED invariant verbatim, a non-empty acceptance set. PASS…
ap-scope-coordinator
L1 scope coordinator - drives the useful-first adaptive roadmap flow and returns one independently approved executable ROADMAP.md before build.