dario

Your Claude and ChatGPT subscriptions each work in exactly one place.
dario makes them work everywhere — at subscription pricing, not per-token API bills.

One local endpoint. Every AI tool you own. The subscriptions you already pay for.

_{npm i -g @askalf/dario · 0 runtime deps · SLSA-attested every release · nothing phones home · ~33k lines you can read in a weekend · independent, unofficial, third-party (DISCLAIMER.md)}

_{Start · Your tools · Routing · Two plans · Pool · Drift · Trust · Risk · Commands · FAQ · Coming back after a while?}

You're already paying $20, $100 or $200 a month for Claude,¹ or for a ChatGPT plan. Then Cursor wants an API key. Aider wants an API key. Cline, Continue, Zed, your own scripts — every one of them bills you again, per token, while the plan you bought sits idle in the one app it shipped with.

dario is one local endpoint that routes all of them through the plans you already pay for. Point any Anthropic- or OpenAI-compatible tool at http://localhost:3456 and you're done. No per-tool config, no second bill, and when one plan hits its limit the other one takes the request.

Start in 60 seconds

# 1. Install
npm install -g @askalf/dario

# 2. Log in to your Claude subscription (Pro, Max 5x, or Max 20x)
dario login                 # or `dario login --manual` for SSH / headless

# 3. Start the local proxy
dario proxy                 # separate terminal or background

# 4. Point any Anthropic-compatible tool at it
export ANTHROPIC_BASE_URL=http://localhost:3456
export ANTHROPIC_API_KEY=dario

That's the whole setup. Every tool that honors those env vars now runs on your subscription. OpenAI-shaped tools use OPENAI_BASE_URL=http://localhost:3456/v1 instead, same key.

Works with: Claude Code, Cursor, Aider, Cline, Roo Code, Kilo Code, Continue.dev, Zed, OpenHands, OpenClaw, Hermes, Codex CLI, the Claude Agent SDK, the Anthropic and OpenAI SDKs, curl, your own scripts. Per-tool snippets are one section down.

Prefer Docker? ghcr.io/askalf/dario:latest — multi-arch (amd64 + arm64), published from the same workflow as every npm release (guide). Something off? dario doctor prints one paste-ready health report.

Point your tools at it

Two base URLs, one key. Anthropic-shaped clients talk to http://localhost:3456; OpenAI-shaped clients talk to http://localhost:3456/v1. The key is dario (any value works until you set DARIO_API_KEY, which then has to match).

export ANTHROPIC_BASE_URL=http://localhost:3456
export ANTHROPIC_API_KEY=dario
claude

dario proxy                                     # terminal 1
cloudflared tunnel --url http://localhost:3456   # terminal 2 → https://<random>.trycloudflare.com

export ANTHROPIC_BASE_URL=http://localhost:3456
export ANTHROPIC_API_KEY=dario
aider --model sonnet        # or opus, haiku, any claude-* id

# ~/.continue/config.yaml
models:
  - name: Claude Sonnet (dario)
    provider: anthropic
    model: claude-sonnet-5
    apiBase: http://localhost:3456
    apiKey: dario

{ "language_models": { "anthropic": { "api_url": "http://localhost:3456", "version": "2023-06-01" } } }

export LLM_BASE_URL=http://localhost:3456
export LLM_API_KEY=dario
export LLM_MODEL=anthropic/claude-sonnet-5

export ANTHROPIC_BASE_URL=http://localhost:3456
export ANTHROPIC_API_KEY=dario
openclaw "task description"

export OPENAI_BASE_URL=http://localhost:3456/v1
export OPENAI_API_KEY=dario

dario backend add openai     --key=sk-proj-...
dario backend add groq       --key=gsk_...    --base-url=https://api.groq.com/openai/v1
dario backend add openrouter --key=sk-or-...  --base-url=https://openrouter.ai/api/v1
dario backend add local      --key=anything   --base-url=http://127.0.0.1:11434/v1

import Anthropic from "@anthropic-ai/sdk";
const client = new Anthropic({ baseURL: "http://localhost:3456", apiKey: "dario" });

import anthropic
client = anthropic.Anthropic(base_url="http://localhost:3456", api_key="dario")

curl http://localhost:3456/v1/messages -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-5","max_tokens":256,"messages":[{"role":"user","content":"Hello!"}]}'

curl http://localhost:3456/v1/chat/completions -H "content-type: application/json" \
  -d '{"model":"gpt-5.5","messages":[{"role":"user","content":"Hello!"}]}'

docker volume create dario-config
docker run --rm -it -v dario-config:/home/dario/.dario ghcr.io/askalf/dario:latest login --manual
docker run -d --name dario -p 3456:3456 -v dario-config:/home/dario/.dario \
  -e DARIO_API_KEY="$(openssl rand -hex 32)" ghcr.io/askalf/dario:latest

Something not listed? If it reads ANTHROPIC_BASE_URL or OPENAI_BASE_URL, or has a "Base URL" field, it works. The compatibility matrix says which tools are exercised end-to-end, which are inferred from a shared code path, and which are untested — one honest cell per tool.

What it does with a request

You point every tool at one URL. dario reads each request, decides which plan or backend owns it, and forwards it in that backend's native protocol.

The tool doesn't know. The backend doesn't know. dario is the seam.

The full Claude lineup, autodetected. Fable 5, Opus 5, Sonnet 5 and Haiku 4.5, plus [1m] long-context variants on every family except Haiku, by full id (claude-opus-5) or shortcut (fable / opus / sonnet / haiku; append 1m for the long-context form; opus48 / opus47 / opus46 / sonnet46 pin a generation and never float). GET /v1/models reads Anthropic's live catalog (TTL-cached, baked fallback offline), so a new model resolves the day it lands with no dario release, and the model-specific request shape is applied automatically. Families pulled upstream are filtered from both the live catalog and the fallback, so /v1/models never advertises a model that 404s. A name no provider lists at all, such as a ChatGPT slug your account doesn't have or a typo that belongs to no family, is refused locally with 400 and x-dario-upstream-rejection: model_unroutable instead of spending a pool request on an upstream 404. The guard steps aside for claude-* names (Anthropic's own 404 stays authoritative there), for requests under a --model / --fast-model override, for upstream-API-key mode, and for the legacy OpenAI names the built-in map translates.

Two plans, one endpoint

Your ChatGPT plan, on both endpoints

A ChatGPT Plus or Pro plan is served on both of dario's endpoints: any client that speaks /v1/chat/completions can use it (Codex CLI, the OpenAI SDKs, your scripts), and so can any client that speaks /v1/messages (Claude Code, the Anthropic SDKs, agent runtimes). The harness never needs to know which subscription is behind it.

dario add altman            # prints an authorize URL; paste the redirect URL back
dario codex list
dario codex remove altman

dario add altman names whose plan you are attaching; dario add amodei attaches a Claude account instead. The browser lands on a localhost page that doesn't load — expected, nothing is listening there. Copy the whole address bar and paste it at the prompt; dario reads the code out of it.

curl localhost:3456/v1/models | jq -r '.data[].id'
curl localhost:3456/v1/chat/completions -H 'content-type: application/json' \
  -d '{"model":"gpt-5.5","messages":[{"role":"user","content":"hi"}]}'

# same subscription, Anthropic wire shape — this is what Claude Code speaks
curl localhost:3456/v1/messages -H 'content-type: application/json' \
  -d '{"model":"gpt-5.5","max_tokens":64,"messages":[{"role":"user","content":"hi"}]}'

Model names are discovered, not hardcoded. The set a ChatGPT subscription may use is per-account and moves; dario asks the backend which models this account lists, caches the answer, and advertises them on GET /v1/models. Anything not on that list (gpt-4o and friends) still routes to a configured API-key backend as before. codex:<model> / chatgpt:<model> forces the route.

Streaming, tool calls and tool-result round trips work on both shapes, and chat-shape image_url parts are carried as Responses input_image parts with detail preserved: dario translates chat/completions or Messages into the Responses API the subscription backend speaks, and translates the stream back into chat.completion.chunk or Anthropic message events. There is no /v1/responses inbound yet. The Codex backend does not accept every chat field, so response_format, stop, n, logprobs, stream_options and the sampling parameters temperature, top_p, max_tokens, max_completion_tokens are intentionally lossy; with --verbose, dario reports each field that does not reach Codex once per process. Codex accounts live in ~/.dario/codex-accounts/, separate from the Claude pool.

Prompt caching: the backend caches prompt prefixes of 1,024 tokens and up on its own; what dario adds is the prompt_cache_key that routes same-prefix requests to the cache that holds them, the way the Codex CLI does with its session id. A chat/completions client that sets its own key keeps it; an Anthropic-shape request gets one per Claude Code session (a hash of metadata.user_id, never the raw ids); anything else is keyed on its model, instructions and tool names, so repeated system prompts from any caller land together. Cached tokens come back as prompt_tokens_details.cached_tokens on chat/completions and as cache_read_input_tokens on /v1/messages, and show up in /analytics and the -v usage line like a Claude request's do.

Failover between subscriptions

Two consumer plans, no API keys, and neither one able to take you down on its own.

dario proxy --pool-fallback=gpt-5.6-sol,claude-sonnet-5

That is a chain, read left to right; each provider takes the first entry it can actually serve. Prefix every entry with a tier and the same flag becomes a tier map: --pool-fallback=haiku:gpt-5.6-luna,sonnet:gpt-5.6-terra,opus:gpt-5.6-sol picks one rung per request from the tier of the model asked for (default: catches the rest, otherwise the first rung), so heartbeat work on Haiku never overflows onto a flagship. That shipped in 6.0.17, the same day a Haiku-tier fleet spent 79% of a weekly allowance doing exactly that. When the Claude pool is drained or cooling, the request is served as gpt-5.6-sol from your ChatGPT subscription. When the subscription is rate-limited or down, the request is handed back to the Claude pool as claude-sonnet-5. Every substituted response carries x-dario-pool-fallback: <model> — a silently swapped model family is exactly the surprise this project exists to avoid.

A single-entry chain is one-way and means what it always meant, so an existing config is unaffected. Failover is opt-in: without --pool-fallback, a drained pool still returns its honest 429/503. Only a 429 or 5xx fails over; a 400 surfaces, because a bad request that fails over just reproduces itself on the other provider and buries the real cause. A 429 also cools that provider for a bounded interval, its retry-after if it sent one and 60 s otherwise, never longer than 15 min, and an entry that already declined is not asked again within the same request. When every entry is cooling, the request ends on one honest 429 with a retry-after instead of a retry storm. The Claude entry has to be a model the pool can actually serve, checked positively against the live catalog, so a typo can't trade a recoverable 429 for an unrecoverable 404.

dario doctor tells you which of these you are actually in:

[ OK ]  Failover   symmetric: gpt-5.6-sol → claude-sonnet-5, across 1 Codex account
[WARN]  Failover   armed (gpt-5.6-sol) but INERT — no Codex account and no backend
                   to fall back to. Add one: `dario add altman`

That warning is the whole reason the check exists. Armed with nothing to fall back to is green on every other check and incapable of doing anything.

[!NOTE] Upgrading from v5? Nothing to do. Every v6 feature is opt-in and a single-value --pool-fallback behaves exactly as it did. CHANGELOG

Shadow compare

Once either subscription can serve either wire shape, the interesting question stops being can I reach GPT and becomes which of these is better at my work. Benchmarks answer that badly. Your own traffic answers it well.

curl localhost:3456/v1/messages \
  -H 'content-type: application/json' \
  -H 'x-dario-compare: gpt-5.6-sol' \
  -d '{"model":"claude-opus-5","max_tokens":1024,"messages":[…]}'

You get the Claude answer, exactly as you would have. Beside it, dario runs the same prompt past gpt-5.6-sol and writes both to ~/.dario/compare/<timestamp>-<model>.json, in your own wire shape, so you are comparing like with like. The comparison cannot degrade the request it observes: it only reads bytes already on their way out, your request is never held open for it, and a comparison that fails, times out or has nowhere to go is dropped with the record still written. Both sides are stored as raw payloads, because extracting text is where a bug would quietly make two answers look more alike than they are.

Many seats, one endpoint

Every dario is a pool. A plain dario login is a pool of one; there is no separate mode to switch on. Hold more than one seat — a personal Max and a work Max, a couple of Pros, team seats — and the same localhost:3456 routes every request to whichever seat has the most headroom, live, per request.

dario accounts add work
dario accounts add personal
dario proxy

Three things it does that a round-robin doesn't:

• Per-model headroom routing. Anthropic meters each model family separately: a 5h bucket, a 7d bucket and a per-model 7d_<family> bucket. dario reads all of them off every response and routes each request by the bucket that governs it — an Opus call to the seat with Opus room, a Sonnet call to the seat with Sonnet room, independently. Plan tiers mix freely; dario cares about headroom, not tier.
• Session stickiness. Claude's prompt cache is scoped to {account × cache key}, so rotating a long conversation across seats on headroom alone re-pays cache-create every turn, a 5–10× token-cost multiplier on the cached portion. dario pins each conversation to one seat (hashed from its first message, deterministic) for the life of the session and rebinds only when that seat is exhausted.
• In-flight 429 failover. A seat hits its wall mid-request and dario retries the same request against the next-best seat before your client ever sees an error. The sticky binding follows, so the next turn doesn't re-select the cold one. A seat parked on a 429 rejoins the pool on its own when its window resets.

--pool-strategy=fill-first concentrates new conversations on one seat until it drains, for primary/backup setups. Refresh tokens expire about 28 days after the original grant regardless of rotation, so every seat's grant age is tracked and surfaced in dario accounts list, dario doctor and GET /accounts before it becomes a silent outage. Provision over HTTP with the headless admin API; pin one request to one seat with dario accounts check <alias> (admin API required: DARIO_ADMIN=1 and a DARIO_ADMIN_TOKEN). Internals and the live /accounts + /analytics endpoints: multi-account-pool.md; covered end-to-end by test/pool-e2e.mjs.

Watch it happen

Type dario with no arguments for a full-screen control panel: live request stream, per-model burn rate, rate-limit utilization per seat, billing-bucket breakdown, and an in-place config editor that writes ~/.dario/config.json. Pure ANSI, zero new runtime deps. Tab moves between tabs, r refreshes, R resumes a halted overage guard, q quits.

_{Both screenshots are rendered from the real TUI against a fixture proxy by scripts/readme/tui.mjs, so a layout change shows up here instead of rotting a mock-up. The numbers are illustrative; the pixels are not.}

It tracks a moving target

Claude Code's request shape changes between releases — new betas, tool renames, per-model thinking configs — usually with no subscriber-facing note. dario doesn't guess that shape: it captures it live from your own installed claude binary on every startup, diffs it against each upstream release, and replays it faithfully. That's why your subscription routes the same through dario as it does through Claude Code itself: the request that leaves your machine is the shape your plan expects. Details: wire-fidelity.md · #13 · #14.

Keeping that current is the whole job, and it's automated. These watchers run unattended; each badge is the live status of that workflow's latest run, and its label is the cadence:

Watcher	Catches	Live
cc-drift-watch	A new Claude Code npm release that changes the wire shape. Auto-drafts the fix; cc-drift-auto-release merges and ships it within minutes.
cc-drift-template-watch	Same-binary remote-config drift, which no npm diff can see. Runs against a live Claude session on a self-hosted runner and opens a rebake PR with the diff inline.
cc-billing-classifier-canary	Classifier drift: one real request a day must still bill to a subscription bucket.
wire-drift-self-hosted	Per-model beta headers and billing blocks the installed claude actually sends, model by model.
sdk-drift-watch	Agent SDK / Stainless pins drifting from what the template assumes.
pricing-drift-watch	dario's pricing table drifting from Anthropic's published rates, so the TUI's cost figures stay honest.
codex-drift-watch	The ChatGPT backend's model list or wire contract moving under the translator.
cc-oauth-health	The maintainer's own production proxy going unhealthy on any axis.
dario-doctor-watch	Runtime drift only a live dario doctor --obedience surfaces: identity, obedience, usage buckets.
deployed-version-watch	Publishing is not deploying: is what's running what was last released?
cc-drift-watcher-liveness	The watcher itself going quiet. Lives on GitHub-hosted infrastructure on purpose, so it survives the failures it watches for.

Guarded at PR time by live-test, a required check that runs the full suite against a live proxy on a self-hosted runner, plus compat-test-self-hosted, which replays the compat suite through a passthrough proxy on wire-shape changes. A few changes the watchers caught and shipped fixes for, same day:

The full ledger lives in the CHANGELOG, 500+ releases since April 2026. Setup and walkthrough: drift-monitor.md. The residual manual cases — OAuth rotation, runner re-registration — are in the recovery runbook.

Guardrails

Overage guard

During normal operation, a subscriber should never see a single response billed outside their subscription pool. If one is, something is wrong — wire-shape drift, an account misconfig, a change upstream — and forwarding more requests in the same shape either bleeds real money (accounts with extra usage enabled) or returns a wall of rejections. The first hit is the signal; the rest are damage.

So the moment any upstream response bills to something other than your subscription pool, dario halts the proxy. The check is an allow-list, not a match on one string: anything that isn't a known subscription claim (five_hour / seven_day, their _fallback and _overage_included variants, and the chatgpt_subscription claim dario stamps on Codex-served responses) and isn't the unknown no-header sentinel trips it, so a billing bucket dario has never seen still halts. Subsequent requests return 503 with an Anthropic-shaped error body until you run dario resume, press R in the TUI, or the cooldown clears (default 30 min). The halt shows across the TUI, fires a best-effort OS notification, and emits named SSE events. Tune it via ~/.dario/config.json → overageGuard, or --overage-behavior=warn / --no-overage-guard / --overage-cooldown=<ms>. In upstream-API-key passthrough mode (ANTHROPIC_UPSTREAM_API_KEY) the guard is off; api billing is the point there. Verified end-to-end by test/overage-guard-e2e-live.mjs. Background: #288.

The billing split, a contingency dario is built for

On 2026-05-13 Anthropic announced that, from 2026-06-15, Agent SDK and claude -p (headless) traffic would leave the subscription pool for a small separate monthly credit, then metered API rates. They paused it before that date. Those surfaces still bill subscription today, and Anthropic says it will give advance notice before any revised version. Nothing changed; no credits were issued.

The split isn't live, but it was announced once on short notice and could return, so dario is built for it either way. Every request is rebuilt into interactive Claude Code shape before it leaves your machine (and, with --stealth, the response-correlated timing an interactive session has), so your traffic sits in the subscription pool whether a split is paused or live. The daily canary above is the tripwire: it surfaces a revived split within a day instead of on a surprise invoice. Verify on your own machine right now: dario doctor --usage fires one request and prints the rate-limit headers; representative-claim should read five_hour or seven_day, both subscription buckets. Full timeline: why-now-2026-06.md.

Trust & transparency

npm audit signatures
npm view @askalf/dario dist.integrity
cd $(npm root -g)/@askalf/dario && npm ls --production

Security reports go to security@askalf.org, not a public issue: SECURITY.md. API stability commitments (@stable / @experimental / @deprecated, deprecation cycles): STABILITY.md.

Will my account get suspended?

The most common question about dario, and it deserves a straight answer: I can't promise you won't be actioned, and I'd be skeptical of anyone who does. Only Anthropic decides how it enforces its terms. What I can do is lay out exactly how dario works, so you can weigh the risk yourself instead of taking anyone's word for it.

What dario does:

• Runs entirely on your machine. Your subscription token never touches my servers or anyone else's; requests go straight from your computer to Anthropic.
• Authenticates as you, with your own Claude login, the same OAuth credential Claude Code itself uses. It impersonates nobody and shares nothing.
• Doesn't modify your account, billing, or subscription settings.
• Sends requests in the shape the official client sends them, rebuilt from your own installed binary, not spoofed from a hardcoded fake.
• Reports nothing, anywhere. No telemetry, no analytics, nothing phones home; verifiable in the source, which is the point of keeping it auditable in a weekend.

What dario does that Claude Code doesn't: it lets tools other than Claude Code use that subscription. That's the whole point of it, and it's also the part that sits outside what Anthropic's own client does. Whether that falls within your plan's terms is Anthropic's call, not mine. Read their terms, read DISCLAIMER.md, and decide deliberately. dario is a transparency tool, in that it documents request behavior Anthropic doesn't publish for subscribers, and it is also, plainly, routing subscription traffic that Anthropic's own tools bill differently. Both are true; decide with both in view.

On policy risk specifically: Anthropic's position on third-party clients has moved before and can move again. dario is built to surface that fast rather than paper over it; see the billing split for the contingency already in place and the daily canary watching for it.

Ongoing discussion, including other users' experiences: #724.

Who it's for

Best fit: developers juggling multiple LLM tools and per-tool API keys · Claude Pro/Max subscribers who want their plan usable everywhere, not just in Claude Code · ChatGPT Plus/Pro subscribers who want their plan in OpenAI-compatible harnesses · teams running local or hosted OpenAI-compat servers who want one stable local endpoint · Agent SDK users who want subscription routing with zero code change · power users wanting multi-account pooling with 429 failover.

Not a fit: you need vendor-managed production SLAs (use the provider APIs) · you want a hosted multi-tenant team platform with dashboards and SSO (dario is a single-owner local proxy) · you want a chat UI (use claude.ai).

How it compares. Only one of these routes a consumer subscription; the others route API keys, and that is the whole split.

Longer version, with specifics: #68.

Commands

Flags: commands.md, plus dario --help for the ones it doesn't list yet (--effort, --max-tokens, --model-alias, --fast-model, session rotation, concurrency caps, the pacing knobs behind --stealth) · env vars grouped by task, for Docker / k8s / systemd: configuration.md · SDK examples: usage.md.

FAQ

Full FAQ, including per-tool 401s and Team/Enterprise plans: faq.md.

Deep dives

• #183 — Modifying Claude Code's system prompt doesn't change billing; stripping its constraints recovers 1.2–2.8× output
• #68 — dario vs LiteLLM / OpenRouter / Kong AI Gateway (when each wins)
• #14 — Template replay: why we replay the shape instead of matching signals
• #13 — Claude Code's request shape, documented
• #1 — Rate-limit header analysis
• system-prompt-classifier-study.md, the measurements behind --system-prompt=partial

Contributing

PRs welcome. Small TypeScript codebase, zero runtime deps. Architecture, file-by-file map and the review bar in CONTRIBUTING.md; release mechanics in RELEASING.md.

git clone https://github.com/askalf/dario && cd dario
npm install
npm run dev    # tsx, no build step
npm test       # 178 files in parallel via test/all.test.mjs
npm run e2e    # live proxy + OAuth (needs a working Claude backend)

Drift and audit runners, none of them part of npm test:

npm run drift:wire     # compare a live Claude Code capture against the baked template
npm run drift:sdk      # Agent SDK / Stainless pin drift
npm run audit:tui      # drives the real TUI through a fake TTY at 12 geometries
npm run check:overage  # overage-classifier check against live headers
npm run stress         # concurrency / queue behaviour under load
npm run cch:calibrate  # re-derive the billing-tag cch seed for a new Claude Code build
npm run readme:assets  # regenerate the diagrams and TUI screenshots above

Two easy ways to help beyond code: star the repo, the clearest signal this is useful, and file drift: open an issue when a rate-limit header flips or a tool that worked yesterday breaks today, and it gets documented in public alongside the fix. Follow @ask_alf for drift bulletins as they land.

Contributors

Disclaimers

dario is an independent, unofficial, third-party project. Not affiliated with, endorsed by, or sponsored by Anthropic, OpenAI, or any vendor referenced here. Provided as-is, no warranty. You are solely responsible for compliance with your subscription's terms, the security of your credentials, and the content you send through the proxy. Not for safety-critical, regulated, or production environments without your own review. Full text: DISCLAIMER.md.

License

MIT — see LICENSE and DISCLAIMER.md. The embedded README font is Space Mono under the SIL Open Font License.

Own Your Stack

dario is the routing layer of Own Your Stack, open tools for owning your AI infrastructure instead of renting it by the token. One subscription. Your box. Your terms.

• dario — own your routing (you are here)
• hybrid — own your inference
• browser-bridge — own your browser
• redstamp — own your agent security
• truecopy — own your agent skills
• agent-security-stack — own your agent security stack: redstamp + truecopy + strongroom leases, one MCP server
• cordon — own your prompts · pair it with dario
• plumbline — own your agent oversight
• amnesia — own your search
• pgflex — own your Postgres
• redisflex — own your Redis
• askalf — own your operation: the AI operation that runs Sprayberry Labs

Built by Thomas Sprayberry

dario is part of Own Your Stack, the open toolkit behind Sprayberry Labs, the software studio with one human on staff, run by askalf, the AI operation these tools are part of.

Built in the open, scars included. Follow the build: @ask_alf · sprayberrylabs.com/own-your-stack