Show the model
five tools, not five hundred.
acri sits between your application and whichever model you call. Each task, it reads your full tool corpus once and hands over only the few tools that call actually needs — then never touches that prompt prefix again.
Every schema you add competes for the same attention.
Anthropic's own tool-use documentation names 30–50 tools as the point where selection accuracy starts to visibly degrade. Past that, the model isn't reading fewer words — it's choosing between more things that look alike.
Cutting tokens can cost more, not less.
Providers price a cached prompt prefix at roughly a tenth of the uncached rate. Re-resolving tools every turn rewrites that prefix — trading a cache discount for a smaller prompt is only a real saving once the cut is steep enough.
Re-resolve every turn
Cache never hits — the prefix changes every time.
Resolve once, append
One full-price write, then ~10% cost after — illustrative, from the r < 1/10 argument below.
Where r is the fraction of the tool block kept and C·p is the full uncached cost. Below a ~10× cut, rewriting a cached prefix is a net regression — the reason acri resolves once per task and appends, rather than re-searching every turn.
Watch the resolver think.
Studio is acri's own dashboard — two read-only views over the same ledger. No separate telemetry, no data leaving the machine.
servers, models, and every tool seen in ledger history
What's actually measured — and what isn't.
Every number below comes from a script in assay/. Recall degrades
as the corpus grows; we report that rather than tune it away.
| k | recall@k, 100 tools | recall@k, 500 tools |
|---|---|---|
| 1 | 74% | 60% |
| 3 | 90% | 82% |
| 5 | 100% | 92% |
| 10 | 100% | 98% |
Single model (gemini-2.5-flash), one synthetic 500-tool corpus, n=50–52 queries. No embeddings baseline yet, no significance test on the 8-point accuracy gap. Full write-up: the paper.