← All posts
Comparison

TrueFoundry AI Gateway alternative: buying one module of a platform

TrueFoundry's gateway is one module of a platform that also sells model deployment, GPU serving, and agent, MCP and skills registries — metered by requests and by seat. nRouter sells the gateway alone, priced as a share of model spend. A procedure for deciding which purchase you are making.

nRouter team · 12 min read
TrueFoundry AI Gateway alternative: buying one module of a platform

Short answer: TrueFoundry's gateway is one module of a platform metered by requests and by seat. nRouter sells the gateway alone, priced as a share of model spend. If you want the rest of the platform the gateway is nearly free at the margin — and if you don't, you are paying platform pricing for one module.

Teams searching for a TrueFoundry alternative are usually not unhappy with the product. They are working out what they bought, or are about to buy.

TrueFoundry's own documentation describes the AI Gateway as a proxy layer in front of the model providers, and lists it alongside a long set of neighbouring capabilities: unified API, multimodal and audio endpoints, load balancing and fallbacks, semantic caching, batch processing, access control and API key management, rate limiting, budget tracking, guardrails, observability, prompt management, an MCP registry, an agent registry and a skills registry. That is a platform. The gateway is a room in it.

Whether that is the right purchase depends on a question no feature table can answer for you: how much of the rest of the building will you actually occupy? The rest of this post is a procedure for answering that, plus the arithmetic that follows from the answer.


The two meters, and why they disagree

TrueFoundry's published plans meter two things at once — request volume and seats:

PlanPriceRequests / monthUsers
Developer$050k3
Pro$499 / mo1M10
Pro Plus$2,999 / mo1M25
EnterpriseCustom10M+Custom

Overage on Pro is published as an additional $499/month for a further 2M requests and 5 API keys.

There is a third meter neither plan controls, and it is the one that dominates the bill: the provider's own per-token rate. Those are published and they move — Anthropic and AWS Bedrock both post per-million-token prices that differ by an order of magnitude between their small and flagship models. A request allowance is therefore not a spend control at all: a million cheap classification calls and a million long-context reasoning calls consume the same allowance and produce wildly different invoices. Keep that in mind while reading the table above, because it is the reason the two products are not measuring the same thing.

nRouter meters exactly one thing: what you spend on models. The platform fee is a flat 4% of your credits on pay-as-you-go (added on top of the credits you buy) and 0% on Pro, with no seat count, no request allowance and no key allowance anywhere in it. The plan table and the crossover arithmetic live on /pricing; the reason a feature never sits behind a plan is argued in Every Feature on Every Plan.

Convert one meter into the other and the shape becomes obvious. TrueFoundry's Pro subscription of $499/month equals nRouter's pay-as-you-go fee at $12,475/month of model spend. Below that spend, the percentage is the smaller number. Above it, nRouter Pro's flat $50/month is smaller still, because it stops scaling entirely.

That comparison is only fair if the gateway is all you want. If you are also deploying models, running GPU workloads and using the agent registry, the $499 is buying four or five things and comparing it to a gateway fee is not an honest comparison. Which is the whole point: decide what you are buying before you compare prices.

Two secondary consequences worth naming, because they surprise people at the wrong moment:

  • Seats are a hard number. Three users on Developer, ten on Pro. Governance tools have a way of acquiring viewers — finance wants the spend view, security wants the audit log, a second team lead wants their own budget page. On nRouter, adding a viewer to an org is free, and the org/team/member scoping that makes it safe is described in Org, Team, Member: Scoping Keys, Budgets, Guardrails.
  • API keys are counted in the overage line. A per-service or per-customer key strategy multiplies keys deliberately. Check that your intended key hygiene is not a billing event before you design it.

The occupancy test

Answer these five before you compare anything else. Each is a yes or a no.

  1. Are you deploying and serving your own models — fine-tuned, open-weights, or classical ML — on infrastructure this vendor manages?
  2. Do you need GPU orchestration or autoscaling from the same vendor?
  3. Will you use the agent, MCP or skills registries as your team's actual registry, not as a demo?
  4. Do you want experiment tracking and model deployment in the same pane as your LLM calls?
  5. Is the number of humans who need a login going to stay inside the seat count you are paying for?

Three or more yes: you are buying a platform, the gateway is a bundled convenience, and a standalone gateway would be a second bill for a room you already own. Stay.

One or zero yes: you are buying a gateway and paying platform pricing for it. That is the case this post is written for.

Two yes: price both explicitly, including the seat line, and check what your answer to question 1 will be in twelve months. That answer moves more than the others.


Side-by-side: module versus standalone

ConcernTrueFoundry AI GatewaynRouter
What you buyA platform; the gateway is one module among model deployment, GPU serving, registriesA gateway, and nothing else
Metered byRequests per month and seats, per the published plansModel spend only
Entry price$0 Developer tier — 50k requests, 3 users$5 first credit purchase; card required
DeploymentManaged SaaS, hybrid (your object storage), or self-hosted in your cloudManaged endpoint at https://api.nrouter.ai/v1
Provider credentialsYours, configured into the gatewayHeld by nRouter — no bring-your-own-key path
Own-model servingFirst-class — the platform's coreNot offered
Guardrails, prompts, budgets, evals, A/BIncluded in the platform, per its docsIncluded on every plan
Feature availability by planPer TrueFoundry's published plan structureIdentical on all plans; plans change the fee and the rate limits
Seat costBounded per plan, then a higher planNone

TrueFoundry and TrueFoundry AI Gateway are trademarks of TrueFoundry Technologies, Inc. and/or its affiliates. nRouter is not affiliated with or endorsed by TrueFoundry. Every TrueFoundry claim above is sourced from TrueFoundry's own documentation and pricing page on the dates listed in the sources below; if any have changed, email hello@nrouter.ai and we will update the post.


Where the gateway sits, and who can see the traffic

TrueFoundry publishes three deployment shapes: fully managed SaaS across regions, a hybrid mode where the data stays in your own object storage while TrueFoundry operates the gateway, and fully self-hosted in your own cloud or on-premises.

The hybrid mode is the interesting one and it is a genuine advantage. "The vendor runs the control plane, my prompts and completions land in my bucket" is a real answer to a real procurement objection, and it is one we do not have. nRouter is a managed endpoint; if your requirement is that request bodies never transit a third party's storage, that requirement is dispositive and you should stay. Our reasoning for taking the managed-only position — and what we think it buys you in exchange — is in Managed LLM Gateway vs Self-Hosted.

The credential question runs the other way. A self-hosted or hybrid gateway is one you configure with your own provider keys, which means your OpenAI, Anthropic and Bedrock credentials sit in your platform configuration and your rotation calendar. nRouter has no bring-your-own-key path at all: one nRouter key and a credit balance, provider credentials on our side. That trade, argued including its downsides, is No BYOK: One nRouter Key Instead of Ten Provider Keys.


Budget enforcement, and the two status codes it produces

"Budget tracking" appears on most gateway feature lists. The distinction worth checking is whether a budget reports or stops, and what your caller sees when it stops — because that determines whether your retry loop makes things better or worse.

On nRouter the ceilings are enforced pre-flight, at four scopes, and they answer with two deliberately different codes:

ScopeWhat it capsResponse when exhausted
OrganizationTotal spend across every team402 budget_exceeded
TeamOne team's share402 budget_exceeded
UserOne member's share402 budget_exceeded
KeyOne virtual key — a service, a customer, an agent run429 key_budget_exceeded

The split follows the codes' own definitions rather than a house convention. RFC 9110 §15.5.3 reserves 402 Payment Required for the payment case; 429 Too Many Requests comes from RFC 6585 §4, which frames it around a condition that resolves after a wait. Any HTTP client that already distinguishes them behaves correctly here before you write a line of handling.

The split is not cosmetic. A 402 means the money is gone and retrying is pointless until someone raises a ceiling or adds credit. A 429 on a key budget means this key is done for the window while the rest of the org is fine, so a caller can fail over to a different key or shed that workload without taking the whole service down. Getting that wrong turns a spent budget into a retry storm — the full treatment is in 429 vs 402 on an LLM Gateway, and the four ceilings are configured as described at /docs/guides/budget-controls and walked through in Hard LLM Spend Caps at Org, Team, User, and Key Scope.

The same pre-flight discipline applies to cost reporting: when a call's cost cannot be determined, x-nr-request-cost is absent from the response and x-nr-cost-status reads unpriced. It is never reported as zero, for the reason in Cost Honesty.


What TrueFoundry genuinely does better

It serves your own models. This is the whole ballgame and it is not close. If you fine-tune, if you run open-weights models on your own GPUs, if you have classical ML in production, TrueFoundry deploys and scales those. nRouter routes to a catalog of hosted models — see /models — and has no story at all for a checkpoint you trained last week. A team with both workloads is choosing between one vendor for everything and two vendors with a clean seam.

It has a $0 entry tier. Developer is 50k requests and three users for nothing. nRouter's entry is a real $5 charge on a real card. We think card-first is the honest design — it means nobody's evaluation is silently rate-limited into uselessness, and there is no free tier to be quietly withdrawn — but if your constraint is "prove it before I file a purchase request," a $0 tier is easier and we should say so.

The registries are ahead of us. Agent, MCP and skills registries are shipped surfaces there. If your team is standardizing how agents discover tools, that is a real capability sitting in the same product as your gateway.

Data residency options. Covered above, and worth repeating here because it belongs on this list as much as on that one.


Switch cost: one base URL, one key

Both sides are OpenAI-compatible, so the code change is two lines:

  from openai import OpenAI

  client = OpenAI(
-     base_url="https://<your-truefoundry-host>/api/llm",
-     api_key=os.environ["TFY_API_KEY"],
+     base_url="https://api.nrouter.ai/v1",
+     api_key=os.environ["NROUTER_API_KEY"],
  )

  resp = client.chat.completions.create(
-     model="openai-main/gpt-5.5",
+     model="gpt-5-mini",
      messages=[{"role": "user", "content": "summarise this ticket"}],
  )

The line that is easy to miss is the third one. Platform gateways commonly namespace a model by the provider account it was configured under, so the model string in your code encodes a piece of that platform's configuration. On nRouter the model string is the model — gpt-5-mini, gpt-5.4, claude-haiku-4-5, o3 — and the mapping to a provider account is not your concern. Grep your codebase for the namespaced form before you plan the migration; it is usually in more places than anyone expects, including prompt templates and eval fixtures.


What maps, and what does not

In TrueFoundryOn nRouter
Gateway API keyA virtual key, scoped per service, team or customer
Provider account configurationNothing — provider credentials are not yours to hold
Namespaced model stringsPlain model names from /models
Load balancing and fallbacksFallback chains across providers
Rate limitingRPM and TPM per key, team and org
Budget trackingEnforced ceilings at four scopes, with the codes above
Guardrails, prompt management, observabilityEquivalent surfaces, on every plan
Semantic cachingNo direct equivalent
Model deployment, GPU orchestration, fine-tuningStays where it is — we do not do this
Agent, MCP and skills registriesNo equivalent
Seat managementNot applicable; seats are not metered

Four rows say the migration is partial. If those four rows are the ones you use, the migration is not partial — it is wrong, and the next section is the one that applies.


The renewal test, and when to stay

Here is the question to ask at renewal, or before signing: if you removed the gateway from this contract, would the rest still be worth the price?

If yes, stay on TrueFoundry and stop reading — the gateway is riding along on a purchase you would make anyway, and splitting it out buys you a second vendor relationship for no gain.

If no — if the honest answer is that the gateway is most of the value and the platform is the wrapper it arrived in — then you are paying a platform price for a gateway, bounded by seats and requests you did not choose to meter. That is the case where a standalone gateway is simply the cheaper and simpler purchase: priced on model spend, no seat ceiling, no request allowance, every governance surface available on the plan you are already on.

Stay on TrueFoundry if own-model serving is live in production, if hybrid or self-hosted deployment is a compliance requirement rather than a preference, if the registries are load-bearing for how your agents find tools, or if semantic caching is already paying for itself. Those are good reasons and none of them are solved by switching.


Try it

Pay as you go starts at $5 — a card is required, the first $5 is a real charge, and the platform fee is charged on top. No free tier, and we would rather say that plainly than bury it.

Create an account, mint a key, and run one workload against https://api.nrouter.ai/v1 alongside your existing gateway. Compare the bill for that workload against the request and seat lines on your current plan.

Bring your plan tier, your seat count and your model bill to a walk-through and we will run the occupancy test above with you. Questions go to hello@nrouter.ai or the public nRouter Slack.


See also


Sources

Verified 2026-08-23. Every TrueFoundry claim traces to TrueFoundry's own documentation or pricing page. If a page has changed since, email hello@nrouter.ai and we will re-audit and re-date this section.

TrueFoundry, Anthropic and AWS are trademarks of their respective owners. nRouter is not affiliated with or endorsed by them.

Share
Written by nRouter teamEngineering, product, and company posts from the nRouter team — code-first, cost-honest, no vendor-marketing fluff.