Every system, one console

Every upstream provider you rely on gets registered once, with its credentials held centrally instead of scattered across client configs and CI secrets. From there, you issue scoped caller keys to the clients and tools that call through memtrunk — kept as a completely distinct concept from the provider credentials they route to, so what you're protecting and what you hand out never get confused.

• Provider keys and caller keys are tracked as distinct concepts, so upstream credentials never get confused with what you issue to clients.
• A newly created caller key is shown once in full, then only ever displayed hashed and prefixed from then on.
• Per-provider detail screens let you drill into the configuration behind any single provider you've registered.
• Built provider-agnostic from the start — the same engine speaks Claude, OpenAI (including Codex), and Azure OpenAI, each with full test coverage and its own console setup screen. Claude is what has carried real, sustained production traffic in this deployment and works reliably there; the others are built, tested, and configurable today, without yet carrying the same production mileage.

Instead of routing every request through a single upstream account and hitting its rate or quota ceiling, memtrunk draws from a pool of accounts per provider. Register the provider accounts you have — including team subscription plans, not just metered API keys — and memtrunk spreads load and quota across the pool automatically as usage grows. Management access to any given account follows a real ownership rule rather than a blanket admin-only gate.

• Pool the provider accounts you already have — including team subscription plans, not only metered API keys — and memtrunk spreads load across them.
• Load and quota spread automatically across the pool instead of concentrating on one account's limit.
• An account's own owner or an admin-tier role can manage it directly — a read-only auditor never gets mutation rights, even over an account it happens to own.

Routing rules decide which provider and model actually serves each request, with no change to client code required. Rules can span more than one upstream provider through cross-provider routing, reaching beyond a single vendor's own model lineup.

• Standard routing rules pick the provider and model for each request.
• Cross-provider routing rules span multiple upstream providers.
• A live playground lets you verify a routing change before it takes effect.
• A routing-decisions log shows which credential actually handled each recent request — transparency into what already happened, not just what a prospective change would do.

Usage dashboards break down tokens, cost, and volume as requests happen, filterable by org, key, or provider. Budgets and rate limits enforce spend ceilings before an overage becomes a surprise invoice, and the rates behind every number stay fully accounted for — each one is either a system default or an admin override, and each can be visible, hidden, or revealed again after being hidden.

• Real-time usage breakdowns by tokens, cost, and volume — filterable by org, key, or provider.
• Spend ceilings cascade across key, user, team, and pool-wide limits, enforced at request time rather than reported after the fact. Two independent background systems — one watching threshold crossings, one watching for statistical spend anomalies — forecast burn rate and an estimated exhaustion date, and route alerts to an in-app notification center plus a webhook or email when configured.
• Every rate carries its own visibility state — visible, hidden, or revealed after being hidden, with a distinct state for stale legacy defaults — so you control exactly what shows up in cost views.

Cost and usage tell you what a session spent; this is what it actually did. Every tool call carries its own agent and sub-agent identity, session, and project, and a failure is classified into one of many specific error types instead of a single generic flag — enough to attribute a repeated failure to the exact agent causing it, not just the tool involved. Tool arguments and prompt text are never captured or stored, by design.

• Every tool call and failure is attributed to the specific agent or sub-agent that made it, not just aggregated by tool.
• A detailed error taxonomy — permission denied, timeout, file not found, and more — replaces a single generic error flag.
• Tool arguments and prompt text are never captured or stored, by design — only identity, classification, and counts.

Memory isn't tied to any one device — it's held centrally in your own deployment, carrying over from session to session and even as memtrunk pools and routes your requests across upstream providers. That's a distinct layer from how the index itself gets built: embedding and reranking run entirely on-device, so nothing you write is ever sent to a third-party embedding API — the resulting memory records are what persist centrally, ready the next time you sign in from anywhere. Capture and sharing are both controlled per project, not just with one global switch, and recall itself runs server-side with zero client configuration and a fixed ~2,000-token injection cap no matter how much history has built up.

• Per-project control over capture and sharing — turn memory collection on or off for exactly the projects you want, and opt a project into a shared pool with same-org teammates who opt in too — never opened to everyone.
• Not tied to whichever upstream account or provider a request ends up pooled or routed to — capture, recall, and injection all run before that routing decision is even made.
• The index is built on-device — zero LLM calls, zero captured content ever leaves your deployment — but the memory records it produces persist centrally, carrying over across sessions and devices rather than staying on one machine.
• Validated against two independent public memory benchmarks with a published, frozen-judge methodology — including the experiments that were killed, not just the ones that shipped.

Every administrative action in memtrunk lands in an immutable audit trail — nothing an admin does goes unrecorded. Access to admin screens and mutations is enforced by role on the server, not just hidden behind a UI check, so a role can be trusted to actually mean what it says.

• An immutable audit trail records every administrative action.
• Role checks are enforced server-side — a hidden button is never the only thing standing between a user and a mutation.
• A dedicated auditor role reaches every admin screen, without the ability to change anything.
• A master admin can view the console as another user for support or debugging — fully audited, unable to target another master admin or a disabled account, and always stoppable by the real admin's own identity even while active.

Users, keys, and quotas are grouped by organization and team, so a deployment serving many teams stays organized without manual bookkeeping. Access scales cleanly from a single administrator up to a full multi-team organization, with roles for ordinary members, org-scoped admins, and a global admin tier above them.

• Group users, keys, and quotas by organization and team.
• Role tiers scale from an ordinary member up through org admin to master admin.