dario makes your Claude and ChatGPT subscriptions answer every editor you own, and it is upfront about the risk

One endpoint, two wire formats, and a seam nobody notices

The problem statement is arithmetic. You already pay twenty, a hundred, or two hundred dollars a month for a subscription plan. Then every other editor you use wants an API key and bills you again per token, while the plan you bought sits idle in the single application it shipped with. The pitch is that the subscription should work in the other eleven tools too.

The mechanism is a local proxy that speaks both shapes. Anthropic-shaped clients get one base URL, OpenAI-shaped clients get the same host under a version path, and the key is a fixed string rather than a credential. Three commands:

npm install -g @askalf/dario
dario login      # your Claude plan (Pro, Max 5x or Max 20x); `dario login --manual` for SSH / headless
dario proxy      # leave it running, then point any tool at http://localhost:3456 with key `dario`

What happens inside is deliberately uninteresting from the client's point of view. A client sends messages in the Anthropic shape, the proxy decides which plan owns that request, and forwards it in that backend's native protocol. An OpenAI-shaped request naming a model the other account can serve gets translated into the other protocol rather than refused. The tool does not know and the backend does not know, which is the entire design goal stated as a sentence.

The routing table is where the honesty lives. A request for a model no plan lists is refused with a specific error code and a header naming the reason, rather than being quietly forwarded somewhere unexpected. A client can also force the destination with a provider prefix in the model name, which is the escape hatch for anyone who wants to override the automatic choice.

Failover is described as finishing the answer, not restarting it

Most failover claims mean the second attempt fails too, or that the request is reissued from the beginning. The description here is narrower and more interesting: a rate-limit response from one plan is re-served by the other, and a stream that dies part-way through an answer is completed on the same model first.

That distinction matters for agent workloads, where a tool call half-way through a response is the difference between a working session and a broken one. Retrying the whole turn after a dropped stream burns tokens and loses whatever context the client had already assembled.

The seat pooling sits on the same axis and is aimed at the same problem. If you hold several seats on one plan, new conversations go to the seat with the most headroom by default, and two alternative strategies exist for people who would rather spend a seat whose weekly window resets soonest or fill seats in a fixed order. The active strategy is visible in four places, which is the detail that suggests it has confused people before: the startup banner, a status endpoint, the diagnostic command, and the account listing.

The overage guard is the feature that makes the rest defensible

Here is the part that distinguishes this from the usual entry in this category. There is a guard that halts the proxy the moment a response bills outside your subscription. Not a warning, not a monthly estimate: a stop.

That is a direct answer to the obvious objection to the whole approach, which is that routing subscription traffic through a tool built for metered API access can produce a bill you did not agree to. A tool that can stop itself when that happens is materially different from one that can only tell you afterwards.

The cost accounting supports the same posture. Every request is priced at published API rates in a local ledger, exposed through the terminal interface, an analytics command, a Prometheus endpoint, and a per-request timing breakdown. The framing is a counterfactual, what the same traffic would have cost on per-token billing, which is a more honest framing than pretending the traffic was free. Both the guard and the ledger are opt-in surfaces you have to know exist.

Eleven watchers exist because the wire format moves

The most honest paragraph in the documentation is the one about drift. The project describes itself as tracking the coding agent whose protocol it imitates, with eleven unattended watchers that catch changes to the wire shape and ship a fix, usually within the same day. Two continuous integration workflows are named for the classifier and for the drift watch, and one is for the template the agent ships.

Read that as a statement about the fragility of the approach rather than about engineering quality. A proxy that reuses a first-party client's authentication against a consumer subscription is depending on an undocumented protocol, and undocumented protocols change without a changelog. Any project in this category either watches for that or breaks quietly, and the ones that do not watch are the ones that leave you with a mysterious error and a support forum full of people whose tools stopped working on a Tuesday.

The same fragility explains other parts of the tree. There is a fuzzing directory, a separate continuous fuzzing configuration, a security policy, a stability document, a migration guide, a codeowners file, and a release process document. The presence of a stability document in a third-party unofficial tool is unusual, and it is there precisely because the tool's behaviour depends on things it does not control.

Zero runtime dependencies, and a container that drops privileges

The package declares zero runtime dependencies and is published with a supply chain attestation on every release. The source is described as roughly forty thousand lines you could read in a weekend, and the repository does contain an ordinary amount of code for something that does this: a source directory, a test directory, an MCP directory, scripts, tools, and a separate directory for reviewing recorded traffic.

The container is where the operational care shows. The base image is pinned by digest rather than by tag, in both the build stage and the runtime stage. The runtime adds a privilege-dropping helper and copies a second runtime binary from another image purely for its TLS fingerprint, because without it the proxy detects the wrong runtime and degrades. A non-root user is created, the application directory is chowned to it, and the entrypoint starts as root only to repair ownership on a mounted volume before dropping privileges, because volume mounts do not preserve it.

Every one of those is a comment explaining why. The build even copies the manifest into the image so the diagnostic command can report a version number, with a comment explaining that omitting it produces a warning about an unknown version even though the binary works. That is what forty thousand lines maintained by watching other people's changelogs looks like.

Named keys, budgets, and a model allowlist per developer

Because a subscription is shared rather than personal, access control has to live in the proxy, and it does. Each developer gets a named key with a preferred seat, a model allowlist, and a daily budget. The endpoint is local, but a shared subscription with several people using it is exactly the situation where per-person limits are the difference between a tool and an incident.

The shadow comparison feature follows the same logic from the other direction. Any request can be compared against another model without affecting what the caller receives, and the results are read with a dedicated command, so you can find out what a different model would have said before you commit to it. That is the feature that turns the tool from a cost-saving trick into something you could evaluate.

Per-client configuration is documented rather than guessed at, in a separate document with a setup section per tool. The named list covers the major coding agents and editors, both vendor software development kits, the agent SDK, a plain HTTP client, and your own scripts, which is the point: anything honouring the two environment variables below runs on the subscription with no further work.

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

What is missing, and who should not install this

Two limits deserve to be stated before anyone installs it. The first is contractual. The project describes itself as independent, unofficial and third-party, and ships a disclaimer document, because using a consumer plan as an API backend is a question about what your agreement with the provider permits rather than about what this code does. Providers have changed the behaviour of first-party clients before, and they can close this path the same way.

The second limit is operational. The proxy holds credentials for accounts that can spend real money, on a machine that is often a developer laptop. The named-key and budget features reduce the blast radius, but the honest summary is that this is a tool for people who already trust their own local machine and have read the provider terms.

Neither limit is a reason not to use it. It is a reason to read the disclaimer and the stability document before the first request rather than after the first surprise, and to keep the overage guard on. If your provider's terms forbid this, no amount of engineering quality in the proxy makes it permitted, and that is the only fact in this article that outranks the rest.

Editorial conclusion

Start with the terms of service, not the feature list. dario works by presenting a consumer subscription to a backend that expects metered API access, and whether that is permitted is a question about your agreement with the provider rather than about this software, and the project ships a disclaimer saying exactly that. With that read first, the engineering is unusually candid: zero runtime dependencies, an auditable supply chain attestation per release, no phone-home behaviour, eleven unattended watchers keeping pace with upstream changes, and a guard that halts the proxy rather than letting a response bill you per token. The failures are worth knowing too, since the whole design is built around the assumption that the upstream wire format will change without notice.

Frequently asked questions

Official sources

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