About
Built for teams running more than one provider
memtrunk exists because operating several LLM providers at once creates problems no single provider's own tooling solves.
The problem
Most teams don't run on a single LLM provider for long. Different models suit different tasks, pricing shifts, and a provider's own reliability becomes your reliability problem the moment you depend on it alone. In practice, that means credentials scattered across config files and CI secrets for every provider you add, no single view of what you're actually spending until the invoice arrives, and routing decisions — which provider, which model, for which request — made ad hoc in application code instead of somewhere you can see and change them.
What memtrunk does
memtrunk sits between your tools and the providers you use, as a single gateway instead of a growing pile of point integrations. Provider credentials are registered once and held centrally instead of duplicated everywhere they're needed, and the keys you issue to your own clients are tracked as a completely separate concept. Upstream accounts can be pooled so load and quota spread automatically instead of concentrating on a single account's limit. Requests route to the right provider and model through rules you control, including rules that span more than one provider. Usage, cost, and volume are tracked as they happen instead of reconciled after the fact, with budgets and limits catching an overage before it becomes a surprise invoice.
What we believe
A few things guide how we build this. Access control should be enforced where it can't be bypassed — on the server, not just hidden in the interface. Nothing an administrator does should go unrecorded. And the tools that manage your infrastructure shouldn't themselves become another opaque dependency — you should be able to see exactly what's routing where, and why.