dario: one local endpoint that puts your Claude and ChatGPT plans behind every AI tool

The second bill dario is trying to remove

A Claude Pro, Max 5x or Max 20x subscription, or a ChatGPT plan, works inside the application it shipped with. The README frames the problem bluntly: Cursor wants an API key, Aider wants an API key, Cline, Continue, Zed and your own scripts each bill you again per token while the plan sits idle. dario's answer is a single local process that speaks both wire shapes, so the tool keeps its existing configuration style and only the base URL changes.

The audience is narrow and specific. It is someone who already pays for a plan, runs several coding agents, and is willing to point them at localhost:3456 rather than a vendor endpoint. It is not aimed at teams that need a shared, auditable, hosted gateway, and it is not a way to get model access you have not paid for. The README links a DISCLAIMER.md and devotes a section to the question of account suspension, which tells you the project treats this as an unofficial arrangement rather than a supported integration path.

Two wire shapes, one port, and what happens on a 429

The mechanism is a local HTTP server. Anthropic-shaped clients talk to http://localhost:3456; OpenAI-shaped clients talk to http://localhost:3456/v1, which the README says covers chat/completions and, since 6.3, the Responses API. The API key is the literal string dario, and any value works until DARIO_API_KEY is set, after which the header has to match.

Routing is where the project spends its complexity. Either plan can answer either wire shape, which means an OpenAI-shaped request does not require an OpenAI plan. When one plan returns a 429, the other takes the request. The README also describes multi-seat pooling, so more than one account can sit behind the same endpoint, and the quickstart output shows a pool line reading "Pool: 1 account".

The repository layout backs this up with a test suite that names the behaviours rather than describing them in prose: test/failover-429.mjs, test/pool-sticky.mjs, test/session-rotation.mjs, test/stream-drain.mjs and test/pacing.mjs. Sticky pool behaviour and pacing are the kind of details that decide whether a proxy is usable for long agent sessions, and here they are at least named and tested.

Installing dario and pointing Aider at it

The package installs globally from npm, and the README's quickstart is four steps. The first block installs the CLI and logs in to a Claude subscription; the --manual flag is the documented path for SSH or headless machines, where a browser cannot open.

npm install -g @askalf/dario
dario login
dario login --manual   # SSH / headless alternative

After login, start the proxy in a separate terminal or in the background. The README's example terminal output shows the banner reporting http://localhost:3456, an OAuth health line and the pool count.

dario proxy

Then export the two variables and run any Anthropic-compatible tool. The README uses Aider as the example.

export ANTHROPIC_BASE_URL=http://localhost:3456
export ANTHROPIC_API_KEY=dario
aider --model sonnet

OpenAI-shaped tools use the /v1 suffix instead. Codex CLI is configured through a TOML file rather than environment variables, and the README gives the file path and the provider block.

# ~/.codex/config.toml
model = "claude-opus-5"
model_provider = "dario"

[model_providers.dario]
name = "dario"
base_url = "http://127.0.0.1:3456/v1"
env_key = "DARIO_API_KEY"
wire_api = "responses"

If something misbehaves, dario doctor prints a single paste-ready health report. A Docker image is published at ghcr.io/askalf/dario:latest for amd64 and arm64, from the same workflow as the npm releases.

The drift problem, and why the project ships a canary

Routing to a subscription means depending on a moving target. The README's own framing is that dario "tracks a moving target", and the repository carries the machinery for it: src/cc-template-data.json holds a version for the bundled Claude Code template, and three GitHub Actions workflows watch it. One runs hourly, one watches the template, and a third is described as a daily live billing canary.

The design implication is that dario's correctness is partly a function of how quickly the maintainers notice a change in Claude Code's behaviour and ship a template update. That is a real operational dependency, not a footnote. A user who pins a version and forgets it will eventually be running a template that no longer matches what the upstream client sends. The CHANGELOG.md and MIGRATION.md files exist for exactly this reason, and the README links a docs/returning.md page for people coming back after a while.

On maintenance, the last push was on 2026-09-14, and the three most recent releases (v6.7.0, v6.7.1 and v6.8.0) landed on 2026-09-13 and 2026-09-14. The repository is not archived. That is a fast release cadence, which cuts both ways: fixes arrive quickly, and so does churn.

Where dario is the wrong tool

The clearest limitation is the one the README raises itself. It has a section headed "will my account get suspended" and a DISCLAIMER.md file, and it describes itself as independent, unofficial and third-party. If your organisation needs a vendor-sanctioned path to model access, or a contract that names who is responsible when a plan's terms change, dario does not provide one. The risk sits with the account holder.

There are engineering limits too. The Dockerfile copies a static bun binary from oven/bun:1-alpine because, in the image's own comment, bun ships dario's runtime TLS fingerprint and without it dario auto-detects Node and falls back to bun-not-found mode. That is extra weight in a container you might otherwise expect to be a thin Node image, and it is a dependency on bun's fingerprint matching what upstream expects.

The project also assumes a single-user local process. Multi-seat pooling is about pooling accounts, not about serving a team from a shared, audited gateway. If you need per-user quotas, central logging or an SLA, a hosted router is the better fit.

How dario differs from LiteLLM and OpenRouter

The topic list puts dario alongside litellm, openrouter and ollama, but the approaches differ in a way that matters for adoption. LiteLLM and OpenRouter are routers over API keys: you bring provider credentials, they normalise request shapes, and you are billed per token by the provider. dario inverts the credential. It authenticates against a subscription you already hold through an OAuth login (dario login), and the billing model is the plan, not the token.

That inversion is the whole product. It also explains the failure modes: a per-token router does not care whether Claude Code's request shape changed last week, because the provider's API is the contract. dario's contract is a client that ships on its own schedule, which is why the hourly drift watch and the billing canary exist at all. If you want a stable, documented API surface and are willing to pay per token for it, a conventional router is the lower-risk choice. If the plan is already paid for and sitting idle, dario is aimed at you.

Licence, upgrade cost and what you are maintaining

dario is MIT-licensed, so you can read, fork and redistribute it, and the README notes the package declares zero runtime dependencies and is SLSA-attested on every release. The MIT grant covers the code; it says nothing about your subscription agreement with Anthropic or OpenAI, and the DISCLAIMER.md is where the project puts that boundary. Nothing here is legal advice, and the licence text is the thing to read rather than a summary of it.

The upgrade cost is real but bounded. Because dario tracks a client that changes without notice, staying current is part of running it: the hourly drift watch and the daily billing canary are the project's own signal that upstream moved, and MIGRATION.md exists for the versions where the change was breaking. Budget for periodic upgrades rather than a set-and-forget install, and read CHANGELOG.md before jumping a minor version. The npm package is published as @askalf/dario and the CLI binary is dario.

Editorial conclusion

Adopt dario if you already pay for a Claude Pro, Max or ChatGPT plan and want Cursor, Aider, Cline or Codex CLI to draw on it instead of an API key, and if you accept that the README carries a DISCLAIMER.md and a risk section rather than a compatibility promise from Anthropic or OpenAI. Do not adopt it if you need a vendor-supported integration, a hosted endpoint, or a guarantee that a subscription plan will not change how it bills agent traffic. Verify first that your tool accepts a custom base URL, that Node is available for the npm install, and that the Docker image's bun dependency is something your deployment can carry.

Frequently asked questions

Official sources

1. askalf/dario on GitHub
2. License: MIT
3. Project website
4. README
5. Releases