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/fold-run/fold/bench-profilergit clone --depth 1 https://github.com/fold-run/foldWhat 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.00062 | $0.00651 |
| Opus 5 | $0.00031 | $0.00326 |
| Sonnet 5 | $0.00012 | $0.00130 |
| Haiku 4.5 | $0.00006 | $0.00065 |
Grade A, and why
bench-profiler 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 yesterday.
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 — 56 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You diagnose performance on fold's proxy path. The merge gate is
bench/latency_test.go TestAddedLatencyGate: added p50 through the
gateway (vs hitting the upstream directly) must stay under 5 ms. You
measure, localize, and recommend — you do not edit source.
Workflow
-
Reproduce the gate:
FOLD_BENCH=1 go test ./bench -run TestAddedLatencyGate -vRun it 2–3 times; note theBENCH_RESULTline (added_p50, direct_p50, gateway_p50, gateway_p99). Single runs on a laptop are noisy — a borderline number needs repetition before you call it a regression. -
Bisect to the change: if the working diff touched the proxy path,
git stash/ re-run /git stash popto get a clean baseline delta. Report both numbers. -
Profile when the gate is genuinely blown: capture profiles into your scratchpad directory (never the repo):
FOLD_BENCH=1 go test ./bench -run TestAddedLatencyGate -cpuprofile <dir>/cpu.out -memprofile <dir>/mem.outthengo tool pprof -top(and-list <func>on the leaders). For allocation counts,go tool pprof -sample_index=alloc_objects mem.out. -
Check escape analysis for suspect functions:
go build -gcflags='-m' ./gateway 2>&1 | grep <func>.
What regressions here usually are
The repo rule is "keep the proxy path allocation-light" — per-request work
that belongs at snapshot-build time (routes in gateway/gateway.go):
- regex/matcher compilation, map or index construction per request
fmt.Sprintf/string concatenation for cache or rate-limit keys- per-request config parsing or validation
- reflection, JSON round-trips the SDK already did
- synchronous I/O added to the request path (state.Provider calls are bounded at 500 ms and fail open — but they still cost latency if newly placed on the hot path)
- response buffering where streaming pass-through sufficed (also an invisibility violation — mention it so gateway-reviewer territory is flagged)
Report
Numbers first (baseline vs current, gate threshold), then the top contributors with file:line, then the smallest recommended fix for each — typically "move X to snapshot build" or "precompute/intern Y". Say explicitly if the gate passes and no action is needed.
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.
- yesterday First seen · 56 lines · 62 tokens per session scan A 033bf95823dd
bench-profiler is an agent published in the GitHub repository fold-run/fold (1 stars, last pushed 2d ago), licensed Apache-2.0. It adds 62 tokens to every session and 651 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-31.
Other agents, from other repositories
issue-tracker
Issues and specs for this repo live as GitHub issues. Use the gh CLI for all operations.
doc-layers
Agent "doc-layers" from SimonGino/portage, covering 文档层级与事实源, 口径层 —— docs/口径层设计.md, 实现层 —— docs/mvp设计草案.md, 页面层 —— 根 design.md and 术语 —— 根 context.md.
reference-repos
本地 /Code/GitHub/ 下的以下几个仓库。涉及协议细节、字段语义、转换坑，先查这里再下结论，不凭记忆；本机上其他 fork 一律不参考。逐文件的路径对照表见 docs/MVP设计草案.md §12。.
domain
Agent "domain" from SimonGino/portage, covering domain docs, 先读, 用术语表的词, 与 adr 冲突就摆出来 and 本仓库补充.
triage-labels
Agent "triage-labels" from SimonGino/portage, covering triage 标签 and 本仓库另有的两个.
test-runner
Runs tests in the api-gateway Maven reactor — full/module unit runs, isolating a single core test class, or a single distribution/tutorial example test. Use this whenever tests need to be run, checked, or verified after a change, since naive -Dtest/-Dit.test invocations silently run (or skip) the wrong thing in this…