Probe0 vs Open WebUI
Open WebUI is the front door for humans typing into a browser. Probe0 is the pipe your coding agents already talk through, so the traffic that actually runs up a bill gets cached, routed and capped before it leaves the machine.
A self-hosted, provider-agnostic chat platform and workspace that sits in front of Ollama and OpenAI-compatible backends, built for teams of humans in a browser.
| Feature | Probe0 | Open WebUI | Edge |
|---|---|---|---|
| Primary surface | Local proxy for agent CLI traffic | Self-hosted chat UI for people | Even |
| Covers Claude Code, Codex and Cursor | One proxy and one cert, no per-tool config | Not the intended path; it expects a browser | Probe0 |
| Response caching | Exact cache on local disk, hits never hit the network | No response or semantic cache; helps backends do KV caching | Probe0 |
| Cache safety for tool calls | Semantic cache refuses to match anything with tool calls | No semantic cache to guard | Probe0 |
| Model routing | Cost tiering and local-first routing with cloud retry | random.choice() across identical Ollama endpoints | Probe0 |
| Spend limits | Hard per-run and per-day cap that warns then pauses | Analytics dashboard only; hard caps are an open request | Probe0 |
| Cost attribution | Ledger of model, tokens, real cost, latency, per process | Message and token volume per user, for estimation | Probe0 |
| Governed chat for a team | None. One machine, one person, sign-in via Google or GitHub | RBAC, SSO, OIDC, LDAP, SCIM, audit logs, shared RAG | Competitor |
| Setup for one developer | Install, trust the cert, done. No services to run | Container plus Redis and a vector DB once you scale out | Probe0 |
Open WebUI is the better buy for exactly one job, and it is very good at it: handing an organisation a governed chat product, with RBAC down to per-resource grants, SSO through OIDC or LDAP, SCIM provisioning, audit logs, shared knowledge bases, a pipelines framework and OpenTelemetry, which is how CUNY runs it for roughly 500 users. That is not the job a developer running coding agents on a Mac has. Their bill comes from Claude Code, Codex and Cursor firing hundreds of API calls a session with prompts nobody typed, and the only place to intervene in that traffic is on the machine it leaves from. Probe0 sits there. One local proxy and one certificate, installed once, and every agent CLI on the box routes through it with no per-tool configuration.
The gap opens where the spend actually happens. An AI coding agent does not sit in a browser, and none of that traffic passes through a chat front-end unless you deliberately wire it there, at which point there is still no per-request policy layer waiting for it. Open WebUI's Analytics dashboard tells you what a model cost after the fact. Native per-user or per-group hard limits are a long-standing open request, issues #6692 and #23323, and the workaround its own largest deployment describes is bolting LiteLLM on the side with budget sync scripts. There is no response cache, so every repeated call is a call. Routing across multiple Ollama instances is literally random.choice() over identical model IDs, with no notion of cost or capability, and failover is timeout-driven until you tune it.
Probe0 takes the other axis: one developer, one machine, the traffic their agents generate. It runs locally, and there is no Probe0 server for your prompts to travel to. Every module is switchable on its own and reports what it saved, so you can judge each one instead of trusting a headline number. Local Routing sends work to a model already loaded in Ollama or LM Studio and retries weak answers on the cloud. Model Tiering tries the cheap model first. The Exact Cache lives on local disk and never touches the network, and the Semantic Cache uses a local vector index behind a strict similarity floor and refuses to match anything carrying tool calls, because a wrong hit there corrupts a run rather than merely embarrassing you. Request Coalescing collapses simultaneous identical calls into one upstream. Spend Guard enforces a hard cap per run and per day, warning first and then pausing. Recording keeps a full ledger of model, tokens, real cost, latency and which process made each call, which is also how it can tell you when your plan tier is above what you actually use.
The verdict
Run Open WebUI if the thing you owe someone is a chat product for a team, with identity, RBAC, shared knowledge and audit logs. For a developer on macOS whose bill comes from coding agents rather than from typing into a chat box, Probe0 is the one that touches the money: caching that never reaches the network, local-first routing, per-process cost attribution and a cap that pauses the run instead of emailing you about it.
Questions
- Can Open WebUI act as a proxy for Claude Code or Cursor?
- Not in the way an LLM proxy does. Open WebUI consumes OpenAI-compatible endpoints to power its own chat interface; it is not designed as an endpoint you point an AI coding agent at, and it has no per-request cost policy layer for that traffic. Probe0 intercepts coding agent CLI traffic on the machine instead.
- Does Open WebUI cache LLM responses to cut cost?
- No. Redis is used for session state, WebSocket coordination and multi-worker config, not for deduplicating model calls, and there is a short cache for external API responses only. Setting RAG_SYSTEM_CONTEXT helps the backend do KV prefix caching; it does not stop a call from being made.
- Can I set a hard spend limit per user in Open WebUI?
- Not natively. The Analytics dashboard shows message and token volume for cost estimation, but per-user and per-group hard caps are open feature requests, and community trackers such as Dartmouth's pipes-based tool cannot enforce limits at the platform level. Probe0's Spend Guard enforces a cap per run and per day, warning and then pausing.
- Is Probe0 an Open WebUI alternative?
- Only if what you wanted from Open WebUI was LLM cost control rather than a chat workspace. Probe0 has no chat UI, no multi-user accounts and no RBAC, and it is macOS-only in private beta. It replaces the cost-and-routing part of the job for a single developer's coding agents, not the team platform part.