tabbit-toy: an OpenAI-compatible proxy for the Tabbit browser's built-in models

What tabbit-toy solves, and for whom

Tabbit is a Chromium-based AI browser with 21 built-in models, among them Claude-Opus-4.8, GPT-5.5, Gemini-3.5-Flash and DeepSeek-V4-Pro. The README states the constraint plainly: normally you have to open the Tabbit browser to use those models. That is fine when you are browsing and awkward when you are working inside an editor, a chat client or a script that already speaks the OpenAI API.

tabbit-toy is a local reverse proxy that closes that gap. Your client sends an OpenAI-format request to a process on localhost, the proxy translates and signs it, forwards it to web.tabbit.ai, and streams the result back in OpenAI shape. The intended user is one person on one machine who already has Tabbit installed and a Pro membership. The README asks for Node.js 18 or newer and notes the project has zero dependencies, so there is no npm install step. Pro models additionally require the account to have been set as the default browser and a unique-uuid marker in the request headers, which the project says it handles automatically.

The request path: OpenAI in, signed Tabbit call out

The README's own diagram shows the shape of the data flow. A client speaks OpenAI format to a local service, which translates and signs the payload before it reaches web.tabbit.ai, and the reply comes back as an SSE stream that the proxy re-frames as an OpenAI response.

The service exposes four endpoints: GET /v1/models returns the model list in OpenAI format, POST /v1/chat/completions handles chat completions with stream set to true or false, GET /healthz reports cookie validity, session count and auto-refresh state, and POST /admin/refresh-cookie triggers a cookie pull from the local browser. Authentication on the proxy side is optional: if API_KEY is empty, the proxy does not check the Authorization header at all.

Cookie handling is the part worth understanding before you commit. The login state lives in cookies, including an HttpOnly JWT, and the README says that JWT expires in roughly seven days. Rather than re-exporting by hand, the service can talk to a locally running Tabbit over the Chrome DevTools Protocol on port 9222. The browser's native layer silently renews the JWT before it lapses, so the proxy always reads a fresh value. Refresh happens at startup, on a timer controlled by COOKIE_REFRESH_MINUTES (default 360 minutes), on demand when a request hits an auth error such as 401 or 403, and via the admin endpoint. If the browser is closed or was not started with the debugging port, the refresh fails quietly and the previous cookie from .env stays in use. A successful refresh is written back to .env, so the last good cookie survives a restart.

Installing tabbit-toy and making a first call

The prerequisites are a Tabbit install you can log into, a Pro membership for the premium models, and Node 18 or newer. The README describes the project as dependency-free, so cloning it and running the server is the whole install.

First copy the environment template and fill in two fields: the cookie string exported from the browser, and the real version number. The version comes from the browser console, not from guesswork, because it is sent in the x-req-ctx header.

cp .env.example .env

chrome.tabInstance.getDeviceInfo().then(d => console.log(d.tabbitVersion))

That console call prints something like 1.1.39(10101039). Put it into .env along with the cookie you exported using the bundled extension under cookie-helper-extension, loaded via chrome://extensions with developer mode on. Then start the server.

node src/server.mjs

The banner should report port 8787, the auth state and the version. A minimal non-streaming call looks like this:

curl http://localhost:8787/v1/chat/completions ^
  -H "Content-Type: application/json" ^
  -d "{\"model\":\"Default\",\"messages\":[{\"role\":\"user\",\"content\":\"你好\"}]}"

Pointing a GUI client at it is a three-field job: base URL http://localhost:8787/v1, any placeholder API key such as sk-anything, and a model name from the list, for example Default or Claude-Opus-4.8.

Where tabbit-toy breaks or is the wrong tool

The most concrete limitation is stated in the README itself: automatic cookie refresh depends on the WebSocket built into Node 22 and above. On Node 18 or 20 that feature turns itself off and degrades to manual .env configuration. The rest of the proxy still works, but you are back to re-exporting cookies before the JWT lapses, roughly weekly. The README does not document a warning beyond a log line, so a user on Node 20 can believe refresh is on when it is not.

The proxy also inherits the browser's session rather than owning an identity. If Tabbit is not installed, not logged in, or the account loses Pro status, the premium model names in the list stop being usable. There is no documented fallback for that case beyond the free models. The README does not document rollback, rate limiting, request queuing or what happens when two clients hit the same session concurrently, and it does not describe any retry policy for upstream failures other than the auth-error refresh path.

Finally, this is a single-user design. With API_KEY empty by default, anything that can reach port 8787 can spend your membership quota. Binding it to localhost and leaving the key empty is a reasonable personal setup; exposing that port to a network is not something the README supports.

How tabbit-toy differs from LiteLLM and one-api

The obvious comparison is with OpenAI-compatible gateways such as LiteLLM or one-api. Those are built around provider API keys: you register credentials for OpenAI, Anthropic or a self-hosted endpoint, and the gateway handles routing, budgets, retries and multi-user access. tabbit-toy does none of that. It has no concept of multiple upstream providers, no key vault, and no per-user accounting. Its single upstream is a Tabbit browser session, and its credential is a cookie plus a device version string.

The difference in approach matters when you pick one. A gateway is the right shape when several people or services need to share models and you want a record of who spent what. tabbit-toy is the right shape when the models you want are only reachable through one specific browser on your desk and you want them in your local tooling. The README's own multi-version section makes this concrete: the international and domestic Tabbit builds share the same protocol, so you point a second instance at a different backend domain and a different env file, for example npm run start:intl on port 8787 and npm run start:dom on 8788. That is still two personal sessions, not a gateway.

Maintenance, upgrades and the licence question

The repository is not archived, and the last push was on 2026-08-23, which is also the date of release v1.1.0; v1.0.0 landed on 2026-06-23. Two releases in roughly two months is a modest cadence for a project that tracks a third-party web backend, and it tells you something about the upgrade model: most breakage will come from Tabbit changing its endpoints or signing, not from tabbit-toy's own code. The README already documents the reverse-engineered surface it depends on, including /chat/sign-key, /proxy/v1/model_config/models and /api/v1/chat/completion, plus the check-in endpoints under /api/commerce/activity/v1/sign-in. Any of those can move without notice.

Upgrading is light because there are no dependencies to reconcile: pull the new revision, keep your .env, and restart node src/server.mjs. The scripts/probe.mjs utility exists for exactly the situation where a new Tabbit build breaks something, since it can exercise the chat and model steps separately.

On licensing: the repository does not state a licence. The README and package.json are the files that would normally carry one, and neither does. Treat that as an open question rather than an implied permission. If tabbit-toy is going anywhere near a commercial environment, the absence of a licence identifier is something to resolve with the author before you depend on it, not something to assume away.

Editorial conclusion

Adopt tabbit-toy if you already run Tabbit, hold a Pro membership, and want Claude, GPT or Gemini models reachable from Cherry Studio, NextChat or curl on your own machine. Do not adopt it if you need a shared service for a team, a stable public interface, or a licence you can point at during procurement: the repository does not state one. Before relying on it, run node scripts/probe.mjs --step chat to confirm your cookie and version string actually authenticate, and check whether your Node build is 22 or newer, because automatic cookie refresh silently disables itself below that.

Frequently asked questions

Official sources

1. goehou/tabbit-toy on GitHub
2. Issues
3. README
4. Releases