DEV Community

Cover image for I Spent 3 Days Debugging Our LLM Setup. Turns Out We Needed an AI Gateway the Whole Time.
Varshith V Hegde
Varshith V Hegde Subscriber

Posted on

I Spent 3 Days Debugging Our LLM Setup. Turns Out We Needed an AI Gateway the Whole Time.

Let me tell you about a Friday afternoon I'd rather forget.

Three teams, four models, six API keys living in different .env files, one very angry compliance officer, and me just staring at a terminal trying to figure out why we got a $1,400 OpenAI bill for a feature that was supposed to cost fifty bucks.

That was my "okay something is genuinely broken here" moment.

Not some big insight. Just a $1,400 invoice and dead silence on a Slack thread for about ten minutes.

If you've felt even a small version of that, this post is for you.


So what actually is an AI Gateway?

Not the textbook answer. That one goes something like "middleware that abstracts your LLM provider calls." Technically fine, tells you nothing.

Here's how I actually think about it.

You know how bigger engineering orgs eventually build out a platform team? Before that team exists, every squad is doing their own thing. Their own CI setup, their own infra configs, their own credentials. It mostly works. Until it doesn't. And then it catastrophically doesn't all at once.

An AI Gateway is basically that platform layer, except it's for LLMs.

AI Gateway

Every single request your app makes to any model (OpenAI, Anthropic, a self-hosted Llama, whatever you're running) goes through it. Because everything flows through one place, you finally get:

  • One set of credentials instead of keys scattered across five repos
  • Rate limits and budgets that are actually enforced
  • Cost tracking per team, per model, per request
  • Guardrails that catch PII before it leaves your infra
  • One place to look when something blows up

One control plane. Every team. Every model.


The architecture is simpler than it sounds

Here's what happens when you put a gateway in the middle:

Excalidraw AI gateway

Request comes in from your app, gateway catches it, validates auth, checks rate limits, applies input guardrails, picks the right provider, logs everything, checks the response output, sends it back. That's the whole flow.

Your application code doesn't change. You stop pointing at api.openai.com directly and point at your gateway instead. That's literally it from your team's perspective.

The control layer just sits there doing its job quietly.


"But I already have an API gateway. Isn't that enough?"

This is where most people get confused. Including me when I first looked into this.

Quick answer: no. Here's why.

Your API gateway (Kong, AWS API Gateway, Nginx, take your pick) understands traffic. It knows Team A sent 10,000 HTTP requests. It can enforce rate limits, handle auth tokens. That's useful.

Your AI gateway understands what's actually inside those requests. It knows Team A sent 4.2 million tokens to GPT-4o, it cost $84, average latency was 340ms, and 3 of those requests triggered the PII guardrail.

One sees requests. The other sees meaning. That's not a small difference.

For stateless REST APIs, a regular API gateway is totally fine. For LLM workloads where tokens equal money and every prompt is a potential compliance issue, you need something that actually speaks the language.


Do you actually need one right now though?

Let me skip the usual "it depends" and be direct.

You're probably fine without one if:

  • One team, one model, one use case
  • Nobody is asking about costs yet
  • Zero compliance requirements
  • It's a POC or side project

Don't add infrastructure you don't need. Raw SDK calls are fast to ship. Keep it simple when simple works.

You've outgrown the simple setup if:

  • Multiple teams are calling models independently with no visibility into what they're doing
  • Swapping providers requires actual code changes
  • Someone from legal or security or finance asked a question you couldn't answer
  • You've had an API key accidentally committed to a public repo (or almost did)
  • You can't answer "what did we spend on AI last month, by team?" without going on a scavenger hunt through billing dashboards

That last point is genuinely the biggest tell. If someone asks that question and you have to go digging, you already needed this.

What actually pushes teams over the edge

It's never one thing. It's always a pile of smaller things that suddenly feel heavy together.

DevOps realizes they can't track spend because keys are everywhere. Someone commits a key to a public repo. A team uses GPT-4 Turbo for tasks that GPT-4 Mini handles just fine, and you find out after they've burned $2K. Compliance asks for an audit trail and you have nothing.

Each of those individually, fine, you deal with it. All of them stacking up at the same time? That's when the "simple" setup reveals it was never actually simple. You were just deferring the complexity.


What a production gateway actually looks like

Okay enough talking around it. Here's what it gives you in practice, using TrueFoundry as the concrete example.

TrueFoundry MainPage

One API key across all providers

Model Unify

Your teams stop touching raw OpenAI or Anthropic keys entirely. One key, routed through the gateway, with access to every approved model. Rotate it in one place. Done.

Per-team budgets with real enforcement

team

Not "we log it and send you a Slack alert." Actual hard limits. Team hits their monthly budget, the next request gets rejected with a clear error. No surprise bills, no awkward retros about where the spend went.

Automatic failover

OpenAI goes down. It happens. Your app doesn't go down with it because requests automatically route to Anthropic or your self-hosted model. No code changes. No one gets paged. It just keeps working.

Full request tracing

request tracing

Every prompt, every response, every token count, every cost attribution. Logged and queryable. Pull a request from six months ago and reconstruct exactly what happened. This feature alone has saved me more debugging time than I can measure.

Guardrails that actually run everywhere

Guardrails

PII filtering, prompt injection detection, custom output policies. You define the rule once and it applies across every team and every model. No per-team implementation, no "oops we forgot to add the check in this service."

Runs inside your own environment

VPC, on-prem, air-gapped. Data doesn't leave your infra. SOC 2, HIPAA, GDPR compliant. If your compliance team has ever asked "but where does the data actually go," this is finally a clean answer.

Performance-wise it handles 350+ RPS on a single vCPU with sub-3ms latency so you're not adding meaningful overhead to your request path.

TrueFoundry is in the 2026 Gartner Market Guide for AI Gateways and processes 10B+ requests per month for companies like Siemens Healthineers, NVIDIA, Resmed, and Automation Anywhere. Mentioning it not as a flex but as a sense of scale.


The question that actually helped me decide

Forget "do I need an AI gateway."

Ask this instead: when does the cost of NOT having one start to exceed the cost of setting one up?

For most teams that crossover happens way earlier than expected. For us it wasn't one event. It was the accumulation. The audit trail we didn't have. The $1,400 bill nobody could explain. The near-miss with a key in a public repo.

Setting up TrueFoundry honestly took less time than the post-mortem meeting for that billing incident.


Try TrueFoundry free at truefoundry.com (no credit card required, deploys on your cloud in under 10 minutes).


What does your current setup look like? Still on raw SDK calls or have you already hit the wall? Drop a comment, genuinely curious where people are when they start asking this question.

Top comments (0)