Memtro vs Portkey
A gateway built around routing configs and deep observability, versus one built around company memory, connectors and routing by difficulty.
This comparison describes Portkey as we understand it at the time of writing from its public documentation. Products change; check the current details before deciding.
Portkey is an AI gateway with an observability suite attached. Its gateway is a universal API over many providers, driven by configs: fallbacks between providers and models, conditional routing on custom checks, automatic retries, load balancing across API keys, simple and semantic caching, and guardrails. Usage limits can be set in cost or tokens and rate limits per minute, hour or day. Every request and response is logged, traced and counted into analytics dashboards with custom metadata and feedback, all OpenTelemetry-compliant. The gateway itself is open source — npx @portkey-ai/gateway runs it — and can be self-hosted and connected back to Portkey.
Memtro is a hosted endpoint in front of the providers you hold keys for, with routing by difficulty, fallbacks per level, token allowances per team and a request log — and a memory and a tool layer on top. Every request carries your organisation's memory and is learned from, and the model can read the systems you have connected through tools that read by default and act where you grant it. The same things are reachable as an MCP server.
Where they differ
| Memtro | Portkey | |
|---|---|---|
| Shape | Hosted endpoint plus MCP server; one price per organisation by headcount | Gateway (open source, hosted or self-hosted) plus an observability platform |
| Providers | Those you hold keys for, including Claude Code and Codex subscriptions | Many providers through one universal API |
| Routing | By difficulty on a five-level ladder, with a second and third choice behind each | Configs: fallbacks, conditional routing, retries, load balancing across keys |
| Caching | A short-lived cache of identical connector calls | Simple and semantic response caching |
| Cost control | Token allowances per level and choice, per organisation and team | Usage limits by cost or tokens; rate limits per minute, hour or day |
| Observability | Request log by user, team, model and day; routing decision on every response | Logs, traces, analytics with 21+ metrics, filters, metadata, feedback |
| Guardrails | Permissions and connection grants per team; actions only when granted | Input and output guardrails in the gateway |
| Memory and tools | A bitemporal knowledge graph of the company; 144 connectors | None; the gateway relays what the client sends |
| Hosting | Hosted | Hosted, or self-hosted gateway connected to Portkey |
Honestly, where Portkey is stronger
Observability. If the question you most need answered is "what did every request cost, how long did it take, and which prompt version is doing better", Portkey is built around that question and Memtro is not. Its logs are complete, its traces follow a request through an application, its analytics are a product in their own right, and feedback can be attached to any log. Its routing configs are also more expressive than Memtro's: conditional routing on your own checks, load balancing across several keys for one provider, retries with policies, and semantic caching that answers a paraphrase from the cache.
Portkey's guardrails run inside the gateway on both input and output; Memtro's protection is about reach — what a request may read or change — rather than about inspecting the text.
Where Memtro is stronger
Memtro's gateway is in service of something Portkey does not attempt: giving a team's tools one memory of the company. Before the model sees a question, the relevant memories and graph context are injected; after it answers, the durable facts are kept with their provenance, superseding what they correct, so memory can be read as of any date. During the answer the model reads the CRM, the ledger, the support desk or the warehouse through connector tools. A Portkey deployment moves and measures requests; the prompt that arrives is the prompt your application built.
Routing is by difficulty rather than by rule: a lookup goes to a cheap model and a multi-step investigation to a strong one, on a ladder you set once, and the decision is written on the response. Cost control caps the same ladder, in tokens per team, so a budget is a policy with a graceful failure — the cheaper choice answers — rather than a limit that stops work.
And there is nothing to deploy or instrument. A client points at the endpoint, or a Slack workspace is connected, and the memory is there.
When to choose which
Choose Portkey when you are building and operating AI applications and need production-grade routing configs, caching, guardrails and, above all, observability across every request, with the option to run the gateway yourself.
Choose Memtro when the application is the tools your team already uses, and what you want from the endpoint is memory, connectors, difficulty-based routing and per-team allowances with nothing to run. The two are not exclusive: an OpenAI-compatible endpoint in Memtro can point at a Portkey gateway, and a Portkey config can name Memtro as a target.