Policy
Hard rules remove edges before anything is scored — an agent never sees a route it may not take.
“Customer email never goes to a cloud model.” “The coding agent can't read the finance folder.”
data · Policy · Capacity · Evidence
The right model and the right data for every agent task.
datapce gives engineers who run fleets of AI agents one control plane that routes every task to the right model and the right data from policy, capacity and measured evidence — and shows each decision in the tool where the agent works.
- Policy removes routes that must never happen
- Capacity picks among what is left, given load right now
- Evidence learns which choice actually works — advise first, enforce once measured
Policy → Capacity → Evidence, running
A live map of one team's agents: the data they read on the left, the models they call on the right. Watch the three layers decide every run.
Policy: each agent asks for data and for a model. Rules remove the edges it may never use (red, dashed, numbered) before anything is scored.
passed / runs, per agent and model
labeled runs—
decisions—
warming up (< 30 runs)promising — advise onlyproven — enforced ✓below 75% — never advised✕ removed by policy
Every decision, in the tool where the agent works
A Claude Code plugin shows a status band above the prompt and annotates each subagent dispatch with what the evidence on this machine says. Advice first; it enforces only once a cell has enough labeled outcomes.
⏺ Agent("triage flaky integration tests", model: opus) ⎿ datapce ▲ evidence: sonnet passed 27/30 of these here — promising, lower bound 0.74 < 0.75 — advise only ⏺ Agent("summarize nightly loop failures", model: haiku) ⎿ datapce warm-up 9/30 — no advice yet ⏺ Agent × 6 ("migrate each service to the new SDK") ⎿ datapce ●AMBER opus 5h window 62%, burning 3.1× — fan-out capped at 3, rest queued datapce ●AMBER 5h:62% ctx ▇▇▇▇▇░░░ 61% $4.12/10 routes 7 (local 4 ✓3 ↑1) ▲2 conf 86% enforce:2/8 >
in development Claude Code plugin — design mock, numbers illustrative. Running today: the backend it builds on — local model lanes, request telemetry and the pressure gate.
Three layers, always in this order
Capacity
Among the allowed routes, pick by what the system can carry now: rate limits, budgets, local slots.
“Opus is at 62% of its 5-hour limit and climbing — cap this fan-out at 3 and queue the rest.”
Evidence
Learn which choice actually works from labeled outcomes on your machine — advise first, enforce once measured.
“Haiku passed 58 of 60 log summaries here. Lower bound 0.89 — route them to Haiku.”
What is measured so far — including the gaps
Every row carries an evidence label, a date and its source. A gap is a row too, not a footnote.
| Layer | Claim | Label | Date | Source |
|---|---|---|---|---|
| Capacity | Rate-limit responses seen in 7 days of Claude Code traffic: 478 HTTP 429s — logged as non-errors until telemetry v7, which now keeps the upstream rate-limit headers | PARTIAL | 2026-10-02 | apex-router telemetry readout |
| Evidence | Request telemetry over 7 days of Claude Code traffic (13.6k requests): prompt-cache hit rate 0.97, 0 cache busts | PASS | 2026-10-02 | apex-router telemetry readout |
| Evidence | Learned routing for Claude Code subagents: 1 labeled outcome on record, so routing stays advise-only — the plugin is what produces the labels | BLOCKED | 2026-10-03 | apex-router route log |
| All | Backend test suite (proxy, routing, local lanes, pressure gate): 1716 passed, 4 skipped | PASS | 2026-10-03 | pytest on apex-router main |
Early adopters
For engineers who run agents at scale: parallel fan-outs, nightly loops, agents working over real repos and real data — and who pay for it and see the regressions.
- Early builds of the Claude Code plugin
- A say in what gets enforced first
- Your machine's evidence stays on your machine