Memtro as an AI gateway
Point the clients and code you already have at one base URL and key. Behind it: every model provider you hold keys for, a model chosen per request by how hard it is, fallbacks when one fails, a token allowance per team, and a log of what answered. And unlike a plain gateway, the organisation's memory and its connected systems ride along with every request.
What you point at it
Memtro serves three wire formats on one base URL, so the client decides nothing about the provider. Anything that speaks the OpenAI-compatible API uses https://platform.memtro.com/v1/chat/completions; the Codex CLI uses the Responses shape at the same base; Claude Code and the Anthropic SDKs use the Messages shape at https://platform.memtro.com/v1/messages. /v1/models lists what a key may ask for, and /v1/embeddings passes through to your own OpenAI or Google key.
Your keys, your providers
Memtro holds no models of its own. Add the keys you already pay for, as an organisation or as a person, and each becomes a provider behind the endpoint: Anthropic, OpenAI and Google, Meta, a Claude Code subscription or an OpenAI Codex sign-in, and any OpenAI-compatible endpoint under a label of your choosing. A provider can carry more than one key, and routing works through the whole list before it gives up on the provider: a key that is rate-limited, revoked or out of credit is a problem with the key, not the model, and is treated as one.
Routing by difficulty
Ask for the model auto and Memtro picks a rung on a ladder of models, cheapest to strongest, by how hard the latest message is. Heuristics score the request from its shape; what they cannot settle gets one short classification call, cached for fifteen minutes. The level, one to five, maps onto the ladder, each rung has a secondary and a tertiary behind it, and agent-mode requests never route below level three. A second ladder answers software tasks. Ladders are set for the organisation, over which a team's choices and a person's lie cell by cell, inheriting whatever they leave empty. Every response carries the decision in its memtro.routing field.
- auto
- The configured ladder, routed by difficulty.
- auto/anthropic
- The same, within one provider.
- memtro
- The organisation's default: auto unless an administrator fixed one model.
- provider/model
- A specific model, through your key for that provider, where the organisation allows it.
Full mechanics, including decision providers that answer difficulty in milliseconds, under Model routing.
A token allowance for every choice
Cost control caps the same cells routing fills: five levels down, three choices across, in tokens a month, for the organisation and for each team. When a choice runs out the one behind it answers, so a budget reached on the twentieth finishes the month on a cheaper model instead of stopping work. Only when a level's three choices are all capped and all spent is a request refused, with HTTP 429 and a message naming the level, the month and where the allowance lives. Every routed request is credited to each scope that could cap it, so the figure beside every box is the real one.
Why it needs the next section, and the two honest limits, under Cost control.
Model choice, locked by default
An allowance reaches a request that climbed the ladder, and a request that names its own model never climbs. So every organisation starts with model choice locked: requests may ask for auto, a provider's auto, or memtro, and a named model is answered as memtro instead, with the log keeping what was asked. The model listing offers only what may be asked for, so a client that discovers models through it offers nothing else. An administrator opens the lock on the Routing page, after a dialog that says what it costs.
Who asked, what answered, what it cost
Every request is logged with who made it, which model actually answered after routing, and the input and output tokens the provider reported. Usage is shown by day, by user, by team and by model, exportable as CSV, and the same figures sit beside the allowances that cap them. Requests from the Chat page, the API, scheduled jobs, the MCP server and client tools all count under the person whose key or session made them. Admins see the whole organisation; everyone else sees their own.
Keys per person, or per organisation
A personal key carries its owner's memory, connections and permissions, so what a client may read and do is decided by who holds the key. An organisation key runs as the organisation. Both are issued and revoked in the dashboard, and neither exposes the provider keys behind them.
What a plain gateway does not do
A gateway moves requests. Memtro also answers them with the company behind it: relevant memory is retrieved into every request, the model can call 144 connected systems through tools that read by default and act where an action is granted by name, agent mode runs a multi-step investigation when a question needs one, and what was learned is remembered for the next request. Turn any of that off per request with the memtro field and it is a gateway again.
See agent memory for companies and the connectors.
Questions
- Does the gateway add latency?
- One extra hop, and for a routed request a decision about difficulty: heuristics settle the easy cases without any call, and the rest get one short classification call on a cheap model whose answer is cached for fifteen minutes. A request that names a model skips the decision.
- Which providers can sit behind it?
- Any provider you hold a key for: Anthropic, OpenAI and Google by API key, Meta through its API, a Claude Code subscription or an OpenAI Codex sign-in, and any OpenAI-compatible endpoint you register under a label. A provider can hold several keys, which are tried in turn before a request moves down the ladder.
- Can I still ask for a specific model?
- Yes, with a provider/model id, unless the organisation has left model choice locked to auto, which it is by default because token allowances only reach requests that were routed. An administrator opens it on the Routing page and is warned what that costs.
- Does it price requests in money?
- No. Allowances and usage are in tokens, which Memtro can count exactly from the provider's own usage report. It does not know what your provider charges you per token and will not invent a figure.