Bifrost adds Warp, a read-only agent that answers questions about gateway telemetry

Bifrost, the open-source AI gateway from Maxim AI, shipped an assistant called Warp in version 2.3.0 on October 13, 2026. Warp, which was called Odin during development, is a tool-calling agent that lives in the gateway’s own dashboard. Asked “Which model had the worst p99 latency yesterday?”, it queries the gateway’s logs, metrics and governance settings and answers with numbers, inline charts and links to the matching log rows. The release labels it alpha. Every tool Warp can call is read-only, every query runs with the permissions of the person asking, and a companion feature embeds logged conversations into a vector store so Warp can find them by meaning rather than by filter. The desk did not run Warp; every detail below comes from Bifrost’s changelogs, documentation and announcement post, or from the standards bodies named.

TL;DR

• Bifrost v2.3.0 (October 13, 2026) adds Warp, an alpha in-dashboard agent that answers questions about logs, spend, latency and governance in plain language.
• Warp calls only read-only tools such as query_logs, query_metrics, get_request_trace and describe_virtual_key. It has no tool that changes configuration or calls providers on a user’s behalf.
• A semantic search tool queries an embedding index of completed chat logs, filled live and by a resumable backfill. Logs with content logging off are never indexed.
• Queries run as the asker. Enterprise adds Warp and WarpSession RBAC resources. The warp feature flag is on by default in open source and off by default in Enterprise.
• Warp’s own model calls pass through the gateway, appear in logs under the app name Warp, and are subject to the asker’s budgets and rate limits.

Warp at a glance

What shipped in v2.3.0

The v2.3.0 changelog describes Warp as “a new in-dashboard agent that answers questions about the deployment’s logs, spend, latency and governance in plain language, using read-only tools.” Three related entries landed alongside it: Warp Semantic Log Search, which embeds completed logs so Warp can retrieve conversations by meaning; a Background Jobs panel that shows Warp’s log indexing with progress and a cancel button; and a per-virtual-key content logging control that, as described below, also keeps a key’s traffic out of Warp’s index.

Maxim followed on October 15 with a post by Vrinda Kohli, Meet Warp: An agent for your gateway’s telemetry. It describes Warp as “a tool-calling agent that runs on the Responses API, through your own Bifrost Gateway instance,” and says it “has no direct database access.” The changelog puts it operationally: Warp “calls the gateway in-process.” The post’s motivating example is a question no filter can answer, “Did anyone complain about the new checkout flow?”, because “the answer lives in what the requests say.”

The two follow-up releases, v2.3.1 on October 19 and v2.3.2 on October 20, contain no Warp entries.

Why telemetry is getting a chat interface

Warp joins a pattern that has been spreading across observability products. Grafana Labs’ documentation says Grafana Assistant “brings a purpose-built LLM to Grafana so operators, developers, and SREs can troubleshoot issues, manage dashboards, and answer product questions,” and a Grafana webinar listed on the same page promises answers “without writing PromQL.” New Relic’s documentation describes New Relic AI as an assistant engineers can query in natural language, including to write NRQL queries, reachable through chat, the NRQL console and the Model Context Protocol.

Two things set Warp apart, and both follow from where it sits.

The first is the data. An AI gateway sees every model call that crosses it, with attribution the gateway itself assigned: virtual key, user, team, customer, provider, model, retries, fallbacks and cost. As running an AI gateway in front of every model call argues, that position is what makes a gateway useful for cost and policy. Warp is an interface onto that record.

The second is the governance context. A question like “How close is the support-bot key to its budget?” (one of the announcement’s sample prompts) is about policy state, which lives in the gateway’s configuration. Warp’s describe_virtual_key tool reads a key’s budget, rate limit and allowed providers and models, and the Enterprise-only describe_user_limits reports access-profile budgets and rate limits from live counters, according to the Enterprise changelog.

For readers comparing tools that trace agents and model calls, the agent observability tools survey maps the wider category. Warp is a query layer over the gateway’s own store, and it pairs with whatever tracing backend the gateway exports to.

Gateway logs and the GenAI conventions

What Warp can answer depends on what the gateway records. Bifrost’s content logging page splits this into two kinds of information. Metadata covers “model, provider, token counts, cost, latency, status, and governance attribution.” Content is “the actual prompts, completions, and tool traffic.”

That split mirrors how the wider industry is standardizing LLM telemetry. OpenTelemetry, the open standard for traces, metrics and logs, maintains semantic conventions for generative AI: agreed attribute names such as gen_ai.provider.name, gen_ai.request.model and gen_ai.usage.input_tokens. Those conventions recently left the main specification. The OpenTelemetry site now says the GenAI conventions “have moved to the OpenTelemetry GenAI semantic conventions repository,” and the client inference page there still marks them with a status of Development.

The conventions treat content differently from metadata. Attributes that carry prompts and completions, such as gen_ai.input.messages and gen_ai.output.messages, have the requirement level Opt-In, and the spec warns that they are “likely to contain sensitive information including user/PII data.” The content capture section states that capturing “model instructions, prompts, completions, retrieval queries, prompt template variables, and memory records is gated by an explicit user opt-in.”

Bifrost’s OpenTelemetry integration emits spans in that shape, with names such as gen_ai.chat and attributes including gen_ai.provider.name and gen_ai.request.model. Warp, however, does not read OpenTelemetry output. Its tools query the gateway’s own logs store. So Warp works with no tracing backend at all, and what it can see is governed by the log store’s content settings, not any exporter’s: “Content is stripped independently at each destination, from that destination’s own setting.”

The tools, and why they are read-only

The Warp documentation lists every tool the agent can call.

The docs then add a sentence that defines the design: “Warp has no tool that changes configuration, sends requests to providers on your behalf, or reads data outside the logs store and governance settings.” The announcement post puts it more briefly.

Warp can look, but it can’t touch.

The choice matters because of what sits in the logs. Gateway logs hold user-written prompts, and an agent that reads them is reading untrusted text. The OWASP Top 10 for LLM Applications names this risk LLM06: Excessive Agency, “the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM.” It lists “direct/indirect prompt injection” among the triggers, and its first mitigations are to minimize the extensions an agent can call and what each can do. Its example of excess is a read extension whose identity has “not only SELECT permissions, but also UPDATE, INSERT and DELETE.” Warp’s tool list is the SELECT-only version. An instruction planted in a logged prompt has no write path to steer Warp toward; its reach is bounded to data the asker could already see. The publication’s guide to the OWASP LLM Top 10 covers the rest of that list.

The post describes three rules every tool follows: read-only, “bounded” (results are capped before they reach the model, so “one careless query can’t dump megabytes of prompts into the context window”), and scoped to the asker. The loop is capped too: eight tool-call rounds by default (max_iterations, 2 to 20). On the last round its tools are removed and it must answer with what it has, and the docs say that answer is marked partial.

A second set of choices targets the plausible invented number. The post states the concern: “An LLM will happily answer a data question from its priors, and the result is a fluent, specific, invented number.” Its countermeasures are mechanical. Log links are checked against the ones Warp’s tools actually returned. Answers with numbers end with the absolute time range the query used. Charts are drawn from query results, and the model “only picks which result to show. It never types the numbers.”

Scope: who sees what

The access and scoping section of the docs says “every tool call runs as the person asking,” and that with Enterprise row-level access control, “Warp sees exactly the logs that person could see on the Logs page, and semantic search results are filtered the same way.” The post’s version: Warp “can never show you data you couldn’t already pull from the logs API yourself.”

Scope also shapes the answer when a question leaves it unstated. The docs set three defaults. A signed-in user with restricted access gets their own traffic. An unrestricted caller, such as an administrator, gets the whole deployment. With no user identity and several teams, customers or business units to choose from, Warp asks which one is meant. Naming a scope in the question (“for the payments team”) overrides the default. On a shared deployment, the post says, “silently picking the widest one gives you a confident number about the wrong thing.”

Enterprise tier. Role-based access control is an Enterprise feature. The Enterprise v2.3.0 changelog adds a Warp RBAC resource: Admin has View and Update, Developer and Viewer have View, and the log-index backfill needs Update. The Warp docs describe a second resource, WarpSession, whose View permission grants use of the chat panel and one’s own history, and whose Delete permission lets a user remove their own conversations. Without dashboard authentication, the docs say, “anyone who can open the dashboard can use Warp,” and every caller counts as the local admin. All conversations then share one owner.

Semantic search over logged conversations

Filters answer “how much” questions; the post calls them “useless for ‘what about’ questions.” For those, the Warp Semantic Log Search entry adds an embedding index. An embedding is a vector of numbers produced by a model so that texts with similar meaning end up close together; a vector store holds those vectors and finds the nearest ones to a query.

The docs list exactly what gets indexed. A log qualifies when it is a chat completion or Responses API request, streaming or not; when it has finished with a status of success, error or cancelled; when its content is logged; and when it is not Warp’s own traffic. For each one, Warp embeds the user input and the assistant output, up to 16 KB of text, and stores filterable metadata next to the vector: provider, model, status, latency, cost, token counts, app, virtual key, user, team, customer and business unit.

Indexing runs two ways. New logs are embedded in the background as they are written; the post says this “never blocks the logging writer or the original inference request.” If logs arrive faster than they can be embedded, the docs say, the queue fills and further logs are dropped from the index with a warning, though they remain in the logs store. Older or dropped logs are added by a backfill, started from the settings page or with POST /api/warp/log-index/backfill and a time range. The backfill checkpoints so it can resume, and only one runs at a time. Progress appears as “Indexing logs for Warp” in the new Background jobs panel, visible only to administrators.

Embedding spaces cannot be mixed. Vectors from two different models are not comparable, so when an operator changes the embedding provider, model or dimension, the docs require a new log_vector_store_namespace, and the gateway rejects the save otherwise.

At query time, according to the announcement’s search section, Warp embeds two to five phrasings of the topic, joins matches back to the log store using the caller’s context, and treats vector metadata “only ever” as a prefilter. Because semantic results are “ranked, not judged,” Warp reads each returned row and drops off-topic ones before counting or quoting anything.

Privacy and the content logging switch

Semantic search carries the clearest privacy trade-off. Building the index means sending logged user prompts and model replies to an embedding model, then storing the resulting vectors with user and team identifiers attached. With a hosted embedding API, that is a second copy of production conversation text leaving the gateway, beyond the original model call. The agent model sees content too: get_log_detail returns a content preview into Warp’s context.

Three details in the docs shape how large that trade-off is. First, embedding calls made while indexing “skip the plugin pipeline, so they do not appear on the Logs page and are not subject to governance.” A backfill reports its embedding spend instead. Second, the operator chooses the embedding provider and model. Third, and most usefully, content logging acts as the off switch: “Logs with content logging turned off are skipped.”

That is why the release’s per-virtual-key content logging control matters to Warp. Virtual keys now carry a tri-state disable_content_logging. Left unset, a key inherits client.disable_content_logging. Set to true, the key’s request and response content stays out of the log store and is stripped from OpenTelemetry export. Set to false, content is kept even when the client setting turns it off. A deployment can keep content, and Warp search, for internal tooling while excluding a customer-facing key that carries regulated data; metadata questions about that key still work.

The content logging docs add two cautions that apply here. Attribution identifiers such as user, team and virtual key “are metadata, not content” and “are never removed by a content setting,” which means they still appear in vector metadata for indexed logs and in log rows for content-disabled ones. And a per-request header, x-bf-disable-content-logging, can override the client and key settings in either direction, but only when client.allow_per_request_content_storage_override is enabled, which is off by default.

Warp’s own chat transcripts are kept per user for history_retention_days (30 by default), capped at 100 per owner, a retention the docs call “independent of log retention.”

The agent’s own cost and governance

Warp’s model traffic is metered like everyone else’s. The cost and governance section says Warp’s calls appear on the Logs page with the app name Warp and the user agent bifrost-warp/1, MCP tools are never attached to Warp’s calls. If a budget, rate limit or model restriction applies to the person asking, Warp reports that its call was refused and why, with the codes budget_exceeded, rate_limited or model_blocked. The changelog adds access_denied to that list.

Warp’s own requests are excluded from its log index, so “asking about Warp does not pollute semantic search.”

Administrators pick the model. The settings reference shows a default provider and model, an optional api_key_id that pins Warp to one provider key (the docs suggest this “to keep Warp’s spend separate from tenant traffic”), up to 20 additional_models users can switch between, temperature from 0 to 2, reasoning_effort and a system_prompt_suffix for deployment conventions that “cannot replace the built-in instructions.”

Teams that already use virtual-key budgets, as described in LLM cost control with an AI gateway, get a plain-language way to check a key against its limit, and the assistant’s own spend lands in the same ledger it reports on.

Turning it on: flags, migrations and upgrade notes

The master switch is the warp feature flag. While it is off, the docs say, “every /api/warp route returns 404,” new logs are not indexed, and the dashboard hides the launcher, chat panel and settings page. The v2.3.0 upgrade notes state that Warp is “on by default in OSS; set feature_flags.flags.warp.enabled: false to keep it hidden.” Enterprise deployments start with the flag off and enable it in Settings, through PUT /api/feature-flags/warp, or in config.json.

The flag alone does nothing visible beyond exposing setup. According to the requirements table, Warp answers only when a logs store exists, a vector store is connected, a provider is configured for the agent model, and a provider is configured for the embedding model. The Enable Warp switch stays disabled until a vector store is connected.

The database migrations are additive. The config store gains a warp_config table and its settings columns. The log store gains warp_conversations and warp_messages, reversible only while empty, plus a concurrent index on warp_conversations(updated_at DESC). The changelog advises large deployments to upgrade in a low-traffic window, since migrations run on startup and can cause lock contention on PostgreSQL.

Open questions

Index lifecycle. The docs describe chat history retention and log retention as independent, and describe how a new embedding namespace starts empty. They do not describe how long vectors persist in the old namespace, or whether index entries are removed when the underlying logs expire. Operators with deletion obligations will want to confirm that against their vector store’s own retention controls.

Answer quality. The read-only tools, verified links and tool-drawn charts constrain how wrong an answer can look. They do not guarantee the agent picked the right query. Bifrost has published no evaluation of Warp’s answer accuracy, and the quality will vary with the model an administrator selects.

Embedding cost at scale. Every indexed log costs embedding tokens, and those calls bypass governance. Teams with high log volume will want to estimate that spend before indexing a long history.

What the release signals

Most natural-language assistants for telemetry sit in the observability backend, downstream of the systems they describe. Warp puts the assistant at the point where model traffic is attributed, priced and governed, and inherits that layer’s access model. The notable design decision is not that an LLM answers questions about logs, which several vendors offer, but the deliberate narrowness: thirteen tools, none of which write, each running as the asker, with the numbers drawn from queries rather than from the model. For an agent whose input is a store of production prompts written by strangers, that narrowness is the security model. The open work is on the data side. Semantic search makes the content of AI traffic queryable in a way it was not before, and v2.3.0 pairs it with per-key controls that decide which conversations ever reach the index. How operators set those switches will determine whether Warp is mainly a cost dashboard that talks, or a search engine over everything their users have said to a model.