FreeDeepseekAPI: a local OpenAI-compatible proxy for DeepSeek Web Chat

What FreeDeepseekAPI solves, and for whom

DeepSeek Web Chat is a browser product. There is no documented HTTP interface for it, so anything that speaks the OpenAI wire format, such as Open WebUI, LiteLLM, Hermes, Claude Code or an OpenAI SDK client, cannot talk to it directly. FreeDeepseekAPI fills that gap by running a local server that accepts OpenAI-shaped requests and forwards them to chat.deepseek.com through a saved browser session tied to your own logged-in account. The README describes the target audience precisely: people who already have a DeepSeek Web login and want to drive it from OpenAI-compatible tooling. It is not a way to obtain an API key, and it does not remove the need for an account. The README's own warning is blunt: this is an experimental web-chat proxy, DeepSeek may change the internal Web API without warning, and the official paid DeepSeek API is the more dependable choice for production cases. Treat that sentence as the project's scope statement rather than as marketing hedging.

How the proxy bridges a browser session to /v1/chat/completions

The architecture is a single Node.js process. server.js is the entry point and lib/ holds the supporting modules, including lib/pow.js, which the test script syntax-checks alongside the auth and doctor scripts. Requests arrive at POST /v1/chat/completions, POST /v1/messages or POST /v1/responses. The proxy resolves the requested model alias against GET /v1/model-capabilities, which maps an alias to a real web mode, then drives the DeepSeek web session and converts the result back into the caller's expected shape. Streaming is delivered as SSE chunks, and non-stream requests return ordinary JSON. Reasoning models surface their thinking in a separate reasoning_content field rather than mixing it into the message body. Tool calling is parsed from OpenAI tools, Anthropic tools and Responses function tools. Sessions are keyed per user or agent id, so different agents can hold separate DeepSeek web sessions, and the README lists session recovery as an automatic reset of stale chains. The zero-dependency claim in package.json is real: there is no dependencies block, only an engines field requiring Node.js 18 or newer.

Installing FreeDeepseekAPI and running a first request

The README's quick start is four commands. npm run auth opens an interactive menu where you pick option 1, log into DeepSeek in a separate Chrome profile, send a short message such as ok, then return to the terminal and press Enter. npm start then shows a launch menu with options for refreshing the login, listing models and statuses, starting the proxy, or exiting.

git clone https://github.com/ForgetMeAI/FreeDeepseekAPI.git
cd FreeDeepseekAPI
npm run auth
npm start

The server listens on http://localhost:9655 by default and is reachable only from the local machine. For headless or CI use, the README gives two environment switches that skip the menu.

NON_INTERACTIVE=1 npm start
# or
SKIP_ACCOUNT_MENU=1 npm start

To reach the proxy from another host, you must set both an address and a bearer token. The README is explicit that without PROXY_API_KEY the non-health endpoints stay unauthenticated, so an instance bound to 0.0.0.0 without a key should not be exposed.

HOST=0.0.0.0 PROXY_API_KEY='replace-with-a-long-random-value' npm start

Clients then send Authorization: Bearer <key>. Browser requests are accepted only from loopback origins unless you list exact origins in PROXY_CORS_ORIGINS, comma-separated, for example https://ui.example.com,http://192.168.1.20:3000. .env.example documents the rest of the surface: PORT defaults to 9655, HOST to 127.0.0.1, DEEPSEEK_AUTH_PATH to ./deepseek-auth.json, and DEEPSEEK_ACCOUNT_COOLDOWN_MS to 600000. A Containerfile is present for rootless Podman, but the README states the container is for non-interactive proxy runs only; auth scripts and deepseek-auth.json are not copied into the image, so you authenticate on the host first.

Headless hosts, auth import and the doctor script

Running this on a VPS is the part most likely to go wrong, and the README addresses it directly. The recommended flow is to authenticate on a desktop with a GUI, then copy deepseek-auth.json to the server and import it. The import script accepts either a ready-made auth file or a browser cookie export, in which case you pass the token through DEEPSEEK_TOKEN. After importing, npm run doctor -- --offline checks the file without touching the network. The README also states that deepseek-auth.json is access to your DeepSeek Web login, that it must not be committed or published, and that it should be stored with 0600 permissions. That is the single most important operational fact about this project: the credential is a full session, not a scoped key, so the blast radius of a leak is your account rather than one API quota. Note that the doctor script is described as an offline check; the README does not document a live connectivity test under that command, so treat a clean doctor run as file validation, not as proof that the upstream session still works.

Where the web-chat approach breaks down

The README's own warning is the honest limitation: DeepSeek can change the internal Web API without notice, and the project is labelled experimental. Anything built on an undocumented endpoint inherits that fragility, and no amount of local code quality changes it. There are secondary constraints worth reading in .env.example. DEEPSEEK_MAX_PROMPT_CHARS defaults to 80000, and the comment says to lower it if the Web endpoint reports that content is too long, which means long agent sessions are compacted before sending and context is not unlimited. DEEPSEEK_MAX_RETRIES defaults to 2 for empty or context-too-long responses, so a persistent failure surfaces as an error rather than an infinite retry. Accounts that return HTTP 401, 403 or 429 are put on a cooldown of 600000 milliseconds by default. That cooldown is a rate-limit signal dressed up as account management: if you hit it often, the web endpoint is telling you that this usage pattern is not welcome. The proxy is also the wrong tool when you need a contractual SLA, predictable latency, or per-request billing visibility. For those, the official paid DeepSeek API is the correct answer, and the README says as much.

FreeDeepseekAPI versus OpenRouter for free DeepSeek access

OpenRouter routes requests to hosted model providers and gives you one API key across many models, including free-tier DeepSeek variants. FreeDeepseekAPI does the opposite: it keeps everything on your machine and forwards to a single upstream, the DeepSeek web chat you are already logged into. The practical differences follow from that split. With OpenRouter, the credential is an API key issued by a third party and the provider handles session management, rate limits and model routing. With FreeDeepseekAPI, the credential is your own browser session, the routing is a single hard-coded destination, and you own the failure modes: Chrome profile path, auth file permissions, CORS origins, cooldown state. OpenRouter gives you a documented, stable interface and someone else's uptime; FreeDeepseekAPI gives you no third party in the path and no cost per token, at the price of depending on an interface that the README says can change without warning. Neither is strictly better. They fail in different places.

Maintenance cost, licence and the upgrade question

The repository is not archived and the last push was on 2026-07-13, roughly two months before this writing, so it has seen recent commits. There are no retrieved releases, which means there is no versioned upgrade path to follow: package.json still reads 0.1.0, and the README does not document a rollback procedure or a migration guide. Upgrades therefore mean pulling main and re-reading the README, and the practical risk is that a change in the DeepSeek web flow lands as a code change rather than as a version bump you can pin against. The licence is MIT, stated in LICENSE and in package.json, which permits commercial use and modification provided the copyright notice and permission notice are retained. That is a statement about the licence text, not legal advice; if you redistribute the proxy inside a product, have someone qualified read the MIT terms and the DeepSeek terms of service together, because the licence covers the code and says nothing about your account. The zero-dependency design keeps the supply-chain surface small and means npm install is not part of the setup, which is a genuine maintenance advantage over proxies that pull in a browser automation stack.

Editorial conclusion

Adopt FreeDeepseekAPI if you want DeepSeek Web Chat reachable from Open WebUI, LiteLLM or an OpenAI SDK client on a machine you control, and you accept that the upstream Web API can change without notice. Do not adopt it for production traffic, for multi-tenant services, or anywhere you cannot keep deepseek-auth.json at mode 0600. Before trusting it, run npm run doctor -- --offline on the target host and confirm that the model alias you plan to call appears in GET /v1/model-capabilities.

Frequently asked questions

Official sources

1. ForgetMeAI/FreeDeepseekAPI on GitHub
2. Issues
3. License: MIT
4. README