github obot-platform/obot v0.17.0
on GitHub

latest releases: v0.23.1, v0.23.0, v0.23.0-rc5...
3 months ago

We’re excited to announce the v0.17.0 release of the Obot MCP Platform. This release introduces a powerful new agent experience for users, enhances OAuth and token visibility, and delivers major improvements across deployment workflows, high-availability support, and overall UI polish.

Big Updates

Obot Agent (Beta)

This release introduces the new Obot Agent experience in beta.

Every user now gets their own agent backed by a cloud-based computer with full agentic capabilities, deeply integrated with Obot’s MCP gateway. With Obot Agents, users can build and run reproducible agentic workflows or perform ad hoc agentic work as needed.

Meanwhile, IT administrators retain full control. Agents run in controlled sandboxes and interact with external systems exclusively through Obot-managed LLM connections and MCP servers — with governance, RBAC, and auditing built in.

Important: Obot Agent replaces the existing Obot Chat experience. Obot Chat is now deprecated and will be fully removed in a future release. This is a breaking change.

As of v0.17.0, Obot Chat is disabled by default. To re-enable it, set the OBOT_SERVER_DISABLE_LEGACY_CHAT environment variable to false.

There is no migration path from Obot Chat to Obot Agent.

Static OAuth for Remote MCP Servers

Remote MCP catalog entries can now be configured with static OAuth credentials. The OAuth authorization URL is surfaced directly in the “connect to server” flow, simplifying external integrations and improving enterprise compatibility.

This enables connectivity to remote MCP servers that do not support Dynamic Client Registration (DCR) or Client ID Metadata Documents (CIMD). Administrators can configure static credentials once in Obot, allowing downstream clients that require DCR or CIMD to successfully connect via Obot.

LLM Token Usage Visibility

A new Admin Token Usage page provides visibility into LLM token consumption across the platform.

Usage is derived directly from token counts returned by upstream LLM providers and can be broken down by:

  • Model
  • Provider
  • Token type (input/output)
  • User

This provides better insight into model usage patterns and cost management.

Kubernetes RuntimeClass Support

You can now configure the Kubernetes RuntimeClass used for MCP servers deployed by Obot.

We are using this capability in our own environments to run Obot Agents inside hardened GKE gVisor sandboxes, enabling stronger workload isolation for security-sensitive deployments.

Additional Improvements

  • Enhanced deployment logs UI with expandable views and direct catalog entry linking
  • Expanded audit log access for Power User Plus users and scoped access for Basic users
  • Improved retry handling, loading states, and error recovery across the UI
  • Increased observability for Basic users
  • Rate limiting configuration documentation and environment variable support
  • Improvements to LLM proxy streaming and token parsing reliability

Upgrade Notes

First and foremost: Obot Chat is now deprecated. It is disabled by default in this release. When you upgrade, it will be gone and the Obot Agent feature will be enabled. You can reenable the legacy Obot Chat by setting OBOT_SERVER_DISABLE_LEGACY_CHAT environment variable to false.

This is breaking change and your previous Obot chats and projects will not be available.

Next, Obot Agent is an early Beta feature. We plan to iterate on it quickly, adding a lot of features and functionality. Expect it to have some rough edges right now and for it to evolve significantly as we receive feedback. Here are few specific things to be aware of:

  • Obot Agent only works well with Anthropic models. We've only tuned and tested its prompts for the most recent releases of Sonnet and Opus. In the future, we'll release OpenAI tuned prompts. Feel free to try it with other models, but in our light testing, the latest OpenAI models didn't perform well with our prompts.
  • Make sure you have default models set. If you've been using Obot Chat, you probably already do. Obot Agent will uses LLM and Fast LLM defaults and it does not fail gracefully if they are unset.
  • It takes a minute or two for Obot Agent to be functional after startup. Various controllers and caches in Obot are starting up and again we don't yet fail gracefully when we're in this state.
  • Every Obot agent gets a pod/container and a volume. If you're running with the Docker backend, this shouldn't be a big deal. If you're running with the Kubernetes backend, you need to have a StorageClass set if you want your agents to survive node restarts. You also need to plan for a pod and volume per user. We have plans to improve this in the future so that you don't need a StorageClass (beyond local storage).

Getting Started

docker run -d --name obot -p 8080:8080 -v /var/run/docker.sock:/var/run/docker.sock --pull=always \
ghcr.io/obot-platform/obot:latest

For full documentation and configuration guidance, see:

https://docs.obot.ai/

What's Changed

Full Changelog: v0.16.4...v0.17.0

Check out latest releases or
releases around obot-platform/obot v0.17.0

Don't miss a new obot release

NewReleases is sending notifications on new releases.

Get notifications