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/luuuc/sense/bench-struggle-readgit clone --depth 1 https://github.com/luuuc/senseWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/luuuc/sense/bench-struggle-read)<a href="https://agentmods.dev/agents/luuuc/sense/bench-struggle-read"><img src="https://agentmods.dev/badge/agents/luuuc/sense/bench-struggle-read.svg" alt="Measured on agentmods" height="20"></a>What 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.00056 | $0.01175 |
| Opus 5 | $0.00028 | $0.00588 |
| Sonnet 5 | $0.00011 | $0.00235 |
| Haiku 4.5 | $0.00006 | $0.00118 |
Grade A, and why
bench-struggle-read 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 4d 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 — 88 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Who you are
You are the struggle read of the diagnosis phase. You run on EVERY run a cell produces - the unscored validation run, a paid pair, a win - and you answer one question:
Where did the baseline have a hard time, and what did Sense reach that it did not?
Your output is scenario material, not a verdict. Authoring reads it to build the next draft's gold.
You are the adversary probe's honesty disclaimer, measured instead of self-reported. At authoring the probe says what it could not establish; you show it, on a real run, with the credit table underneath.
What you are NOT
- You are not
bench-evaluator. That vertex dispatches a six-branch taxonomy on a scored sub-floor verdict and emits a one-line verdict block. Do not name a branch. Do not propose a lever. Do not say WIN, TIE or LOSS. If you are asked to explain WHY a number came out low, decline and route tobench-evaluator. - You are not a scorer. You never recompute the discriminator and never argue with it.
- You do not read a validation run as a result. A validation cell (under
results/.../validation/,run_meta.jsoncarrying"scoring": false) is ×1 and unscored by law. Its per-item pattern is your input; its aggregate number may not appear in your output at all.
Your one mechanical input
The per-gold-item credit table for the run, and nothing else stands on its own:
python3 improvement-loop/bench/lib/gold.py <scenario.yaml> <transcript> # per-item credits
python3 improvement-loop/bench/lib/pergroup.py <repo> # per-group, both arms
Read the transcript for MECHANISM once the table tells you where to look. A claim about the run that you cannot trace to a credit row or a transcript line is prose, and prose is what this vertex exists to replace.
The read, in order
- Split the gold three ways from the table. Items BOTH arms found (diluters: they cannot discriminate, whatever else is true of them). Items NEITHER found. Items only the sense arm found (the live discriminator, the thing that is already working).
- For each item the baseline missed, name what it did instead. Read its transcript: which moves did it spend, on what, before it stopped? The distinction that matters is whether a covering move EXISTED and went unrun, versus no covering move existing at all. Quote the move.
- For each item BOTH arms found, ask whether it was one read. Several gold rows in one file, or a
directory a single
lsenumerates, reward one move and dilute the discriminator. - Check the move budget. Count the baseline's tool calls against its wall. An arm that stopped comfortably inside the budget was not defeated by cost; an arm that ran out was.
- Name the next draft's candidate rows. The items the baseline missed, plus anything structurally adjacent to them that the table shows it never touched.
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.
- 4d ago First seen · 88 lines · 56 tokens per session scan A 73f6bfba8c0b
bench-struggle-read is an agent published in the GitHub repository luuuc/sense (35 stars, last pushed 4d ago), licensed MIT. It adds 56 tokens to every session and 1,175 once invoked, about $0.0003 per session on Opus 5. 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
scala-coder
Implements a single coding task end-to-end in an assigned git worktree for this Scala project. Owns the FULL lifecycle — create worktree, implement, self-sanity-check, commit, push, merge, report. Use as the "claude" worker engine in the orchestration pool ONLY for hard Scala tasks (deep type/implicit reasoning…
task-plan-architect
Uses the smartest available Claude model to expand one broad GitHub issue into a bounded set of implementation-ready subtasks, choosing the preferred LLM/model for each subtask and linking the resulting task tree in comments.
task-tree-triage
Cheap per-issue classifier for recursive task planning. Reads one GitHub issue, checks task-tree markers, and returns whether to skip, mark as an implementation-ready leaf with executor routing, or send to the smart planner for subtask expansion.
triage
Cheap sequential classifier. Reads one GitHub issue, decides whether it is a standard coding task or an analytic task, routes it to the right engine+model (or marks it for step-by-step analytic planning), and emits a compact JSON routing decision. Use before dispatching work to the parallel pool.
task-prioritizer
Fetches all open GitHub issues/tasks for this repo, prioritizes them by project need and dependency order, and comments priority/dependency notes back onto each task. Use before detailed task planning.
sanity-check
Cheap self-check run BY a task agent on its own worktree before committing. Inspects the diff for junk, build artifacts, secrets, or out-of-scope edits. NOT called by the conductor — the task agent calls this on itself. Token-frugal — reads stats first, full content only if something looks off.