Grafbase just launched Nexus, an open-source AI Router that unifies MCP servers and LLMs through a single endpoint. Designed for enterprise-grade governance, control, and observability, Nexus helps teams manage AI complexity, enforce policies, and monitor performance across their entire stack.
Built to work with any MCP server or LLM provider out-of-the-box, Nexus is designed for developers who want to integrate AI with the same rigor as production APIs.
Yeah they definitely belong in the same space. Nexus is an LLM Gateway, but early on, the focus has been on MCP: aggregation, authentication, and a smart approach to tool selection. There is that paper, and a lot of anecdotal evidence, pointing to LLMs not coping well with a selection of tools that is too large: https://arxiv.org/html/2411.09613v1
So Nexus takes a tool search based approach to solving that, among other cool things.
Disclaimer: I don't work on Nexus directly, but I do work at Grafbase.
Here are a few key differentiators vs LiteLLM today:
- Nexus does MCP server aggregation and LLM routing - LiteLLM only does LLM routing
- The Nexus router is a standalone binary that can run with minimal TOML configuration and optionally Redis - LiteLLM is a whole package with dashboard, database etc.
- Nexus is written in Rust - LiteLLM is written in Python
That said, LiteLLM is an impressive project, but we're just getting started with Nexus so stay tuned for a steady barrage of feature launches the coming months:)
The main difference is that while you can get Nexus to list all tools, by default the LLM accesses tools by semantic search — Nexus returns only the relevant tools for the what the LLM is trying to accomplish. Also, Nexus speaks MCP to the LLM, it doesn't translate like litellm_proxy seems to do (I wasn't familiar with it previously).
Seems quite similar to the commercial nexos.ai platform, which also focuses on routing, governance, and observability for AI workloads, but as a proprietary solution rather than open source
I'm curious, what issue does that solve? I'm only working on agents that make tool calls via HTTP in a home baked way but I can't imagine how resolving the tools from 2 MCP servers is harder than 1.
The issue is when you have many MCP tools the context becomes too large for the LLM. So Nexus indexes all the tools and lets you search for the right tool and then execute it.
Thanks, I think I get it now. In our case I've dealt with this problem by refactoring the monolithic agent into smaller agents, smaller, more specific prompts, fewer, more relevant tools.
We've found that monolithic agents just don't perform that well.
Grafbase just launched Nexus, an open-source AI Router that unifies MCP servers and LLMs through a single endpoint. Designed for enterprise-grade governance, control, and observability, Nexus helps teams manage AI complexity, enforce policies, and monitor performance across their entire stack. Built to work with any MCP server or LLM provider out-of-the-box, Nexus is designed for developers who want to integrate AI with the same rigor as production APIs.
Sounds like litellm which I use, I wonder how it compares?
There is also https://github.com/maximhq/bifrost which apparently overcomes some performance issues of litellm and is easy to get going.
Yeah they definitely belong in the same space. Nexus is an LLM Gateway, but early on, the focus has been on MCP: aggregation, authentication, and a smart approach to tool selection. There is that paper, and a lot of anecdotal evidence, pointing to LLMs not coping well with a selection of tools that is too large: https://arxiv.org/html/2411.09613v1
So Nexus takes a tool search based approach to solving that, among other cool things.
Disclaimer: I don't work on Nexus directly, but I do work at Grafbase.
Founder of Grafbase here.
Here are a few key differentiators vs LiteLLM today:
- Nexus does MCP server aggregation and LLM routing - LiteLLM only does LLM routing
- The Nexus router is a standalone binary that can run with minimal TOML configuration and optionally Redis - LiteLLM is a whole package with dashboard, database etc.
- Nexus is written in Rust - LiteLLM is written in Python
That said, LiteLLM is an impressive project, but we're just getting started with Nexus so stay tuned for a steady barrage of feature launches the coming months:)
What's the difference between "MCP Server Aggregation" and the litellm_proxy endpoint described here?
https://docs.litellm.ai/docs/mcp
The main difference is that while you can get Nexus to list all tools, by default the LLM accesses tools by semantic search — Nexus returns only the relevant tools for the what the LLM is trying to accomplish. Also, Nexus speaks MCP to the LLM, it doesn't translate like litellm_proxy seems to do (I wasn't familiar with it previously).
As in Torment Nexus? Wow.
Ha
https://www.sonatype.com/products/sonatype-nexus-pro/trial
Nexus name already has a taker
Seems quite similar to the commercial nexos.ai platform, which also focuses on routing, governance, and observability for AI workloads, but as a proprietary solution rather than open source
From what I can tell they don’t offer a self-hosted router?
It looks like you're planning on monetizing this (which is totally fine!), do you have any plans on what the enterprise version would do differently?
And isn't OpenRouter already open source?
OpenRouter isn't open source that I know of, but there are open source things similar like Litellm.
I thought it was a phone :/, for developers.
That phone was discontinued:)
This is cool
What are you building?
Another proxy?
MCP aggregation is one of the big differentiators
I'm curious, what issue does that solve? I'm only working on agents that make tool calls via HTTP in a home baked way but I can't imagine how resolving the tools from 2 MCP servers is harder than 1.
The issue is when you have many MCP tools the context becomes too large for the LLM. So Nexus indexes all the tools and lets you search for the right tool and then execute it.
Thanks, I think I get it now. In our case I've dealt with this problem by refactoring the monolithic agent into smaller agents, smaller, more specific prompts, fewer, more relevant tools.
We've found that monolithic agents just don't perform that well.
> There is no problem that can't be solved by another level of indirection.
David Wheeler
[dead]