If you are early in building with LLMs, there is a good chance you do not need a gateway yet.
Calling a provider SDK directly is often the right choice when traffic is low, the model choice is fixed, and failures are easy to reason about. Introducing additional infrastructure too early adds operational overhead without much benefit.
That changes once LLM usage starts behaving less like a library call and more like shared infrastructure.
This post looks at why LLM gateways are emerging, how different gateways make different tradeoffs, and how to evaluate them beyond surface-level features. We will also look at where Bifrost fits in this landscape and why its design choices matter.
When LLM Usage Becomes Infrastructure
The shift rarely happens all at once.
It usually sta…
If you are early in building with LLMs, there is a good chance you do not need a gateway yet.
Calling a provider SDK directly is often the right choice when traffic is low, the model choice is fixed, and failures are easy to reason about. Introducing additional infrastructure too early adds operational overhead without much benefit.
That changes once LLM usage starts behaving less like a library call and more like shared infrastructure.
This post looks at why LLM gateways are emerging, how different gateways make different tradeoffs, and how to evaluate them beyond surface-level features. We will also look at where Bifrost fits in this landscape and why its design choices matter.
When LLM Usage Becomes Infrastructure
The shift rarely happens all at once.
It usually starts with small additions. A retry wrapper to handle transient failures. Some logging around token usage. A fallback model when latency spikes. None of these are controversial on their own.
Over time, these concerns accumulate.
Model choice stops being static. Teams start routing between providers or model variants based on cost, quality, or availability. Retries become nuanced because failures are no longer binary. Streaming responses and tool calls introduce long-lived request paths. Observability becomes critical because response quality and latency directly affect user experience.
Cost also moves from an offline concern to a runtime one. Understanding spend after the fact is not sufficient when behavior changes dynamically.
At this stage, pushing all of this logic into application code becomes a liability. It increases coupling, duplicates logic across services, and makes system-wide changes risky.
This is where an LLM gateway becomes useful. Not as an abstraction for convenience, but as a control plane that centralizes routing, retries, observability, caching, and policy enforcement.
Once LLM calls sit on the critical path of your system, the gateway itself must behave like infrastructure. Predictable performance, operational simplicity, and failure isolation start to matter more than feature count alone.
That is where the real differences between gateways show up.
The Axes That Actually Matter
Before comparing individual gateways, it helps to define the dimensions that matter once you are operating at scale.
Language and runtime model
The language a gateway is written in heavily influences its concurrency model, memory behavior, and performance envelope. It also affects how easy it is to reason about failures and resource usage.
Codebase complexity and velocity
A gateway is long-lived infrastructure. Its codebase needs to be understandable, extensible, and maintainable. Excessive abstraction or complexity slows down iteration and increases operational risk.
Scalability posture
How the gateway behaves under sustained load matters more than peak throughput. Backpressure, graceful degradation, and predictable latency are critical once traffic grows.
Operational overhead
Configuration surface area, deployment complexity, and day-two operations determine whether a gateway reduces complexity or adds to it.
Intended user profile
Some gateways optimize for developer velocity and flexibility. Others optimize for control, predictability, and scale. Neither is inherently better, but mismatches here lead to frustration.
With these axes in mind, we can look at the current players.
LiteLLM
LiteLLM is one of the most widely used gateways today, especially among individual developers and small teams.
It is written in Python and is extremely feature-rich. It supports a large number of providers, integrates easily with existing Python-based stacks, and gets you productive quickly. For experimentation, prototyping, and low to moderate traffic, it does exactly what it promises.
The tradeoff shows up as load increases.
Python’s runtime characteristics make it harder to achieve predictable performance under sustained high concurrency. As usage grows, issues around latency, resource contention, and process management become more visible. The large feature surface area also means a more complex codebase, which can slow down debugging and optimization.
LiteLLM shines when flexibility and speed of iteration matter most. It is less well suited as a long-term gateway for workloads that require consistent high throughput and tight latency control.
Website: https://litellm.ai/ GitHub: https://github.com/BerriAI/litellm Docs: https://docs.litellm.ai/
Portkey
Portkey takes a different approach.
It is designed with production usage in mind and focuses on providing a clean, controlled gateway layer. The feature set is intentionally narrower, which makes the system easier to reason about and operate.
The emphasis here is on stability and predictability rather than breadth. For teams that value a smaller configuration surface and are comfortable with a more opinionated system, this can be a good fit.
The tradeoff is flexibility. If your use cases evolve quickly or require deep customization, Portkey’s constraints can become limiting. It is well suited for scenarios where requirements are clear and unlikely to change rapidly.
Website: https://portkey.ai/ GitHub: https://github.com/Portkey-AI/gateway Docs: https://docs.portkey.ai/
TensorZero
TensorZero is written in Rust and targets high-performance production workloads.
Rust offers strong guarantees around memory safety and concurrency, which makes it attractive for infrastructure that needs to handle sustained load with minimal overhead. Architecturally, TensorZero is positioned as a serious systems-level gateway.
The tradeoff here is complexity.
Rust has a steeper learning curve, and development velocity can be slower compared to higher-level languages. Extending the system or onboarding new contributors requires more specialized expertise. For teams that value maximum performance and are comfortable operating Rust-based systems, this is a reasonable tradeoff.
For others, the complexity can outweigh the benefits, especially when requirements are still evolving.
Website: https://www.tensorzero.com/ GitHub: https://github.com/tensorzero/tensorzero Docs: https://www.tensorzero.com/docs
TrueFoundry
TrueFoundry approaches the problem from a platform perspective.
Rather than being a standalone gateway, it is part of a broader ecosystem that includes deployment, observability, and management tooling. This integrated approach can be powerful when the platform aligns closely with your needs.
The tradeoff is coupling.
Adopting the gateway often means buying into the broader platform. For teams that want a lightweight, standalone component that fits into an existing stack, this can feel heavy. For teams that want an opinionated, end-to-end solution, it can be appealing.
Website: https://www.truefoundry.com/ Docs: https://docs.truefoundry.com/ LLM Gateway specific: https://www.truefoundry.com/llm-gateway
Where Bifrost Fits
Bifrost is written in Go, and that choice is deliberate.
Go offers a strong balance between performance, simplicity, and development velocity. Its concurrency model is well suited for high-throughput network services, and its runtime characteristics make it easier to reason about memory and latency behavior under load.
Compared to Python-based gateways, Bifrost can push higher sustained concurrency with more predictable performance. Compared to Rust-based systems, it offers faster iteration and a lower barrier to contribution.
The goal with Bifrost is not to maximize any single dimension in isolation. It is to balance performance, extensibility, and operational simplicity.
The codebase is designed to be readable and modular, making it easier to add features without introducing excessive complexity. This matters because gateways evolve quickly as new models, providers, and patterns emerge.
From a scalability perspective, Bifrost is built to behave like infrastructure. Backpressure, isolation, and predictable failure modes are first-class concerns. The focus is on staying out of the way while providing a reliable control layer.
Website: https://www.getbifrost.ai/ Bifrost specific: https://www.getmaxim.ai/bifrost GitHub: https://github.com/maximhq/bifrost
Docs: https://docs.getbifrost.ai/
What Will Actually Decide the Winners
Language choice matters, but it is not sufficient on its own.
Gateways that win long term will balance three things well. They will be fast enough to handle real workloads, simple enough to operate and extend, and flexible enough to adapt as the ecosystem changes.
Over-optimizing for features leads to complexity. Over-optimizing for performance can slow down iteration. Over-optimizing for control can limit adoption.
The gateways that survive will be the ones that recognize these tradeoffs early and design for balance.
Closing Thoughts
The LLM gateway space is still early, but it is no longer hypothetical.
As LLM usage moves from experimentation to production, the need to externalize routing, observability, and policy becomes clear. Not every team needs a gateway today, and that is fine.
When you do need one, the choice should be informed by architecture, not marketing.
Bifrost is positioned for teams that care about performance, clarity, and the ability to ship and evolve quickly. It does not try to be everything to everyone. It tries to be solid infrastructure that you can build on.
In a space that is still finding its footing, that balance matters.