Announcing Obot Platform v0.23.0: A Reworked UI, an LLM Gateway for Coding Agents, and GitOps for Multi-User Servers

Announcing Obot Platform v0.23.0: A Reworked UI, an LLM Gateway for Coding Agents, and GitOps for Multi-User Servers

The Obot Platform v0.23.0 release is out. It is a step toward deeper integration between Obot and the clients and agents that connect to it. Two early pieces land here: the LLM Gateway can now serve as a model endpoint for coding agents like Claude Code and Codex, and obot mcp search lets users and agents find MCP servers from the command line. The release’s biggest change is the UI, which we’ve reorganized to keep AI governance separate from everyday use.

  • An LLM Gateway that external coding agents can point at directly
  • obot mcp search for finding servers from the command line
  • A reworked UI that separates administration from end-user consumption
  • Multi-user MCP servers defined as catalog entries, managed through GitOps
  • A license key for enabling enterprise features, so you can start with OSS and upgrade in place

An LLM Gateway for Your Coding Agents

Obot’s LLM Gateway can now act as a model endpoint compatible with the OpenAI and Anthropic APIs for external clients. You point a tool like Claude Code or Codex at the gateway, authenticate with your Obot token, and call models by their native provider names, for example gpt-5.5 or claude-sonnet-4-6. Obot forwards the request to the vendor and enforces your per-user model access policy. The model list a client sees is scoped to only the models that user is allowed to call.

A developer points their agent at the gateway and gets to work. The organization keeps a single place to decide who can call which models. Setup is two environment variables:

export ANTHROPIC_BASE_URL="https://obot.example.com/api/llm-proxy/anthropic"
export ANTHROPIC_API_KEY="$(obot login --url https://obot.example.com --print-token)"

A new Models page shows users which OpenAI and Anthropic models they can access, the gateway base URL, and a copy-paste example to get started. The gateway pages (Tokens, Model Providers, Model Access Policies, and Models) are now grouped under a dedicated “LLM Gateway” section in the sidebar.

This is a starting point. With model traffic flowing through Obot, the gateway is the natural place to add the controls that come next, like guardrails on how agents use models and visibility into token cost. Both build on what shipped here.

Finding MCP Servers from the Command Line

Finding the right MCP server should not require opening the UI. The new obot mcp search command lists and searches the servers and catalog entries available to you, from the terminal.

obot mcp search github

It is also a building block for local coding agents. Given a way to query the servers a user has access to, an agent could find the right MCP server and wire it up on the user’s behalf, instead of asking the user to go find and configure it by hand. This is an early piece of a larger effort to make Obot’s catalog something agents can act on, not just something people browse.

A UI Built for Two Different Jobs

Agents and end users are one side of Obot. Administrators are the other, and the two had been sharing one set of screens. Managing an MCP catalog and consuming what is in it are different jobs, but an administrator curating catalog entries and an end user looking for a server to connect to were navigating the same pages. Neither was well served by that.

v0.23.0 reorganizes the UI to separate the two. Administrators get dedicated areas for managing catalog entries and deployments. End users get a focused experience for discovering and connecting to the servers available to them, without the administrative surface area in the way.

Multi-User MCP Servers, Managed Through GitOps

Obot already lets you manage MCP servers through a Git-backed catalog, so server configurations get version control, code review, and automated validation like any other infrastructure. Multi-user servers were the exception. The shared, multitenant servers that many users connect to had to be set up by hand and lived outside that workflow.

In v0.23.0, multi-user MCP servers can be defined as catalog entries. That puts them in the same Git-backed MCP catalog as the rest of your servers. You declare a shared server as a template in a git-managed catalog and get the same review and versioning you already rely on.

A multi-user template can now reference externally managed secrets. The credentials a shared server needs are pulled from your existing secret store rather than typed into Obot, so the secret stays where it already lives. Multiple servers can be deployed from a single template, and users connect by creating instances on a deployed server.

A License Key for Enterprise Features

Enterprise features are now enabled with a license key. Before v0.23.0, the enterprise edition was a separate private Docker image, and getting access meant being granted access to that image. Now the same open-source build powers both editions, and a valid license key turns the enterprise features on.

You supply the key through configuration, with the OBOT_SERVER_LICENSE_KEY environment variable, or you enter it in the UI. The point is that you can start on the open-source version and upgrade to enterprise in place, without redeploying a different image or starting over. If a license is removed or becomes invalid, Obot keeps running as long as no enterprise features are configured.

Additional Improvements

This release also includes a number of smaller changes:

  • API tokens now replace auth tokens. A single API-key model covers everything from connecting to MCP servers to calling the Obot API, with selectable capabilities (LLM, skills, device scan, artifact, and API access) that you create from the UI or the CLI.
  • MCP OAuth flows now show a consent screen, which also signals when a server requires second-level OAuth and that the user will be redirected to complete it.
  • Model Access Policies now accept wildcard suffix patterns such as claude-haiku-4-5*, granting access to every model whose ID starts with the given prefix and covering new matching models as providers add them.
  • Per-entry CPU and memory requests and limits can be set in the UI for hosted MCP server catalog entries when the Kubernetes engine is enabled.
  • Obot can now block private and link-local IPs, and blocking of loopback IPs is on by default.

Looking ahead, we are focused on deeper integration with the clients people run: agents that configure the MCP servers they need on first connect, the Obot client rolled out and enforced through MDM with scanning on a schedule, token usage pulled from clients for organization-wide analysis, and a Windows client. v0.23.0 is a step in that direction.

Get Started

Obot v0.23.0 is available now. New to Obot? Start with our installation guide. Upgrading? Read the release notes first, since this release changes a few defaults. Either way, we’d like to hear what you’re running into. Reach us on Discord or connect directly with one of our reps at info@obot.ai.

Related Articles