As you all might have seen, in the past two blogs, I wrote about how I explored the different features of Bifrost, and how each one of them improved my workflow, and how I interact with different harnesses through one common gateway. If you haven’t read them yet, go check them out from here. So after exploring all the free features, I was getting the urge to try the Enterprise version as well (for my personal use, though). So, I contacted the Bifrost team, and thanks to them, they gave me limited access to try out their paid features for free!! So, in this blog, I will be exploring the most prominent paid features, and would give an honest verdict on whether it’s great for personal use or not, or whether you should even give it a try for your enterprise use case.
Transparency through Audit Logs
So, before creating any new Enterprise configuration, I wanted to see whether Bifrost could actually tell me what was happening behind the scenes. Audit Logs tell you exactly that. It’s different from the regular LLM logs because they show the requests going through the gateway, while Audit Logs focus on changes and administrative activity inside Bifrost. So if someone creates a virtual key, changes a routing rule, updates a guardrail, or modifies the cluster configuration, this is where we should be able to find it.
It is not the most exciting feature on its own, and for personal use, this might not be that useful, but in an enterprise setting, it is probably one of the most important ones to have, when you are working with a large group of people, and you have to keep tabs on everything that’s going on.
What are MCP Tool Groups?
In my previous blog, I already mentioned how I connected the MCP Gateway to OpenCode using the Virtual Key, which enabled Bifrost to expose all of my configured MCP tools through that one endpoint.
But that also raised a question: do I really want every harness to have access to every tool? So, this time I decided to try MCP Tool Groups.
The idea is pretty simple. We can create a group of selected MCP tools and attach that group to a virtual key. OpenCode already uses my dedicated Enterprise virtual key, so I can control the tools available to it without changing the rest of my MCP setup.
In the previous blog, you might have seen that I’ve used the Context7 MCP server. It provided access to two tools:
resolve-library-idquery-docs
So, while creating the tool group, I decided to drop the query-docs and kept only the resolve-library-id activated.
Then, under Associations, I attached the group only to my opencode-enterprise virtual key. I didn't attach it to any teams, customers, providers, or other keys.
The OpenCode MCP configuration itself didn't need much change. It was already pointing to Bifrost's remote MCP endpoint:
json
{
"mcp": {
"bifrost": {
"type": "remote",
"url": "https://bifrost-enterprise.agitracker.io/mcp",
"enabled": true,
"oauth": false,
"headers": {
"Authorization": "Bearer {file:./bifrost-virtual-key}"
}
}
}
}
I kept the virtual key inside a separate local file, so it never had to be pasted into the configuration or committed to Git.
After restarting OpenCode, I used a deliberately small prompt,
Use the Context7 MCP to resolve the React library. Reply with only the returned library ID.
The request executed successfully, as you can see in the above screenshot.
So, is this feature useful? The idea is excellent, especially when different coding harnesses should have access to different MCP tools. And, it gives you a central place to manage tool access instead of duplicating MCP configuration across every client.
What is Adaptive routing?
The next feature I wanted to try was Adaptive Routing. The idea behind it is quite useful, especially if you are running several models, providers, or API keys through the same Bifrost gateway.
Normally, requests are distributed using fixed weights. For example, if two Gemini keys have the same weight, Bifrost can send roughly half of the traffic to each one. The problem is that fixed weights do not know whether one key has become slower, started returning errors, or hit a rate limit.
Adaptive Routing tries to solve that automatically.
Bifrost monitors the latency, error rate, success rate, and utilization of each available route. It then recalculates their weights every few seconds. And, a healthy and faster route receives more traffic, while a failing or slow route receives less. Bifrost still sends a small amount of traffic to recovering routes so it can detect when they become healthy again.
The routing happens at two levels:
- Bifrost can select which provider should handle a model request.
- After selecting the provider, it can choose the best API key configured for that provider.
This makes the feature more useful for companies that maintain multiple provider accounts or keys. Instead of manually changing weights whenever a provider starts acting up, Bifrost can react to the recent performance data on its own.
How to set Guardrails?
Every model has a set of their own guardrails by default, but while working on them you might need to put your own custom guardrails as well. And the best place to do that is to integrate it directly into your AI gateway!
This feature is meant to protect both the prompts sent to a model and the responses coming back from it. Bifrost separates the feature into two parts: rules decide when a check should run, while profiles define what kind of check should be performed. For this test, I wanted to avoid adding another external API key, so I chose Bifrost's built-in Custom Regex provider. According to the Guardrails documentation, Custom Regex runs locally and can be used for deterministic pattern checks.
So, I created two guardrail rules. One for the input, and the other one for the output.
So, now if I send a request like Reply with exactly: BIFROST_GUARDRAIL_TEST, I get a regex pattern matched error. That’s where the guardrail is actually doing its job.
It is as simple as that. No fancy setup needed for a working guardrail.
Final thoughts
When I started exploring Bifrost Enterprise, I expected the paid version to feel like the open-source gateway with a few extra switches. That wasn’t true.
The core experience stayed familiar, and I could continue using OpenCode through one Bifrost endpoint while the gateway handled the provider connection underneath. That part was convenient. I did not need to change my workflow every time I switched between OpenAI and Gemini.
The enterprise features that made the most sense to me were Audit Logs and MCP Tool Groups. Audit Logs give teams a central record of what happened, while MCP Tool Groups make it easier to control which tools a client can access.
Would I use Bifrost Enterprise for my personal setup? Probably not if I only had one provider, one API key, and a handful of requests. The extra governance and operational features would be more machinery than I need.
For a team running several models, provider keys, MCP clients, and internal users, the situation is different. A shared gateway, centralized logs, access controls, guardrails, and tool restrictions can remove a lot of repeated setup from individual applications. And if you think you are the right candidate, you can always book a demo!
Top comments (2)
great share
Thank you!!