Chat2API: a desktop proxy that turns vendor web sessions into an OpenAI-compatible endpoint
Chat2API enables zero-cost access to leading AI models by leveraging official web UIs. It supports providers such as DeepSeek, GLM, Kimi, MiniMax, Qwen, and Z.ai, and seamlessly integrates with tools like openlcaw, Cline, and Roo-Code.
At a glance
- What is it?
- An Electron app that accepts your web login for DeepSeek, GLM, Kimi, Qwen and others, then serves them to any OpenAI-compatible client from a local port. It is a credential router, not a model host.
- Who is it for?
- Chat2API fits a specific situation: you have a subscription or free tier on a vendor web service, and you want your own tools to reach it through one local OpenAI-shaped endpoint instead of eight separate integrations. For that job the design is coherent, because context management, model mapping and request logs all exist to make a browser session behave like an API server.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 137 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 11, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What the app actually is: a session broker with a UI
Chat2API is an Electron 33+ desktop application with a React 18 renderer and TypeScript 5 throughout. Its pitch is in one sentence from the README: it enables zero-cost access to leading AI models by leveraging official web UIs, then re-exposes them as OpenAI-compatible endpoints so that tools written against that API work without modification.
The mechanism is worth stating plainly, because it determines everything else. No model runs on your machine. The app holds whatever credential your vendor web session uses, calls the vendor's own web endpoints on your behalf, and translates the response into the OpenAI response shape. The README says this in its own provider section by listing an auth type per vendor: user token, refresh token, JWT token, cookie, SSO ticket. None of those is an API key. Every one of them is something a browser holds after a person logs in.
That single design choice explains the feature list. Custom HTTP headers that enable web search, thinking mode and deep research are not extra integrations, they are flags the vendor's web client sends. Model mapping with wildcard support is not catalog management, it is translating your client's model name into a name the vendor's web backend recognizes. Context management with sliding window, token limit and summary strategies exists because a web session has a shorter memory than an API key has.
The tree supports this reading. Alongside `src/`, `components/` and `tests/` there is `docs/providers/` with a providers README, an `AGENTS.md`, a `CODE_WIKI.md`, a `skills/` directory, and a `sha3_wasm_bg.7b9ca65ddd.wasm` blob at the root. That last file is a hint about integrity checking somewhere in the request path.
The provider table and what each auth type implies
The README's provider table is the most informative part of the documentation, because auth type is the variable that decides whether a given vendor works for you.
DeepSeek takes a user token with OAuth support, listing deepseek-v4-flash and deepseek-v4-pro. GLM takes a refresh token and lists GLM-5.1. Kimi takes a JWT token and lists Kimi-K2.6. MiniMax takes a JWT token and lists MiniMax-M2.7. Mimo takes a cookie and lists MiMo-V2.5-Pro, MiMo-V2.5 and MiMo-V2.5-Flash. Perplexity takes a cookie with the model shown as Auto. Qwen in the China region takes an SSO ticket, and Qwen AI in the global region takes a JWT token, each listing several Qwen 3.x variants including Qwen3-Coder.
Z.ai is the row that teaches the lesson. The table lists it with a JWT token and then states it is temporarily unavailable due to frontend captcha risk control. That is not a missing feature, it is a vendor-side defense reacting to automated access. Any provider listed here can behave the same way, and the README's own row is the evidence.
Cookie-based entries carry a different risk profile from token-based ones. A cookie is a session artifact that a vendor can invalidate at any time and that may be bound to a device fingerprint, so a cookie entry will need more babysitting than a JWT. The README points to `docs/providers/README.md` for provider adaptation notes and for adding models by hand, which is the file to read when a vendor's web payload changes and you need to patch the adapter yourself.
Installing: a download or a source build
The README offers two paths. The first is a release download, with a table mapping each platform to a file:
| Platform | Download | | --- | --- | | macOS (Apple Silicon) | `Chat2API-x.x.x-arm64.dmg` | | macOS (Intel) | `Chat2API-x.x.x-x64.dmg` | | Windows | `Chat2API-x.x.x-x64-setup.exe` | | Linux | `Chat2API-x.x.x-x64.AppImage` or `.deb` |
The second is building from source, which needs Node.js 18 or newer, npm and Git. The clone and install steps are:
git clone https://github.com/xiaoY233/Chat2API.git
cd Chat2API
npm installThe package manifest defines a full build matrix. `build:win` and `build:win32` target 64-bit and 32-bit Windows, `build:mac` and `build:mac-arm` target Intel and Apple Silicon macOS, `build:linux` covers Linux, and `build:all` runs all three in sequence. Each one first runs the Vite build and then hands off to electron-builder. There is also `build:unpack` for a directory build without an installer, and a `release` script that calls `node scripts/release.js`.
Two hooks are worth knowing about. `postinstall` runs `electron-builder install-app-deps`, so native modules are rebuilt for the Electron ABI rather than the system Node ABI. And `build` begins with `npm run check:source-artifacts`, a script under `scripts/` that validates something about source artifacts before the real build starts, which suggests the project guards against shipping incomplete generated files.
Version drift between the badge, the manifest and the releases
Three version numbers in this repository disagree, and the pattern is normal for an actively maintained desktop app rather than a sign of anything broken.
The README's badge row reads Release v1.3.0. The package manifest says `version` is 1.4.0. The most recent release is dated 2026-05-27 and its notes describe a managed tool calling redesign with an OpenAI-compatible tool calling engine, multiple protocol parsers for managed XML, managed bracket syntax, Anthropic-style tool use and Codex Responses-style payloads, plus streaming tool-call chunk parsing so compatible clients receive deltas more reliably.
The badge lagging the manifest is the ordinary failure mode of a README that gets updated in batches rather than on every release. Trust the manifest and the releases page over the badge.
The release notes are worth reading for what they say about direction. The 2026-05-27 release reworked tool calling across several wire formats at once, which means the app is trying to be usable from clients that speak different dialects. A previous release added automatic in-app updates with progress tracking and bilingual UI, and another moved request log persistence to standalone NDJSON with migration, retention limits, buffered writes and sanitization controls.
The NDJSON detail is the one with operational weight. Moving logs out of whatever store Electron provided, into flat files with explicit retention and sanitization, is what you have to do before a request log can be left running on a shared machine. Sanitization controls specifically suggest the logs contain credential-adjacent data, which is consistent with an app that brokers sessions.
Context management, function calling and the proxy configuration surface
The features list is long enough that it is worth sorting into three groups: things that make a web session behave like an API, things that manage your credentials, and things that observe traffic.
In the first group, context management is described as intelligent conversation context management with sliding window, token limit and summary strategies. That is the piece that makes long agent sessions viable, since a vendor web session will not hold an entire conversation the way a key-based endpoint might. Function calling is implemented through prompt engineering rather than native tool protocols, which the README is candid about, and the newest release notes describe moving that toward managed tool parsing across several formats.
In the second group: API key management for the local proxy itself, model management for viewing and editing the models available from all providers, and proxy configuration with routing strategies. The app generates keys for its own endpoint, so anything pointed at it authenticates to Chat2API rather than to the vendor.
In the third group: a dashboard for real-time request traffic, token usage and success rates, plus detailed request logs for debugging.
The desktop shell also brings system tray integration for status from the menu bar, and the UI ships English and Simplified Chinese with dark and light themes. The `build/` directory referenced by the manifest holds the application icons that the README displays at the top.
Licensing, compliance and where this approach stops working
The README badge reads GPL-3.0, the package manifest declares `license` as GPL-3.0, and a LICENSE file is present in the repository tree. The repository metadata classifies the license as NOASSERTION, which is GitHub's label when it cannot detect a license from the files, so the badge and the manifest agree and the metadata field is the odd one out. GPL-3.0 is a copyleft license, and that has a practical consequence: if you modify Chat2API and distribute it, you owe source availability. Using it as a local proxy for your own traffic is a different situation from shipping a modified build, and this is not legal advice, so read the LICENSE file before you package anything.
The deeper limitation is not licensing. It is that every provider here is a web service with its own defenses, and the Z.ai row documents what happens when one of those defenses activates. Vendor web endpoints change their payloads without notice, token refresh flows get revised, and captcha risk control can appear on a provider that worked yesterday. The release history shows the maintainer responding to exactly this by adding DeepSeek V4 Pro and V4 Flash compatibility, Kimi K2.6 request payload behavior and DeepSeek Expert model mapping support. That is reactive maintenance against a moving target.
If you need a production API with predictable behavior, the honest comparison is against paying the vendor directly for API access. Chat2API wins when you already have web access and want tools to use it. It loses when uptime matters, when you need to serve other people, or when a provider's terms prohibit automated access to consumer endpoints. Read the terms of each service you connect.
Editorial conclusion
Chat2API fits a specific situation: you have a subscription or free tier on a vendor web service, and you want your own tools to reach it through one local OpenAI-shaped endpoint instead of eight separate integrations. For that job the design is coherent, because context management, model mapping and request logs all exist to make a browser session behave like an API server. Two things decide whether it is appropriate for you. First, you are authenticating with a user token, refresh token, JWT, cookie or SSO ticket rather than an API key, which means access depends on a session that can expire or be challenged, and the Z.ai row in the provider table is already listed as temporarily unavailable for exactly that reason. Second, the licensing is GPL-3.0 per the badge and the package manifest, so anything you build on top of it carries copyleft obligations. The last push was on 2026-05-28.
Frequently asked questions
Is Chat2API safe to use with my accounts?
It requires real credentials per provider: user tokens, refresh tokens, JWTs, cookies or an SSO ticket, depending on the service. The README is explicit that the app leverages official web UIs, so your traffic is sent through those web endpoints using your own session. Treat it like any other app holding your login, check what the request logs record, and review each vendor's terms on automated access.
Which providers can Chat2API connect to right now?
The README's provider table lists DeepSeek, GLM, Kimi, MiniMax, Mimo, Perplexity, Qwen for the China region, Qwen AI for the global region, and Z.ai. Z.ai is marked temporarily unavailable due to frontend captcha risk control, which is the clearest example in the table of a vendor-side defense blocking automated access.
Do I need an API key for each provider to use Chat2API?
No API keys. The provider table lists the auth type per service, and they are all web session credentials: a user token for DeepSeek, a refresh token for GLM, JWT tokens for Kimi, MiniMax and Z.ai, cookies for Mimo and Perplexity, and an SSO ticket for Qwen in the China region. You need API keys only for tools connecting to Chat2API itself.
What is the difference between the OpenAI API and ChatGPT?
They are different products with different access models. The OpenAI API is a programmatic endpoint authenticated with API keys, metered per token, with documented rate limits. A ChatGPT subscription is a consumer product with a web interface and per-user usage caps. Chat2API sits between them: it takes the consumer web session and republishes it as an API shape for local tools.
Can I build from source on Linux?
Yes. The README lists Node.js 18 or newer, npm and Git as the requirements, then a clone and `npm install`. The package manifest has a `build:linux` script that runs the Vite build followed by electron-builder, and releases are published as an AppImage or a .deb package for Linux.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/xiaoy233-chat2api)