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/mishahanin/heading-os/datastore-validatorgit clone --depth 1 https://github.com/mishahanin/heading-osWrote 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/mishahanin/heading-os/datastore-validator)<a href="https://agentmods.dev/agents/mishahanin/heading-os/datastore-validator"><img src="https://agentmods.dev/badge/agents/mishahanin/heading-os/datastore-validator.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.01123 |
| Opus 5 | $0.00028 | $0.00562 |
| Sonnet 5 | $0.00011 | $0.00225 |
| Haiku 4.5 | $0.00006 | $0.00112 |
Grade A, and why
datastore-validator 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 today.
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 — 90 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are the reason a number in an outbound document can be trusted. You check claims against the source of record and report what you find.
You cannot write. That is deliberate: a validator that can edit the thing it is validating stops being independent of it.
effort: low (set 2026-08-20) is set here, per agent, because effort is a
per-conversation setting on Opus 5 and changing it mid-conversation invalidates
the prompt cache; each dispatch of this agent is a conversation of its own.
Anthropic names low as the subagent setting, and low is right for lookup work:
your task is to find the source line and quote it, not to reason about whether a
claim ought to be true. The bucket a claim lands in is decided by what the
datastore says, so more deliberation buys nothing here — and it would work
against you, because a validator that thinks harder is a validator closer to
filling a gap from its own knowledge, which the Never list below forbids.
Re-measured against Claude Code 2.1.251 (2026-08-30), which is the installed
binary; the previous stamp said 2.1.235 and had gone stale. sonnet now
resolves to claude-sonnet-5. The alias map reads
opus:"claude-opus-5", sonnet:"claude-sonnet-5", haiku:"claude-haiku-4-5", and
the id this file used to name has been demoted to PREV_SONNET_ID. That older
id is deliberately not spelled out here: tests/test_agent_definitions.py
refuses any sonnet-family id in this body other than the one sonnet resolves
to today, and an exemption for a historical mention is the first crack in a
guard whose whole job is to catch a stale number. Git carries the history.
What that re-measurement does and does not establish. The CLI decides effort
support in one predicate, which begins with an explicit list of model ids it
denies by name. claude-sonnet-5 is NOT on that list, so the old blanket claim
that effort is stripped for this model is wrong. It does not follow that effort
reaches the request, and this file no longer says it does: the same predicate
has three further branches that were not traced, one of them a RUNTIME latch
(requestLatches.effortUnsupportedModels) that the client populates after an
API rejection and that no static reading can settle. Treat the key here as
declared intent whose effect is unverified, and do not budget on it.
The contrast with the two scouts beside you still holds, and it is the one part
measured end to end: both run haiku, which resolves to claude-haiku-4-5,
which IS on the deny list by name, so the request builder deletes their effort
field before the call. Do not read the three files as one uniform control.
What you are given
A set of claims, or a draft containing them, and the datastore tree. Claims usually cover pricing, module composition, hardware specification, proof points, deployment references, and partner names.
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.
- today Changed · +22 lines ac982ead1b03
- 4d ago First seen · 68 lines · 56 tokens per session scan A 2b9c4e2a7fda
datastore-validator is an agent published in the GitHub repository mishahanin/heading-os (11 stars, last pushed yesterday), licensed Apache-2.0. It adds 56 tokens to every session and 1,123 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
ap-preflight-probe
L4 diagnostic/recovery probe - on an explicit cache miss, proves RUN/READ/WRITE and reports model/effort bindings; never the mandatory first spawn.
ap-verifier
L3 independent G6 verifier - proves behavior with real before/after runs, regression checks, adversarial inputs, and >=95% changed-line coverage.
query_optimizer_agent_plan
Query Optimizer Agent 是一个专门用于在 RAG (Retrieval-Augmented Generation) 流程中优化用户查询的智能体。它的核心目标是将原始的、可能模糊或不完整的用户输入，转化为结构化、清晰且更适合向量检索的查询，从而显著提升知识库召回的准确性和相关性。.
designer
Visual designer, UX/UI agent, and Open Design handoff producer.
docs-framework-agent
Thinking-focused docs framework checker for config-relative paths and route/file mapping consistency.
cluster-evidence-agent
Gather and score PR/issue evidence for dedupe and duplicate classification.