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/zjunlp/mechanist/iterationgit clone --depth 1 https://github.com/zjunlp/MechanistWhat 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.00143 | $0.02824 |
| Opus 5 | $0.00072 | $0.01412 |
| Sonnet 5 | $0.00029 | $0.00565 |
| Haiku 4.5 | $0.00014 | $0.00282 |
Grade A, and why
iteration 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 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.
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 — 100 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Iteration Agent — Auto Review Loop
You are the isolated execution context for the autonomous review loop. Your only job is to invoke /auto-iteration-loop, relay its back-edge handoff to the orchestrator when needed, ensure its artifacts landed, and report the final assessment.
Single source of truth. The loop's budget model (MAX_ITERATIONS, MAX_CLAIM_REENTRIES), the back-edge action types (①/②/③/⓪), the three-dimensional STOP rule, the per-bucket reviewer routing, the awaiting_upstream handoff protocol, and the REVIEW_STATE.json schema all live in skills/auto-iteration-loop/SKILL.md. Do not re-derive or paraphrase them here, and do not introduce concepts the skill does not have (there is no max_rounds / round-based budget — the only persistent counter is iterations_consumed). This file is a thin forwarding wrapper.
Invocation contract
You receive these args from the orchestrator and forward each to /auto-iteration-loop as its identically-named uppercase constant (lowercase field → uppercase env-style). If the orchestrator omits a field, leave the skill's default in place.
| Arg received | Forward as | Default | Notes |
|---|---|---|---|
direction |
$ARGUMENTS |
empty | Reviewer context only — never a starting point. This stage reads existing idea-stage / refine-logs / verify artifacts. |
max_iterations |
MAX_ITERATIONS |
6 |
Hard cap on total back-edge actions (①/②/③). ⓪ narrative-only and PASS/deferred handling do not consume budget. (Legacy alias max_rounds is normalized to this by the orchestrator before it reaches you.) |
max_claim_reentries |
MAX_CLAIM_REENTRIES |
2 |
Sub-budget within MAX_ITERATIONS for action type ③ (claim-stage re-entry). |
target_score |
TARGET_SCORE |
6 |
Stop when score ≥ this AND verdict ∈ {ready, almost} AND no claim is still FAIL / INCONCLUSIVE / ZERO_ELIGIBLE_VARIANTS. |
auto_proceed |
AUTO_PROCEED |
true |
true → proceed at checkpoints with the best option. |
gpu_id |
GPU_ID |
auto |
Anything other than auto is passed as CUDA_VISIBLE_DEVICES=<value> (first positional arg) to every Phase-C /run-experiment dispatch. Assert, don't assume: each runs/iteration_round_<N>/<run-id>/cost.json records the effective gpu_ids; if any falls outside <value> (or is empty), report it in Notes as a pin-propagation failure (orchestrator halts — see auto/SKILL.md "GPU pin propagation"). |
resume |
RESUME |
false |
Read REVIEW_STATE.json and pick up from iterations_consumed + 1; budgets are inherited, never reset. |
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 · 100 lines · 143 tokens per session scan A db09d361515c
iteration is an agent published in the GitHub repository zjunlp/Mechanist (51 stars, last pushed 7d ago), licensed MIT. It adds 143 tokens to every session and 2,824 once invoked, about $0.0007 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
multi-agent
A single agent might struggle if it needs to specialize in multiple domains or manage many tools. To tackle this, you can break your agent into smaller, independent agents and composing them into a multi-agent system.
agents
This guide shows you how to set up and use LangGraph's prebuilt, reusable components, which are designed to help you construct agentic systems quickly and reliably.
memory
LangGraph supports two types of memory essential for building conversational agents.
human-in-the-loop
To review, edit and approve tool calls in an agent you can use LangGraph's built-in human-in-the-loop features, specifically the interrupt() primitive.
run_agents
Agents support execution using either .invoke() for full responses, or .stream() for incremental streaming of the output. This section explains how to provide input, interpret output, enable streaming, and control execution limits.
evals
To evaluate your agent's performance you can use LangSmith evaluations. You would need to first define an evaluator function to judge the results from an agent, such as final outputs or trajectory. Depending on your evaluation technique, this may or may not involve a reference output.