WebAI2API: Turning Browser AI Sessions into an OpenAI-Compatible Endpoint

The gap WebAI2API fills: browser-only AI products behind an OpenAI-shaped door

Several capable AI services are reachable only through a web UI. LMArena, Gemini Enterprise Business, ChatGPT, DeepSeek, Sora and Google Flow all ship browser front ends, and the README's support table lists which of them accept text, image or video generation. None of them publish an API key you can drop into an OpenAI client. WebAI2API exists to close that gap for people who already have accounts on those sites and want to script them.

The audience is narrow and specific. You need a machine that can run Camoufox, a Node.js 20 or newer runtime, and enough patience to complete a manual login through a virtual display. The README's device table puts the floor at 1 core, 1 GB of RAM and 2 GB of disk, but it also records that an Oracle free-tier 1C1G Debian 12 box was 'resource tight, fairly laggy, only for trial or light use', while a 2C2G Alibaba Cloud instance ran smoothly with the same single browser instance. That is a direct statement that the minimum is a floor, not a target.

This is not a way to get free model access. It is a way to automate sessions you are already entitled to, and the disclaimer in the README says account bans are among the consequences the authors disclaim.

How the mechanism works: Camoufox, adapters, queues and instance isolation

The core is Camoufox, described in the README as a Playwright-based browser. Instead of calling a model endpoint, WebAI2API opens a real browser, navigates to the target site, and interacts with it. The README calls this 'anthropomorphic interaction': simulated human typing and mouse trajectories, plus feature spoofing intended to evade automated detection. The project migrated from Puppeteer to Camoufox specifically because the older approach stopped working against current bot detection; the Puppeteer edition now lives on the puppeteer-edition branch and the README states it receives no further updates or maintenance.

Above the browser sits an adapter layer. Each supported site has an adapter, and the WebUI exposes adapter management, which the README points to as the place to check what account requirements a given site imposes. The adapter is what translates an incoming OpenAI-shaped request into whatever sequence of clicks and form submissions that site needs.

Around that, the README lists a task queue, load balancing, failover and error retry. Concurrency is handled by running multiple browser windows, and each window can carry its own proxy configuration. Because browser instance data is separated, multiple accounts can be logged in at once without sharing cookies or local storage. That separation is the feature the project name advertises, and it is what makes the queue meaningful: a saturated window can hand work to another instance rather than blocking.

There is a second output path worth noting. GET /v1/cookies returns the current cookies for a named browser instance, optionally filtered by domain, using the project's automatic re-login behaviour. That turns WebAI2API into a cookie source for other tooling, which is a different use case from the chat endpoint and one the README documents explicitly.

Getting it running: pnpm install, npm run init, and the login pass you cannot skip

The README documents two deployment routes. For source installs the sequence is pnpm install, then npm run init, which fetches browser and precompiled dependencies. The README warns that this script needs GitHub access and suggests passing a proxy, either interactively with npm run init -- -proxy=http://username:passwd@host:port or by setting one up beforehand. On Linux it then lists apt install -y xvfb x11vnc libgtk-3-0 libx11-xcb1 libasound2, and notes that other distributions should consult the documentation site.

Starting the service is npm start. On Linux with a virtual display it is npm start -- -xvfb -vnc. For the initial login there is a dedicated mode, npm start -- -login, which the README says temporarily forces headless mode and automation off so you can authenticate by hand.

Configuration lives in data/config.yaml, copied from config.example.yaml on first run. The README is blunt that config changes require a restart. The two keys it shows are server.port, defaulting to 3000, and server.auth, an API token that applies to both the API and the WebUI. The README suggests npm run genkey to generate one, and the example value is sk-change-me-to-your-secure-key.

Docker is the second route: docker run -d --name webai-2api -p 3000:3000 -v "$(pwd)/data:/app/data" --shm-size=2gb foxhui/webai-2api:latest, or docker-compose up -d. The README carries a security warning that the image enables Xvfb and VNC by default and that WebUI traffic is unencrypted, recommending an SSH tunnel or HTTPS on public networks. It gives the tunnel form: ssh -L 3000:127.0.0.1:3000 root@server-ip.

First-run initialisation is mandatory and manual. You connect to the virtual display, log in to the target site, send any message to trigger whatever human verification appears, accept terms or onboarding prompts, and confirm nothing else blocks the session. Only then does the adapter have a usable session.

The API surface is small on purpose, and the streaming behaviour is the important part

Three endpoints are documented. POST /v1/chat/completions takes a model name, a messages array and a stream flag, and the README's curl example uses model gemini-3-pro with stream set to true. GET /v1/models returns the models available under the current configuration, which is the authoritative list rather than the marketing table. GET /v1/cookies takes optional name and domain parameters, with name defaulting to default.

Multimodal input is constrained in ways worth reading twice. Accepted formats are PNG, JPEG, GIF and WebP, up to 10 images, and the payload must be Base64 Data URLs. The server then converts every image to JPG before sending it onward. That conversion is a compatibility measure, but it also means you lose the original encoding, and any format-specific metadata goes with it.

The concurrency behaviour is the sharpest edge in the documentation. The README states that because the project simulates real browser operations, timing varies, and when queued tasks exceed the configured limit the server rejects non-streaming requests outright. Its recommendation is to enable streaming, because the server then sends keepalive heartbeats and can queue indefinitely without timing out. Two heartbeat modes exist: Comment mode, the default, which emits a :keepalive SSE comment, and Content mode, which sends an empty data packet for clients that only reset their timeout on receiving JSON. If your client cannot handle SSE comments, you need the second mode, and that is a config change plus a restart.

Headless mode is the failure mode, and the support table is a promise the sites can revoke

The README's own guidance is that headless operation is risky. It states that headless mode saves resources but hides the browser, and that it may be detected by the target site. Its recommendation is to stay non-headless long term, or to use Xvfb as a stand-in for a real display. That is an unusual admission for a server tool: the recommended production posture is to keep a visible browser process alive.

The support table encodes a second class of fragility. Its legend distinguishes four states: supported, not currently supported but possibly later, not supported by the site at all, and watermarked results that cannot be removed. Google Gemini's image and video output and Sora's video output carry the watermark marker. DeepSeek is text-only. Nano Banana Free is image-only. Any of these cells can change when the site changes, and nothing in the repository can prevent that. A model that appears in GET /v1/models today can vanish after an adapter update or a site redesign.

The queue rejection behaviour compounds this. If you disable streaming and your workload spikes, requests are refused rather than queued. That is a deliberate backpressure choice, but it means a non-streaming integration needs its own retry logic, and the README does not describe one.

Finally, the legal and operational exposure is stated plainly. The disclaimer says the project is for learning and exchange, that the authors accept no responsibility for consequences including account bans, and that users must follow the target sites' terms of service. The MIT licence covers the code; it does not cover your relationship with LMArena or Google.

What you would otherwise write yourself, and what that costs

The obvious alternative is to write the Playwright or Camoufox automation directly against one site. If you only need LMArena, a single script that logs in, types a prompt and scrapes the response is perhaps a few hundred lines. What you would then have to build yourself is everything WebAI2API already ships: the OpenAI-compatible request and response shape, SSE streaming with heartbeat keepalive, a task queue with a rejection policy, multi-instance account isolation with per-instance proxies, a WebUI for adapter management and log inspection, and a VNC path for debugging a headless Linux box. The README's feature list is essentially an inventory of that work.

The trade-off runs the other way too. A hand-written script for one site is far easier to repair when that site changes, because you know exactly which selector broke. WebAI2API's adapter abstraction spreads that knowledge across a codebase you did not write, and the README does not describe a debugging workflow beyond the WebUI's real-time logs and VNC connection. If you are automating a single site and you control the deployment, the general-purpose harness may be more surface area than you want.

A different alternative is to use the sites' own paid APIs where they exist. Gemini, ChatGPT and DeepSeek all offer official endpoints. Those come with rate limits, billing and terms that permit programmatic use, and they do not break when a button moves. WebAI2API is the right choice only when the capability you want is not available through an official API, or when your existing account tier gives you access the API does not.

Maintenance burden, licence terms and what to check before you commit

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That covers the source in this repository. It does not grant any rights to the AI services the adapters talk to, and the README's disclaimer places the responsibility for complying with those terms on the user. Nothing here is legal advice; if you intend to run this in a commercial setting, the terms of each target site are the documents that matter.

Upgrade cost is dominated by adapter churn rather than by the application code. The project already went through one forced rewrite, from Puppeteer to Camoufox, and the README says the old branch is archived and unmaintained. That is the shape of future maintenance: when a site's detection or DOM changes enough, an adapter needs rework, and the release history retrieved for this review contains no releases, so there is no versioned changelog to pin against. The README points to CHANGELOG.md and the documentation site for version history.

Resource cost is real and continuous. A browser instance per account, kept non-headless or under Xvfb, consumes memory whether or not requests are flowing. The README's recommended single-instance figures are 2 cores, 2 GB RAM and 5 GB disk, rising to 4 GB RAM and 7 GB disk for multiple instances.

Before adopting, verify three things in order. First, that npm run init completes behind whatever proxy your network requires, since it downloads from GitHub. Second, that you can complete the manual login and human-verification pass through the virtual display, because no automation shortcut is documented for it. Third, that GET /v1/models returns the specific model you plan to call, since that endpoint reflects your configuration rather than the support table.

Editorial conclusion

Adopt WebAI2API if you already hold legitimate accounts on the listed sites and want their outputs behind POST /v1/chat/completions without writing Playwright glue yourself. Do not adopt it if you need a stable model contract, if you cannot run non-headless browsers with Xvfb, or if you cannot accept that a site redesign silently removes a model from GET /v1/models. Before committing, run npm run init, start with npm start -- -login, log in to one adapter, and confirm that GET /v1/models lists the model you actually intend to call.

Official sources

1. foxhui/WebAI2API on GitHub
2. Issues
3. License: MIT
4. Project website
5. README