Tavern OS
Eliza agents,powered by BitRouter
Build, orchestrate, and ship autonomous agents — each one running on a smart router that picks the provider, enforces guardrails, and tracks every cost.
Watch every call, as it happens
Provider, latency and cost for every request — streamed in real time.
A control plane for ElizaOS agents
You build autonomous ElizaOS agents in a no-code builder. Instead of letting each agent call OpenAI or Anthropic directly, every agent is wired to run on top of BitRouter — a local LLM router that proxies the call, picks a provider, enforces guardrails, and records the exact cost and latency. The result: a fleet of agents you can actually see, price, and govern from one dashboard.
ElizaOS 1.7 + BitRouter alpha.9, wired together — not a reimplementation of either.
Each agent gets an isolated, budget-capped BitRouter key the moment it's created.
Provider, tokens, latency and spend recorded per request and streamed live.
The stars of the show
Neither is mocked or wrapped in marketing — both run for real in this app.
elizaOS
Your agentic operating system
An open-source TypeScript framework for building autonomous AI agents. Agents are defined by character files and extended with plugins; the runtime is model-agnostic.
- Character files: name, bio, system prompt, plugins & settings
- Plugin model — we load plugin-openai, plugin-bootstrap & plugin-sql
- Embedded here as real @elizaos/core runtimes, one per agent
- plugin-openai resolves its base URL + key via runtime.getSetting() — the hook we use
BitRouter
Agent-native LLM router (Rust)
A local-first daemon that proxies LLM calls behind a single OpenAI-compatible endpoint at localhost:8787, with failover, guardrails, virtual keys and per-request cost tracking.
- 9+ providers behind one API — OpenAI, Anthropic, Google, Bedrock, OpenRouter…
- Virtual keys via `bitrouter key sign` — wallet-signed, model-scoped, budget-capped
- Per-request spend, latency, provider & status from its observation log
- Guardrails & spend policies enforced at the router, before the provider
Agents call LLMs blind
Wire an agent straight to a provider and you get no failover, no per-agent cost visibility, no guardrails, and no idea which model served a request. Keys leak across agents and spend is impossible to attribute.
- One hardcoded provider, no fallback
- Zero per-agent cost attribution
- No guardrails or spend caps
- Shared keys, no isolation
Route every call through BitRouter
Each agent points its model base URL at BitRouter and gets its own virtual key. Calls fail over across providers, every request is cost-tracked and guarded, and the dashboard shows exactly which provider served what — and for how much.
- Multi-provider routing + failover
- Per-agent cost, routing & traces
- Guardrails + budget caps per key
- One isolated virtual key per agent
Every agent is a character file
The no-code builder writes a real ElizaOS character. The one line that changes everything: its model base URL points at BitRouter, authed with a virtual key we mint just for that agent. No provider SDKs, no shared secrets — the agent never talks to a provider directly.
What happens on every message
The backend mints a BitRouter virtual key scoped to the agent's model with a μUSD budget, and writes its ElizaOS character with OPENAI_BASE_URL pointed at BitRouter.
The ElizaOS runtime composes the prompt and calls its model — the request goes to BitRouter at :8787, never to the provider directly.
It verifies the virtual key, applies routing rules + guardrails + the budget cap, and forwards to the chosen provider (OpenAI / Anthropic / Google).
BitRouter records which provider served it, the token usage, latency and computed spend, then returns the completion to the agent.
The trace streams to the dashboard over WebSocket — provider, status, latency and cost, attributed to that agent.
How it works
From an empty form to a live, fully-observable agent in three steps.
Describe your agent
Name it, set a personality and system prompt, pick a model and plugins. The backend writes an ElizaOS character file.
We mint a virtual key
On creation, the backend mints one BitRouter virtual key for the agent and points its model base URL at BitRouter.
Chat & watch it flow
Every message runs ElizaOS → BitRouter → provider → back. The dashboard shows provider, latency and exact cost.
It's real, not a demo shell
The parts that usually get faked in a hackathon build actually run here.
Real sibling daemon
The backend downloads, configures and supervises the actual BitRouter binary (pinned v1.0.0-alpha.9) as a child process.
Wallet-signed virtual keys
Each agent's key is a JWT signed offline by an OWS operator wallet, scoped to its models with a spend cap.
BYOK, routed locally
Your provider keys, your spend — BitRouter routes in Bring-Your-Own-Key mode with no third-party settlement.
Observation-log telemetry
Provider, model, status and latency_ms are parsed straight from BitRouter's per-request observation log.
Works offline (mock mode)
No provider key? Routing, virtual keys, cost and latency are still real — only the upstream model is simulated.
One swappable module
Every BitRouter interaction lives in one wrapper module, so the alpha is easy to fix or upgrade in place.
Everything, observable
No-code agent builder
Spin up real ElizaOS runtimes from a form — character, system prompt, model, plugins.
Multi-provider routing
BitRouter proxies an OpenAI-compatible endpoint with failover across 9+ providers.
Per-agent virtual keys
Each agent is isolated behind its own minted BitRouter key with a budget cap.
Per-request cost & latency
See which provider served each call, the token usage, and the exact cost.
Guardrails
Spend limits and policy guardrails enforced at the router, surfaced as dashboard hits.
Live traces
Stream every call as it happens over WebSockets — routing, status, and timing in real time.
Questions, answered
Do I need API keys to try it?
No. It boots in mock mode — a local OpenAI-compatible upstream stands in for the provider, while BitRouter routing, virtual keys, cost and latency stay 100% real. Add a key to get live model answers.
Is this really ElizaOS, or a lookalike?
Real. The backend instantiates @elizaos/core AgentRuntimes (with plugin-bootstrap, plugin-sql and plugin-openai). Each agent you create is an actual ElizaOS character running in-process.
How does an agent end up using BitRouter?
On creation we mint a BitRouter virtual key and write the agent's character so plugin-openai's OPENAI_BASE_URL points at BitRouter (:8787) with that key. ElizaOS reads it via runtime.getSetting() — no provider SDK in the agent.
Where do the cost numbers come from?
Token usage from the response × per-model pricing from BitRouter's /v1/models catalog (with public list-price fallbacks). Provider, latency and status come from BitRouter's observation log.
Which providers can it route to?
Anything BitRouter supports in BYOK mode — OpenAI, Anthropic, Google and more. The agent always speaks the same OpenAI-compatible protocol; BitRouter handles the rest.
Is it production-ready?
BitRouter is alpha (pinned to v1.0.0-alpha.9) and wrapped in a single module so it's easy to upgrade. The app itself is an MVP focused on the create → route → observe loop.
Ship your first routed agent
Create an ElizaOS agent, chat with it, and watch the provider, cost, and latency land on your dashboard in real time.