ClewdR: a Rust proxy that puts Claude.ai and Claude Code behind one binary
High Performance LLM Reverse Proxy
At a glance
- What is it?
- ClewdR serves native Claude and OpenAI-compatible endpoints from a single static executable, routing requests through exported Claude.ai cookies. It is small and quick to start, but the cookie dependency and the AGPL-3.0 licence shape who can use it.
- Who is it for?
- Adopt ClewdR if you already hold Claude.ai cookies, want one binary to serve both native Claude and OpenAI-compatible clients, and can accept AGPL-3.0 in your deployment. Do not adopt it if you need a vendor-supported or contractually clear path to Anthropic, or if you cannot keep cookie exports fresh, since the documentation states ClewdR needs at least one before it serves anything.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 14 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap ClewdR fills between Claude clients and Claude endpoints
Claude.ai and Claude Code do not expose the same surface. A tool written against the OpenAI chat completions schema cannot talk to either without a translation layer, and a tool written for Claude Code expects paths under /code. ClewdR takes the position that one process should answer both. The README describes it as a Rust proxy for Claude.ai and Claude Code that serves native Claude and OpenAI-compatible endpoints from a single binary. That framing is the whole product thesis: not a gateway to many providers, but a local adapter for one provider with two client dialects. The audience is narrow and specific. Someone running SillyTavern, Continue, or Cursor against a Claude.ai subscription, or someone who wants Claude Code style routing without a separate Claude Code installation, is the target. Anyone looking for a multi-provider router or a hosted service is not. The README gives no indication of multi-user authentication beyond an API password, so treat it as a single-tenant local proxy rather than shared infrastructure.
Cookies are the credential, and the routing table is the contract
ClewdR does not hold an API key in the usual sense. The README states plainly that it needs at least one Claude.ai cookie before it can serve requests, and that you export them via browser devtools and paste them into Claude, then Submit Cookie, one per line. Cookie Status then shows each cookie's state and remaining quota. That is the data flow: a client hits /v1/messages or /v1/chat/completions, ClewdR picks a cookie from its pool, and the request goes upstream under that identity. The Config tab carries an outbound proxy, retry limits, and rules for skipping cookies, which implies the pool is expected to be heterogeneous and some entries expected to be unusable at any given moment. The routing table is small enough to memorise. Claude.ai traffic goes to /v1/messages, /v1/chat/completions and /v1/models. Claude Code traffic goes to the same three paths under /code, plus /code/v1/messages/count_tokens, which has no Claude.ai equivalent. Streaming works on every endpoint, per the README. The model list returns the ids ClewdR currently accepts, including a -thinking variant of each, so clients that validate model names against that endpoint should work without hardcoded strings.
Running it: one binary, one port, two passwords
The quickest path is the release archive. The README gives the Linux x86_64 example verbatim: curl -L -O the release zip, unzip it, chmod +x clewdr, then run ./clewdr and open http://127.0.0.1:8484. The admin password is printed to the console. Assets follow the pattern clewdr-<os>-<arch>.zip with os in linux, musllinux, macos, windows, android and arch in x86_64 or aarch64. Docker is the alternative, and the README is explicit about the trap: mount something at /etc/clewdr or the generated passwords are lost on every recreate. The config lives there as clewdr.toml with logs under log/. You can read the generated passwords with docker logs clewdr | grep Password, or set them yourself. Any config key can be set as an environment variable by upper-casing it and prefixing CLEWDR_, and the value is read as the type that key holds, so CLEWDR_PASSWORD=12345 is the string 12345. Booleans accept true/false, yes/no, on/off and 1/0 in any case. The image already sets CLEWDR_IP=0.0.0.0 and disables update checks, since an image cannot replace its own binary. A client then points at http://127.0.0.1:8484/v1/ with the API password as the key, which is what the SillyTavern JSON snippet in the README does.
Building from source is where the toolchain bites
The frontend compiles to WebAssembly into static/, and that directory is gitignored. The README warns that cargo run on a fresh checkout starts a server with no UI. cargo xtask handles the ordering: check reports on the required toolchain pieces, build produces a release build of both frontend and server, dev runs both with frontend hot reload on port 3000, lint runs clippy over every valid feature combination, fmt formats via nightly, and ci runs everything CI runs. Building the frontend needs rustup target add wasm32-unknown-unknown and cargo binstall trunk. Two gotchas are documented for anyone bypassing xtask. Formatting must go through nightly because .rustfmt.toml uses nightly-only options that stable silently ignores, which means a stable cargo fmt can quietly leave the file unformatted rather than fail. And --all-features fails, because embed-resource/external-resource and portable/xdg are mutually exclusive pairs enforced in build.rs. The escape hatch for all of this is nix develop, which the README says provides the pinned stable toolchain with wasm32, nightly rustfmt, trunk and the matching wasm-bindgen, so nix develop -c cargo xtask ci works on a bare checkout. The same flake builds release binaries and container images, for example nix build .#clewdr-musl-x86_64 and nix build .#image-amd64.
Where ClewdR is the wrong tool
The cookie requirement is the first hard boundary. If you do not have a Claude.ai account to export cookies from, ClewdR serves nothing. Cookie exports also expire and get invalidated, and the README's own feature set reflects that: cookie status, remaining quota, and rules for skipping cookies all exist because cookies fail. There is no documented mechanism for automatically refreshing a cookie, only for skipping the ones that stop working. The second boundary is the licence. AGPL-3.0 is a strong copyleft licence, and if you modify ClewdR and expose it to users over a network, the licence's source-disclosure obligation is the kind of thing you should read yourself or take advice on rather than infer from an article. That rules it out for many commercial deployments without legal review. The third boundary is scale. The README cites under 10 MB RAM, under 1 s startup and a roughly 15 MB binary, which describes a single-process local tool, not a horizontally scaled gateway. Nothing in the material describes clustering, shared state between instances, or coordination of a cookie pool across processes, so running two instances side by side would mean two independent pools with no shared quota view.
ClewdR against Clewd, the project it credits
The README's thanks section names Clewd as the source of many upstream ideas. Clewd is a JavaScript project, and that difference in runtime is the substantive one. A Node-based proxy needs a Node runtime present, carries a node_modules tree or a bundler step, and starts a V8 instance. ClewdR compiles to one static executable with a WebAssembly frontend embedded in it, which is why the README can quote a 15 MB artifact and sub-second startup. For someone deploying to a small VPS or an Android device, that is the whole argument. The trade-off runs the other way too. A JavaScript project is easier to patch in place, easier to read for people who do not know Rust, and easier to extend without setting up wasm32, trunk and a nightly formatter. The two also differ in surface area: ClewdR explicitly adds Claude Code paths under /code, including /code/v1/messages/count_tokens, which the README presents as part of its own routing table rather than something inherited. If you need to change routing behaviour, the Rust build chain described above is the cost of entry.
Upgrades, configuration persistence and the maintenance bill
Release cadence is visible in the material: v0.13.3 and v0.13.4 landed a day apart in August 2026, and v0.13.5 followed in early September. That is frequent enough that pinning matters. The Docker instructions suggest pinning with a tag like :v0.13.1 rather than :latest, and the image disables update checks because a container cannot replace its own binary. For binary installs the README says nothing about an upgrade path beyond downloading a newer archive, so the practical cost is re-downloading and restarting, plus re-checking that your config keys still behave. The config surface is a single clewdr.toml under /etc/clewdr in the container, and the README notes that server settings such as IP and port need a restart while the rest apply on save. Losing that file means losing the passwords, which is why the README tells you to mount a persistent folder and, if you forget the admin password, to delete clewdr.toml and start again. On licence: AGPL-3.0 covers the whole project, and the README does not carve out a separate licence for the embedded WebAssembly frontend or the build tooling. Whether that matters to you depends on how you deploy it, and it is worth confirming with your own counsel rather than from a summary.
Editorial conclusion
Adopt ClewdR if you already hold Claude.ai cookies, want one binary to serve both native Claude and OpenAI-compatible clients, and can accept AGPL-3.0 in your deployment. Do not adopt it if you need a vendor-supported or contractually clear path to Anthropic, or if you cannot keep cookie exports fresh, since the documentation states ClewdR needs at least one before it serves anything. Verify first that your client's model ids appear in the /v1/models list, that streaming behaves as your client expects on /v1/chat/completions, and that the config keys you need are settable as CLEWDR_ environment variables in your container runtime.
Community notes