Every multi-agent pipeline today uses sender authority — Agent A decides what to pass Agent B. Agent B gets everything or nothing, regardless of its actual task.
Result: bloated context windows, PII leaking across boundaries, ballooning costs.
What CHP does
Inverts control. Agent B declares requirements in a ContextManifest. CHP scores and routes only what B actually needs.
Inverting to receiver-declared context is the right instinct — sender authority is exactly why B ends up with “everything or nothing.” One thing I’d add from having chased the same 40–70% number: selection and measurement are two different jobs, and the manifest is only as good as what you measure against it.
Two concrete bits of feedback on that:
Auto-inference needs a footprint baseline to be trustworthy. If CHP infers a manifest, you want to see what it would have passed vs. what it actually passed in tokens, per hop — otherwise a slightly-too-greedy manifest silently reintroduces the bloat you removed. When I profiled real repos/context trees the footprint was wildly lopsided — on one mid-sized codebase ~79% of the token surface lived in a single directory. That lopsidedness is why selection pays off, but it’s also why an auto-inferred manifest that grabs one wrong chunk can wipe out most of the savings. Measuring the per-chunk token cost first tells you which manifest decisions actually move the needle.
Prove the 40–70% per-run, not just in the benchmark. The claim will get pushback unless a user can reproduce it on their pipeline. Emitting a before/after token count per session (raw counts are fine for a relative delta) turns “40–70% in our tests” into “31% on your crew, here’s the number.” I’ve been doing this with a small local CLI — npx @wartzar-bee/tokenscope reads the session and shows what ate the context; and its scan --diff mode does a HEAD-vs-BASE token delta you can wire into CI (--max-delta N fails the build), so a manifest change that regresses context cost gets caught in the PR instead of the bill. Might be a clean way to give CHP users an objective “it worked” signal rather than asking them to trust the number.
For multi-node: the ledger per session_id is the right shape — I’d just make sure the token accounting sums across hops by a trace id, because per-hop alone undercounts whenever one agent does the expensive read. Nice work, will star the repo.
Full results JSON committed: benchmarks/llm_results.json
The key insight from the CrewAI team’s earlier feedback was right — the claim needed to be per-pipeline, reproducible. SessionTokenTracker now emits
your actual number at session close so you see it in your own pipeline, not just in our benchmark.
Would love to hear your numbers if you run it on a real crew.
Ran your committed benchmarks/llm_results.json through an outside-in re-sum (no rerun, no API spend — just
re-adding the per-agent rows) and it lands exactly on your headline: 5,768 → 2,136 prompt tokens = 63.0%, PII-in-prompt 12/12 → 0/12. Good sign when an in-framework tracker and a blind external re-count agree —
that’s the difference between “trust our number” and “here’s a number anyone can check.”
One thing the raw rows show that the summary table hides: the savings are not evenly spread — they
concentrate hard at the fan-in node. The orchestrator went 726 tok → 379 (biggest single drop), then
escalation 522 → 250 and summarizer 520 → 210. That’s the whole thesis in the data: sender-authority pipes
every upstream output into whoever aggregates, so a declare-what-you-need manifest cuts hardest exactly at
the aggregator. If you ever want a one-line “where did CHP actually save” view for users, ranking per-hop
delta surfaces that fan-in win automatically.
One honest caveat for anyone turning this into a dollar figure: prompt_tokens here is the logical count.
If the 12 agents share a system preamble and you’re on a provider with prefix-caching, the uncached-billed
delta can differ from 63% (cached prefix tokens bill cheaper), so the invoice reduction may not track the
logical one 1:1. Worth logging uncached-billed alongside logical so nobody’s surprised at reconciliation.
On the CI angle you picked up — that’s exactly the loop I’d close: npx @wartzar-bee/tokenscope scan --diff
gives a HEAD-vs-BASE per-hop token delta, and --max-delta N fails the build, so a manifest edit that
quietly re-greedies a hop gets caught in the PR instead of the bill. SessionTokenTracker emitting the
real per-pipeline number at session close is the right call — pairing that in-framework signal with the
external re-sum is the strongest form of the claim you can make. Happy to compare notes if you wire the
diff into the CHP repo’s own CI.