GPT_API_free: A Forwarding Proxy for Cheap Multi-Model API Access
免费大模型API,支持免费调用GPT、DeepSeek等主流模型,免费额度10000点,每日刷新!另付费价格最低官方1-2折!
At a glance
- What is it?
- The repository is not a model server or a client library. It is a documentation and onboarding front end for a hosted relay at api.chatanywhere.tech that speaks the OpenAI wire protocol and resells access to GPT, DeepSeek, Qwen, Kimi, GLM and MiniMax under a quota system.
- Who is it for?
- Adopt it for personal experiments, classroom demos and non-commercial research where you want one OpenAI-compatible endpoint covering GPT, DeepSeek and Qwen without a proxy, and where a hard failure mid-run is survivable.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 8 days ago.
- What is it written in?
- GitHub does not report a main language for this repository.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is billing and network access, not model capability
Most people who want to call GPT, DeepSeek or Qwen from a script run into two walls before they write any prompt logic. The first is payment: official platform accounts want a card in a supported currency, and per-token pricing on frontier models adds up quickly during experimentation. The second is network reach: from mainland China, direct calls to official endpoints need a proxy, and the README states plainly that this relay is reachable without one, describing the domestic route as using dynamic acceleration. GPT_API_free addresses both by inserting a relay between your code and the upstream provider. The repository itself contains no inference code. It is a README, a logo, and instructions for obtaining a key and pointing your existing OpenAI-compatible client at a different host. That is the entire deliverable, and reading it as anything more will lead to wrong expectations.
What the relay changes in your request path
The mechanism is a host substitution. Your client still sends the same OpenAI-style payload it would send to api.openai.com; you change the base URL to https://api.chatanywhere.tech for the domestic route or https://api.chatanywhere.org for use outside China. The README says the interface standard is fully consistent with the official one and that models from other vendors are reached by changing only the model name, with Claude additionally available over Anthropic's own protocol. So the data flow is: your process, relay, upstream vendor, relay, your process. The relay authenticates you with its own key, forwards the call, and returns the response. It also meters usage, which is why the paid tier bills on the token counts returned by the upstream provider. Everything your application knows about the model is still expressed in OpenAI's request and response shape, which is what makes existing plugins and SDKs work without modification.
Free quota arithmetic: points, requests, and the IP ceiling
The free tier is described in two currencies at once, and the numbers do not appear in the same place. The repository description advertises 10,000 points refreshed daily. The README's feature list states a weekly free quota of 50,000 points and a daily limit of 100 requests. The notes section then adds a separate rule: free keys are capped at 200 requests per day per IP and per key, counted separately for GPT and embedding models at 200 each. These figures are not reconciled in the README, and the interaction between the daily request limit and the IP-based cap is not spelled out. The practical reading is that the request count, not the point balance, is the binding constraint for most scripts. The notes also warn that if you run several keys behind one IP, their combined daily requests must stay under 200, and that a single key spread across several IPs is capped the same way. Paid keys, the README states, are not subject to this limit.
Getting a key and pointing a client at it
There is no package to install and no server to run. The README's quick-start path is to register at chatanywhere.tech and bind a GitHub account, which yields a free key. You then set two values in whatever OpenAI-compatible client you already use: the API key, and the base URL. For the domestic route that base URL is https://api.chatanywhere.tech; for use outside China it is https://api.chatanywhere.org. The README states the key is used for the forwarding API and that the host must be changed to one of those two addresses. Model selection happens in the model field of the request, using the names printed in the pricing tables, for example deepseek-chat, qwen3-coder-plus or glm-5.2. Claude is the exception to the uniform-protocol claim: the README says Claude models support Anthropic's official protocol, which means a Claude client can talk to the relay in its native format rather than through the OpenAI shim.
The free tier is weaker than the paid tier on purpose
One line in the notes deserves more attention than it usually gets: free API keys have weaker reasoning on the gpt-5 series, and users who need stronger reasoning are told to buy a paid key. That is an explicit statement that the free route does not deliver the same model behaviour as the paid route, even when the model name is identical. Combined with the ban policy (the README says abusive accounts are banned periodically, with appeals handled through a QQ group) and the disclaimer that the system is for internal evaluation and testing only, the free tier reads as a trial channel rather than a production dependency. There is also a geographic restriction: one pricing table carries a note that certain models are limited to ChatAnywhere's supported countries and regions, linking to a separate document, so model availability is not uniform across users. The README does not enumerate which countries those are.
Paid pricing versus calling the vendors directly
The paid tier is where the economics get interesting and where the documentation gets least precise. The repository description claims prices as low as 10 to 20 percent of official rates. The pricing table shows per-1K-token input and output figures in a unit the README calls CA coins, defined as yuan, with a note that prices move with supplier changes. Several entries carry a two-tier pricing marker, and the table directs readers to the top of the page for peak and off-peak rates, which means a single number in the table is not the whole cost. A few models, including deepseek-v4-pro, qwen3.8-max and glm-5.3, are listed at parity with official pricing, with the discount arriving only after a top-up promotion. Many rows carry the same caveat: the model is supplied by a third party and may occasionally respond slowly or return errors. That caveat is the honest part of the table. The headline discount applies to some models, not all, and the rows where it does not apply are marked.
When a direct vendor account is the better choice
The obvious alternative is an account with each model vendor: OpenAI for GPT, DeepSeek's own platform, Alibaba's DashScope for Qwen, Moonshot for Kimi, Zhipu for GLM. The difference is not model quality, since the relay is passing through to the same upstreams. It is control and accountability. A direct account gives you a service-level agreement, a stable model inventory, first-party support, and a clear data-handling statement from the party that actually runs inference. The relay gives you one key, one protocol and one bill across eight model families, which is a real convenience when you are comparing models in a notebook. But the README itself notes that the model list may lag and that some models may already have been withdrawn upstream, telling readers to treat official information as authoritative. With a direct account, a model disappearing is a vendor announcement. With a relay, it is a table that has not been updated yet. If your workload depends on a specific model version staying available, the relay adds a layer you do not control.
Licence, maintenance and what the MIT tag does not cover
The repository is MIT licensed, which covers the contents of the repository: the README, the logo assets, and whatever else is committed. It does not license the API service. The relay, the keys, the quota system and the pricing are operated by ChatAnywhere under its own terms, and the README's privacy statement, ban policy and commercial-use restriction are part of those terms, not part of the MIT grant. A team that vendors the README into its own docs has done nothing wrong; a team that assumes MIT means it can resell relay access, or use free keys in a commercial product, has misread the situation. On maintenance cost, the repository shows a last push in September 2026 and has no releases, so there is no versioned artifact to pin and no changelog to track. The things that will change are the pricing table, the model list and the status page. If you build against this, the table is the file you will be re-reading, and it is maintained by hand.
Editorial conclusion
Adopt it for personal experiments, classroom demos and non-commercial research where you want one OpenAI-compatible endpoint covering GPT, DeepSeek and Qwen without a proxy, and where a hard failure mid-run is survivable. Do not adopt it as the backbone of a commercial product, a batch training pipeline, or anything that must return an answer every time: the README states the service is intended for internal evaluation and testing, that free keys are barred from commercial use, and that abuse triggers account bans. Before wiring anything in, check status.chatanywhere.tech for current uptime, confirm the model you need is still listed at chatanywhere.tech/pricing, and test your own IP and key against the 200-requests-per-day-per-IP-and-key ceiling, since that number, not the weekly point balance, is what most integrations will hit first.
Community notes