ClewdR: a Rust reverse proxy that fronts Claude.ai and Claude Code with OpenAI-compatible endpoints

What ClewdR actually solves for Claude.ai and Claude Code users

Claude.ai is a web product. Claude Code is a separate client. Neither speaks the OpenAI chat-completions shape that most local tooling expects, and neither gives you a single local address you can hand to arbitrary clients. ClewdR sits in the middle and exposes both worlds behind one port.

The README is explicit about the audience: it is a proxy for Claude, covering both Claude.ai and Claude Code, and it serves native Claude and OpenAI-compatible endpoints from a single binary. That means a client that only knows /v1/chat/completions can talk to it, and a client that speaks the native Claude message format can talk to it too, against the same process. The README's own connection table lists /v1/messages and /v1/chat/completions for Claude.ai, and /code/v1/messages and /code/v1/chat/completions for Claude Code, plus /v1/models and a token-counting route on the Claude Code side.

The intended user is someone running a local desktop client. The README's example is SillyTavern, but it also names Continue and Cursor and says any other OpenAI-compatible client works the same way: point the API base at http://127.0.0.1:8484/v1/ and use the API password as the key. This is a tool for individual operators wiring a browser session into a local tool, not a team gateway.

How ClewdR routes requests: cookies, endpoints and the -thinking model suffix

The mechanism is cookie-backed. The README states that ClewdR needs at least one Claude.ai cookie before it can serve requests, and that cookies are pasted into the Claude tab under Submit Cookie, one per line. Cookie Status then shows each cookie's state and remaining quota. So the data flow is: client request arrives at one of the documented paths, ClewdR picks a cookie from its pool, forwards upstream, and streams the response back.

Streaming is supported on every endpoint, per the README, which matters because most chat clients assume it. The model surface is dynamic rather than hardcoded: the model-list endpoint returns the ids ClewdR currently accepts, including a -thinking variant of each. That is a useful design choice. Instead of documenting a fixed model list that drifts, the proxy reports what it will accept, and the client can enumerate it.

The cookie pool is also where the operational complexity lives. The Config tab, according to the README, covers the API and admin passwords, an outbound proxy, retry limits, and rules for skipping cookies. Those last two are the admission that cookies fail: retries and skip rules exist because a cookie can go bad or exhaust its quota. Server settings such as IP and port need a restart; the rest apply on save.

Installing ClewdR from a release zip and making a first request

The README's quick start is a download, an unzip and a run. The Linux x86_64 asset is named clewdr-linux-x86_64.zip, and the naming scheme is clewdr-<os>-<arch>.zip with os in linux, musllinux, macos, windows or android, and arch in x86_64 or aarch64.

curl -L -O https://github.com/Xerxes-2/clewdr/releases/latest/download/clewdr-linux-x86_64.zip
unzip clewdr-linux-x86_64.zip
chmod +x clewdr
./clewdr

After running the binary, open http://127.0.0.1:8484 and enter the admin password printed to the console. The API password is printed separately at startup, and you need both: admin for the UI, API password as the client key.

Docker is the alternative path, and the README is direct 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/.

docker run -d --name clewdr \
  -p 8484:8484 \
  -v clewdr-data:/etc/clewdr \
  -e CLEWDR_PASSWORD=your-api-password \
  -e CLEWDR_ADMIN_PASSWORD=your-admin-password \
  ghcr.io/xerxes-2/clewdr:latest

Setting passwords through the environment is the automatable route. 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. 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.

Once a cookie is submitted, a client config looks like this:

{
  "api_url": "http://127.0.0.1:8484/v1/chat/completions",
  "api_key": "password-from-console",
  "model": "claude-sonnet-4-6"
}

If you forget the password, the README says to delete clewdr.toml and start the binary again.

Building ClewdR from source: the xtask ordering and two toolchain traps

The source build has a real ordering dependency that the README calls out. The frontend compiles to WebAssembly into static/, which is gitignored, so it has to be built first or cargo run starts a server with no UI. cargo xtask handles the ordering.

cargo xtask check     # report on the required toolchain pieces
cargo xtask build     # release build of the frontend and the server
cargo xtask dev       # both, with frontend hot reload, on :3000
cargo xtask lint      # clippy over every valid feature combination
cargo xtask fmt       # format (always via nightly)
cargo xtask ci        # everything CI runs

Building the frontend needs rustup target add wasm32-unknown-unknown and cargo binstall trunk. Running cargo xtask itself needs nothing, which is a deliberate split: the build tool is cheap even when the toolchain is not.

Two gotchas apply if you bypass xtask. Formatting must go through nightly, because .rustfmt.toml uses nightly-only options that stable silently ignores. And --all-features fails, because embed-resource/external-resource and portable/xdg are mutually exclusive pairs enforced in build.rs. There is also a Nix path: nix develop 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: cookie dependence and a thin operations story

The largest limitation is structural, not a bug. ClewdR needs at least one Claude.ai cookie before it can serve requests. Everything downstream, including retry limits and cookie-skipping rules, exists to manage the failure of that input. If your cookies expire, are invalidated, or your account stops being usable for this kind of access, the proxy has nothing to fall back on. The README does not document any non-cookie authentication path, and it does not document rollback or recovery beyond deleting clewdr.toml to reset a forgotten password.

The second limitation is operational. Configuration is split between a UI and a file: server settings such as IP and port need a restart, while the rest apply on save. That is a reasonable split, but it means you cannot treat clewdr.toml as a fully declarative source of truth for a running instance. In Docker, the persistence requirement is sharper: mount /etc/clewdr or the generated passwords are lost on every recreate. Anyone running the container without a volume will re-read the passwords from docker logs after each restart.

The third is scope. The README describes a single-operator setup: one admin password, one API password, one cookie pool. There is no documented notion of per-user keys, quotas per key, or audit logging. For a team that needs to attribute usage or revoke access per person, this is the wrong shape. It is also the wrong tool if you want a hosted service; the whole design assumes a binary you run yourself, on Linux, macOS, Windows or Android, with a Docker image as the alternative.

How ClewdR differs from Clewd and from a generic Anthropic API proxy

The README's own thanks section names Clewd for many upstream ideas, and the relationship is worth being precise about. Clewd is the earlier project in this space, and ClewdR is a Rust rewrite that keeps the cookie-backed approach while changing the deployment story. The concrete differences visible in the repository are the single static binary, the platform matrix (linux, musllinux, macos, windows, android across x86_64 and aarch64), the Docker image on ghcr.io, and the dual endpoint surface that serves both native Claude paths and OpenAI-compatible paths from the same process.

Against a generic Anthropic API proxy, the difference is what sits behind the endpoint. A proxy that expects an API key is a forwarding layer; ClewdR expects a Claude.ai cookie and manages a pool of them, with retry limits and skip rules. That is the whole point and also the whole risk. If you have a proper API key, a plain forwarding proxy is simpler and does not depend on a browser session staying valid. If you do not, ClewdR is one of the few options that accepts the cookie model and still presents an OpenAI-compatible face to your client.

The model surface is another practical difference. ClewdR reports accepted model ids, including a -thinking variant of each, from /v1/models. A client that enumerates models will adapt; a client with a hardcoded list will need to be told what to request.

Licence, releases and the cost of staying current

ClewdR is licensed AGPL-3.0, stated in both the repository metadata and Cargo.toml. That matters if you plan to modify it and expose it over a network: the AGPL's network clause is the reason many teams avoid it for internal services they do not want to publish. Running the unmodified binary for yourself is a different situation from shipping a modified fork as a service, and the licence text, not this article, governs which applies. Nothing here is legal advice.

The release cadence visible in the repository is brisk: v0.13.3 and v0.13.4 landed a day apart in mid-August 2026, and v0.13.5 followed on 2026-09-02, the same day as the last push to master. The Cargo.toml version is 0.13.5, matching the latest release. The Docker README advises pinning with a tag such as :v0.13.1 rather than tracking :latest, which is the right default given that cadence.

Upgrade cost is mostly the cookie pool and the config file. Because clewdr.toml lives at /etc/clewdr in the container, a pinned image plus a persistent volume means an upgrade is a container replacement, not a reconfiguration. Source builders pay more: the frontend must be built into static/ before the server has a UI, and cargo xtask is the supported path for keeping that ordering correct. The workspace also keeps xtask out of default-members, so a bare cargo build still builds only what ships.

Editorial conclusion

Adopt ClewdR if you already have Claude.ai cookies and want a local, single-binary endpoint that speaks both the native Claude and OpenAI-compatible protocols, especially for desktop clients like SillyTavern, Continue or Cursor. Do not adopt it if you need a hosted gateway, multi-tenant key management, or any guarantee that cookie-based access will keep working, because the README treats cookies as the required input and does not describe a fallback. Before committing, verify two things yourself: that your platform asset exists under the naming scheme clewdr-<os>-<arch>.zip, and that your client works against /v1/chat/completions with the API password printed at startup, since the README documents the endpoints but not per-client compatibility beyond SillyTavern.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. README
4. Releases
5. Xerxes-2/clewdr on GitHub