Experiential's Agent Gateway Can Only Govern the Traffic You Send It

The open-source router promises per-agent control over models and spend. The most popular coding agents can route around it, and its own docs say so.

Every agent gateway makes the same promise: put us in the middle and you get one place to decide which agent uses which model, how much it can spend, and what gets logged. The promise has a hidden condition. The gateway has to actually be in the middle.

Experiential, which sat at #7 on Trendshift's daily board on the morning of October 3, is a useful case study because its README is unusually honest about where that condition breaks. It describes itself as "an open source gateway and router for agent workflows" that lets you "control which users and agents can use which models, for which use cases, and how much they can spend." A few sections later, it describes a second feature, Capture, that exists precisely because some of the most-used agents never pass through the gateway at all.

That second feature tells you more about agent governance in 2026 than the first.

What Experiential is

The pitch has three parts, quoted from the README:

"Use hosted, BYOK, and local models through one OpenAI-compatible API."
"Control which users and agents can use which models, for which use cases, and how much they can spend."
"Turn production traffic into a custom router or model optimized for quality, speed, and cost."

Install is pip install experiential, and the CLI is exp. The setup wizard walks through providers and models and, per the README, "shows defaults for the public alias, identity, and $50.00 command budget" before it issues a key. You pick a public alias such as opus-5, export the key as EXP_GATEWAY_KEY, and point clients at a local endpoint like http://127.0.0.1:8000/v1/chat/completions. A hosted version runs at platform.experientiallabs.ai with OpenAI-compatible and Anthropic Messages APIs.

The third part is the ambitious one. exp build turns collected traces into a project, and exp optimize model fine-tunes an open model you own using Tinker. The idea is that your agents' real traffic becomes training data for a cheaper router or a smaller model tuned to your workload.

How a coding agent gets into the gateway

The coding-agents docs page shows the mechanics, and they are the standard ones.

For Claude Code, you set three environment variables:

export ANTHROPIC_BASE_URL="https://api.experientiallabs.ai"
export ANTHROPIC_API_KEY="xpl_..."
export ANTHROPIC_MODEL="<slug>"

For Codex, you add a provider block to ~/.codex/config.toml with base_url = "https://api.experientiallabs.ai/v1", env_key = "EXPLABS_API_KEY", and wire_api = "responses", then run codex -m <slug> -c model_provider=explabs.

In both cases the agent authenticates to the gateway with an API key, and the gateway forwards to whatever model the alias maps to. That is where budgets, model allowlists, and logs can apply, because that is the only place the gateway sees a request.

Now read the warning on the same page. It tells you to use ANTHROPIC_API_KEY and never ANTHROPIC_AUTH_TOKEN, because an existing claude.ai sign-in can outrank the auth token and send the gateway an OAuth token instead.

Sit with that for a second. On a developer laptop that is already signed in to claude.ai, set the wrong variable and the credential Claude Code presents is the user's own login, not the gateway key you issued. The per-key identity and budget you configured are no longer the ones in play. One environment variable decides whether your governance applies.

Capture: the feature that admits the gap

The README describes Capture as designed "to collect supported traces from the Codex and Claude Code desktop apps using your existing ChatGPT or Claude subscription," with the requests themselves going directly to OpenAI or Anthropic. It labels Capture experimental, says macOS network reliability is still under investigation, and lists its requirements as macOS, Python 3.13 or newer, and approval for an extension and a certificate.

Every part of that description matters.

Using your existing ChatGPT or Claude subscription means this is traffic paid for by a flat-rate plan, not an API key. The coding-agents docs only describe API-key routing, and I found nothing in what I read that routes subscription traffic through the gateway.

Requests going directly to OpenAI or Anthropic means the gateway is not in the path. It cannot reject a call, swap the model, or stop spend, because the call never reaches it.

Approval for an extension and a certificate means that to see that traffic at all, Experiential asks the user to approve an extension and a certificate on their Mac. The README does not spell out the mechanism, but a certificate approval in a traffic-collection tool is a significant grant, and it deserves the same scrutiny you would give any local proxy.

So Capture records. It does not govern. For the subscription-signed desktop apps, which are how many developers actually run these agents, Experiential can tell you afterward what happened. It cannot decide beforehand what is allowed to.

Why this matters past one repo

None of this is a flaw unique to Experiential. It is the shape of every gateway, and Experiential is simply candid about it.

Cloudflare made the same bet from the other direction on October 2, when it put web search inside AI Gateway so that "requests show up in your normal AI Gateway observability logs." That is valuable for exactly the traffic that goes through AI Gateway, and invisible for traffic that does not.

The lesson for anyone building agent governance: a gateway's coverage is a property of your clients' configuration, not of the gateway. A team can roll out a router with careful per-agent budgets and still have most of its real agent usage flowing around it on personal subscriptions and stale environment variables. The dashboard looks complete because it shows everything it saw.

Put this into practice

If you are evaluating Experiential, or any gateway, start with coverage before features.

1. Run it locally first. pip install experiential, then exp, accept the wizard's defaults, and point one agent at the local endpoint. Confirm a request shows up before you configure anything else.

2. Use the right variable. For Claude Code, set ANTHROPIC_API_KEY, as the docs say, not ANTHROPIC_AUTH_TOKEN. Then sign out of claude.ai in a test environment and confirm the agent still works, which proves it is not leaning on the OAuth session.

3. Test that the budget bites. The billing docs say that when a credit balance, spend limit, or budget runs out, calls fail with HTTP 429 insufficient_quota, with the reason in the message, and that retrying does not clear it. Set a tiny budget on a test alias, exceed it, and write down what your agent actually does with that 429. Some agents retry, some stop, and some surface the error to the user. You want to know which before a real budget runs dry mid-task.

4. Inventory subscription usage separately. Ask your team which agents run on personal ChatGPT or Claude plans. Those sessions sit outside any API gateway. Govern them through the vendors' own admin and managed settings, not through the router.

5. Treat Capture as a separate trust decision. If you want it, run it on one machine, read what the extension and certificate are allowed to do, and decide whether that grant is acceptable for your environment.

6. Check telemetry. The README says "Anonymous aggregate PostHog product telemetry is enabled by default" and that it "never includes prompts, traces, actions, observations, paths, model names, credentials, or raw customer content." If your policy is off-by-default, run exp config telemetry disable.

Honest limitations

Several things I could not pin down.

Budget enforcement lives on the hosted billing page (a 429 insufficient_quota when a limit runs out, plus email alerts at thresholds), not in the open-source README. I did not confirm that the self-hosted gateway behaves the same way, and that matters, since "how much they can spend" is one of the three headline promises.

The release story is muddy. Main's pyproject.toml says 0.7.149, one summarized read of the releases feed this morning listed v0.7.149 dated October 3, a rendered releases page showed an older tag, and PyPI's page showed 0.7.115 from September 24. Check which version you are installing.

Trendshift's one-line description called the project a world-model harness for simulating agent environments. The README does not support that, and the project also links a Hugging Face dataset of terminal-task traces, so it may have changed direction recently. Read the current README rather than any directory listing.

I have not run Capture, so I cannot tell you how it intercepts traffic, what it stores, or where. Everything above about Capture comes from the README's own description.

And the "custom router from your traffic" promise is only as good as the traffic it sees. If half your agent usage runs on subscriptions outside the gateway, the router learns from the half that does not.

What to do with this

Before you pick a gateway, draw the map. List every agent your team runs, how each one authenticates, and where its requests actually go. Mark the ones that would pass through a gateway with an API key and the ones that would not.

Experiential may well be the right tool for the first group. The second group is the question the gateway cannot answer for you, and the README, to its credit, does not pretend otherwise.

Sources: experientiallabs/experiential README · Experiential coding-agents docs · Experiential billing docs · PyPI: experiential · Cloudflare Web Search API · Trendshift

Medium metadata

Title: Experiential's Agent Gateway Can Only Govern the Traffic You Send It
Subtitle: The open-source router promises per-agent control over models and spend. The most popular coding agents can route around it, and its own docs say so.
Tags: AI Agents, LLM Gateway, Claude Code, Open Source, AI Security
Canonical URL: fervorai.dev article URL
Reading time: about 8 minutes