OpenClaw Zero Token: Driving ChatGPT, Claude and Gemini Through Browser Logins

The problem: web subscriptions you already pay for, locked behind a chat box

Most people who use several AI models have already paid for them, through a browser subscription rather than an API plan. The gateway model assumes the opposite: you hold API keys, you pay per token, and your tooling talks to an endpoint. OpenClaw Zero Token is a fork of the OpenClaw gateway that removes that assumption. Instead of an API key, you log in to each provider's web UI in a browser once, and the gateway drives that session on your behalf.

The README frames the trade in a four-row table: buying API tokens versus browser login, per-request billing versus no enforced quota, credit card versus login only, and tokens that may leak versus credentials stored locally. The audience is developers and tinkerers who want a unified interface across Claude, ChatGPT, Gemini, DeepSeek, Doubao, Grok, Qwen, Kimi, Zhipu GLM, Xiaomi MiMo and Manus without opening eleven browser tabs. It is not aimed at production workloads, and the README never claims to be.

One provider in the table breaks the pattern. Manus is listed as "API key, free quota" rather than a web session, so the zero-token promise does not extend to it. That inconsistency is worth noticing before you plan around the table as a whole.

How the browser-session gateway actually routes a request

The architecture diagram in the README shows four entry points: a Lit 3.x web UI, a CLI and TUI, a gateway listening on a port, and messaging channels such as Telegram. All four converge on an Agent Core the README calls the PI-AI Engine. Below that sits the provider layer, where each vendor appears as a "Zero Token" adapter: DeepSeek Web, Qwen Web for international and China, Kimi, Claude Web, Doubao, ChatGPT and the rest.

So the flow is: a prompt arrives from any front end, the agent core decides what to do with it, and the provider layer translates it into whatever the target vendor's web interface expects. The browser is the transport, not an HTTP client with a bearer header. That design decision explains most of the project's strengths and most of its fragility. There is no rate-limit header to read, no usage endpoint to poll, and no versioned contract. There is a DOM.

Tool calling is the second mechanism, and it is implemented differently from a normal function-calling API. The middleware under src/zero-token/tool-calling/ injects tool definitions into the prompt itself, following an approach the README attributes to arXiv:2407.04997 and the ComfyUI LLM Party project. The available tools are web_search, web_fetch, exec, read, write and message. File access is bounded by the configured workspace directory, exposed as agents.defaults.workspace.

The README states that injection only happens when keywords in the user message suggest a tool action, and gives the reason directly: normal chat stays short to reduce ban risk. That is an honest description of a heuristic, and heuristics misfire. A question that mentions searching without intending a search may trigger injection; a request phrased unusually may not trigger it at all.

Installing OpenClaw Zero Token with Docker and a first request

The repository ships a Dockerfile and a docker-compose.yml, so the container path is the one with the most visible configuration. The compose file defines two services, openclaw-gateway and openclaw-cli, and the gateway publishes two ports by default: 18789 for the gateway itself and 18790 for the bridge. The image defaults to openclaw:local, and the config and workspace directories are bind-mounted from environment variables.

services:
  openclaw-gateway:
    image: ${OPENCLAW_IMAGE:-openclaw:local}
    environment:
      HOME: /home/node
      TERM: xterm-256color
      OPENCLAW_GATEWAY_TOKEN: ${OPENCLAW_GATEWAY_TOKEN:-}
      CLAUDE_AI_SESSION_KEY: ${CLAUDE_AI_SESSION_KEY:-}
      CLAUDE_WEB_SESSION_KEY: ${CLAUDE_WEB_SESSION_KEY:-}
      CLAUDE_WEB_COOKIE: ${CLAUDE_WEB_COOKIE:-}
    ports:
      - "${OPENCLAW_GATEWAY_PORT:-18789}:18789"
      - "${OPENCLAW_BRIDGE_PORT:-18790}:18790"

Those environment variables are the whole credential story in the compose file. CLAUDE_AI_SESSION_KEY, CLAUDE_WEB_SESSION_KEY and CLAUDE_WEB_COOKIE each pass through with an empty default, so an unset variable means no session and no working Claude provider. OPENCLAW_GATEWAY_TOKEN is the gateway's own access token and has nothing to do with the vendor accounts.

The healthcheck in the compose file polls the gateway's own health endpoint from inside the container, so a healthy start is one where that check passes. The compose file also sets the gateway command to bind on the value of OPENCLAW_GATEWAY_BIND, defaulting to lan, on port 18789.

The Dockerfile takes OPENCLAW_EXTENSIONS as a space-separated build argument to pull in optional extension dependencies, and OPENCLAW_VARIANT to choose between the default bookworm image and a slim variant. The README and the repository layout also point to INSTALLATION.md and START_HERE.md for the non-Docker path, and to docs/zero-token/index.md for the zero-token documentation set.

Where the zero-token approach breaks: Doubao, Gemini and the ban-risk heuristic

The README's own tool-calling table is the most useful honesty in the repository. Of thirteen web models listed, eleven support tool calling and are marked verified. Doubao is marked as not supporting it, with the reason given as a stream parser limitation, and it is excluded from the middleware. Gemini gets a checkmark for tool calling but a warning for chat, with the note that web_search works while DOM polling is unstable.

That last note is the whole failure mode in miniature. When a vendor changes its page structure, the adapter that reads the page stops reading it correctly. Nothing in the README describes a versioned contract, a selector stability policy, or a detection mechanism that tells you the adapter has gone stale. You find out when a response comes back empty or malformed.

The tool-injection heuristic carries a second risk that the README names itself: the keyword trigger exists to reduce ban risk. That phrasing acknowledges that driving a web UI programmatically is something vendors may act against. The README does not describe what happens if an account is restricted, and it does not document a fallback path if a session is invalidated mid-run.

Finally, the project is the wrong tool when you need accounting. The README's comparison table says "no enforced quota" as a benefit, which is true from the user's side and also means there is no usage meter, no per-request cost figure, and no way to attribute spend across teams. If your finance or security team needs that, this is not the gateway for you.

How OpenClaw Zero Token differs from LiteLLM and OpenRouter

The obvious alternative is a model-routing proxy such as LiteLLM, or a hosted aggregator such as OpenRouter. Both solve the same surface problem, one endpoint in front of many models, and both assume you hold API keys and pay per token. That assumption is exactly what this fork removes.

The practical difference is where the credentials live and who enforces the limit. With a routing proxy, your key is a bearer token, the vendor meters your usage, and an overage produces a 429 you can handle in code. With OpenClaw Zero Token, your credential is a browser session, the vendor meters nothing you can read, and an overage produces whatever the web UI does when it decides you have had enough. The first model is auditable. The second is not.

The second difference is tool calling. A routing proxy passes through the vendor's native function-calling API, so the model decides when to call a tool and the response comes back structured. OpenClaw Zero Token injects tool definitions into the prompt text and parses the model's prose reply, which is why the README can only verify eleven of thirteen models and why Doubao is excluded outright. Prompt-injected tool calling is a workaround for the absence of an API, and it behaves like one.

If you already have API keys and a budget line, a routing proxy is the better fit. If you have browser subscriptions and no budget line, the trade this fork makes is the only one available.

Licence, maintenance and what an upgrade actually costs

The repository is MIT licensed, and package.json confirms that for the upstream openclaw package. MIT permits commercial use and modification with the licence and copyright notice retained. That covers the code in this repository. It does not cover the vendor web interfaces the adapters drive, and the README's own disclaimer section is where that boundary is drawn. Nothing here is legal advice; if you plan to run this inside a company, the question of whether programmatic use of a consumer web session complies with each vendor's terms is one your own counsel has to answer, not the MIT grant.

On maintenance: the last push to the default branch was on 2026-09-14, and the most recent tagged release in the repository's release list is v2026.4.5 from 2026-04-04. That gap between the last release and the last commit is worth noting, because it suggests work landing on main that has not been cut into a version. The README also carries an "Upstream sync (Zero Token)" section and a docs/zero-token/upstream-sync.md file, which tells you the fork tracks a parent project. Every upstream rebase is a merge you may have to redo against the zero-token adapters.

The upgrade cost is therefore not a version bump. It is three things at once: merging upstream changes, re-checking that each vendor's web UI still matches its adapter, and re-verifying the tool-calling table, since a vendor-side change can silently move a model from the verified column to the broken one. Budget for that as ongoing work rather than a one-time install.

Editorial conclusion

Adopt OpenClaw Zero Token if you want a single gateway in front of many vendors' web UIs and you accept that browser sessions, not contracts, are your availability guarantee. Do not adopt it if you need per-request cost accounting, a support channel, or stable DOM selectors, because none of those exist here. Before committing, verify that your target providers still log in through the documented flow, check whether the tool-calling keyword trigger fires for your prompts, and read SECURITY.md for how session cookies are stored on disk.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. linuxhsj/openclaw-zero-token on GitHub
4. README
5. Releases