Ten tabs manage accounts, cards, codes, and proxies
The interface groups work into 10 tabs covering account records, email sources, card and redemption-code pools, phone numbers, proxies, billing services, browser profiles, job execution, and logs. Underneath, Python modules handle registration, session refresh, subscription checks, payment links, card assignment, and batch scheduling. SQLite stores the local pools, while PyQt workers keep longer jobs away from the interface thread.
This is Chinese-language software written for a narrow operational niche. The README, setup guide, and security notes are in Chinese, and we found no English README or translated guide in the repository tree. English-only teams would have to translate both the instructions and the risk warnings before judging the code. That is a serious cost when the checkout contains roughly 36,847 lines of source across 112 files.
Most paid workflows require services outside the repository
The README separates a few local actions from flows that need extra infrastructure. Importing an existing session, refreshing it, checking a subscription, and managing SQLite records are described as basic functions. Registration can involve email providers, proxies, a browser-profile service, Playwright, SMS vendors, or a captcha-solving provider. Card and redemption paths add billing data and third-party endpoints.
Two important APIs, cha.nerver.cc and chong.nerver.cc, are maintained by the repository author. The first supports several payment-link and subscription operations; the second handles redemption codes. Their server code is absent, and users must request access keys or build compatible backends. Open issue 1 asks how to obtain those keys and whether the services are paid. It had no reply when fetched.
What happened when we ran it
Our sandbox installed 45 Python packages in 28 seconds and occupied 619 MB. The build succeeded in 9 seconds. Pip-audit reported 0 known vulnerabilities in the installed packages. Those are encouraging repository mechanics for commit 9c3f56a, especially for a desktop application that also includes a vendored registration engine. They say nothing about whether a real account or payment flow will succeed.
Pytest stopped with exit code 1 after 12 seconds. It reported 30 passed and 2 failed out of 32. test_headers_include_openai_target raised a KeyError because x-openai-target-path was absent. test_refresh_session_jar_priority retried a session request, received HTTP 403, found no accessToken, and raised a runtime error. The log does not establish whether remote behavior, a fixture, or implementation logic caused either failure.
The test suite ran inside a fresh unprivileged Debian container with 3 CPUs, 8 GB of RAM, Python 3.12, and no secrets. That environment could install and build the code, yet it could not produce a clean result for the session-refresh tests. Since refresh and re-login are central to the advertised account-maintenance job, these failures matter more than a cosmetic GUI test would.
Local storage contains material that demands strict handling
The first launch creates config.json, an SQLite database, plus log, data, and output directories. According to the security guide, those files may hold account details, card records, cookies, session tokens, TOTP secrets, recovery codes, phone numbers, and service credentials. Git ignores the expected paths, but ignored files can still leak through copied folders, backups, cloud sync, or an exposed workstation.
A 619 MB environment is manageable; the information placed inside it is the larger concern. The guide tells contributors to scan staged changes for payment keys, bearer tokens, session cookies, and card-like number patterns. It also advises deleting runtime artifacts before sharing the project directory. Organizations would still need encrypted storage, access control, retention rules, incident response, and an audit of every external endpoint before placing real data in this application.
No release or CI signal supports unattended operation
GitHub showed 943 stars, 1 open issue, and a last push on August 15, 2026. The sole open issue was created on August 25 and concerns access to the maintainer's private APIs. There was no latest GitHub release, so adopters cannot choose a named stable artifact or read a release history. The repository also had no CI workflow file and no Dockerfile in our scan.
The codebase does include a tests directory, architecture notes, a configuration example, and an MIT license. Its README is candid that APIs and risk controls may change and that the author does not promise stability or successful outcomes. That warning matches our 30-of-32 test result. A recent push shows maintenance, while a one-issue queue is too small to establish how quickly user problems are resolved.
Normal teams should use supported model access instead
For source research, gpt_nerver is unusually explicit about its architecture and dependencies. A reviewer can inspect how one developer organized a desktop UI, single-writer database access, batch runners, provider adapters, and session logic. Keep that work isolated, use test data, and do not treat the repository's disclaimer as permission to ignore service terms or payment controls.
For ordinary use, the decision is much simpler. Open WebUI, NextChat, or LobeChat can give users a managed interface around supported model APIs without automating account creation and Plus billing. gpt_nerver asks operators to trust private endpoints, store high-impact secrets, and chase changing provider behavior. The 2 failed session tests are enough reason to decline it for unattended account operations.