GLM Coding Helper: a Tampermonkey script plus local OCR backend for the Zhipu GLM Coding Plan rush

What the GLM Coding Plan rush assistant actually automates

Zhipu sells the GLM Coding Plan through a limited-drop page at https://www.bigmodel.cn/glm-coding. The README describes a supply situation that has gotten worse: an update note dated 2026-07 states that the domestic plan "basically does not release stock anymore" and that the rush difficulty is extremely high. So the honest framing of this project is not "get the plan faster than everyone else". It is a workflow tool for a page that is hard to operate under time pressure.

The concrete jobs it takes over: unblocking the subscribe button so it can be clicked before the drop, switching plan tier and billing cycle in a configured order, recognizing a Chinese point-and-click captcha through a local OCR backend and clicking the target characters, retrying after rate-limit responses, and keeping several windows warm before restock. It also adds shortcuts, because the last seconds before 10:00 are not a good time to hunt for a button. Esc closes the system-busy or payment popup, Enter or Space confirms the captcha, F8 pauses the script, Shift+F8 pauses every ordinary glm-coding window in the same browser, and F9 toggles automatic subscribe clicking.

The target user is narrow: someone in China buying the GLM Coding Plan on Chrome or Edge who is willing to run a local Python service. Anyone who wants a hosted, zero-install tool is looking at the wrong project.

Architecture: userscript in the browser, OCR server on 127.0.0.1:8888

The repository splits into two halves. In the browser sits glm-coding-helper.user.js, the Tampermonkey script that scans the page, manages the plan and cycle selection, watches for captcha widgets, and issues clicks. On the machine sits a Python backend under backend/, started by the platform launchers, which performs the OCR. The default listen address given in the README is http://127.0.0.1:8888.

That split is the design decision worth noting. Captcha images go from the page to a process on the same machine, not to a cloud recognition API. The README makes this explicit as a feature: CPU/GPU recognition runs locally and captcha images are not uploaded to a third-party service. The cost is that you now own a Python environment, model files, and a port. The repository ships requirements-backend-cpu.txt and requirements-backend-gpu.txt as separate dependency sets, plus a models/ directory, and docs/backend_config.md covers GPU versus CPU auto-selection, worker count, and OCR settings. GPU is optional, not required.

The README also documents a deliberate change of approach. Earlier high-concurrency scripts that pooled and reused captcha tickets have largely stopped working against Zhipu's per-minute request limiting, according to the README. This project moved to single-window, single-request with fresh OCR on every attempt, which lowers request density. Automatic subscribe clicking is off by default, because the README argues that firing at the purchase endpoint before the drop can itself trigger risk control. Rush mode targets 10:00:00 and releases the captcha confirmation conservatively, by max(0, RTT/2 - 20ms) ahead of the target, never before the predicted safe point and never after the target time.

Installing the userscript and starting the backend on Windows, macOS or Linux

The README's recommended path is to download a Release archive rather than clone the repository. Two archive types exist: glm-coding-helper-portable-cpu-*.zip bundles local model and cache files and is recommended for Windows users who want fewer downloads, while glm-coding-helper-online-installer-*.zip is a small package that fetches the CPU or GPU environment on first start and is recommended for macOS and Linux.

Extract to a short, plain-ASCII path. The README warns that some dependency packages have long internal paths and that a deep directory can trigger Windows path-length failures that surface as pip install errors reading No such file or directory. C:\glm-coding-helper is the example given.

Install Tampermonkey from https://www.tampermonkey.net/ in Chrome or Edge, then install the script either from the Greasy Fork page or from the local glm-coding-helper.user.js in the extracted directory. Note that scripts/userscripts/ is kept only for development and old-path compatibility; the root file is the user-facing entry point.

Start the backend with the platform launcher. Windows users double-click one-click-start.cmd, which on first run installs the CPU or GPU environment (auto-detecting an available PyPI mirror) and afterwards starts the backend plus a Tk GUI. macOS on Apple Silicon has two launchers, and Linux needs the executable bit set first:

chmod +x one-click-start.sh scripts/setup_backend_linux.sh
./one-click-start.sh

On Linux the first run installs the environment and starts captcha_server headless, with no Tk window. Once running, the backend listens on http://127.0.0.1:8888. Open the plan page and confirm the script is active:

https://www.bigmodel.cn/glm-coding

If nothing happens in Chrome, open the extension details page and enable Developer mode, Allow user scripts, and Allow in incognito if you use incognito windows. The README reports testing at 1080p to 1920p, 100%-150% desktop scaling and 50%-125% browser zoom, and suggests 1920p with 100%-125% desktop scaling and 100% browser zoom when clicks land in the wrong place.

Risk control, rate limits and the limits the script cannot cross

The README is unusually direct that the main obstacle is on Zhipu's side. A note dated 2026-06-23 describes an upgrade to click interception: automatic clicks on the subscribe button are occasionally blocked or rejected, and manual clicks get blocked too, with the page returning a message about the URL potentially posing a security threat. The suggested responses are to wait about ten seconds and retry, or to click the discounted-subscribe entry manually, which still enters the purchase flow. Captcha recognition, character clicking and confirmation continue to work regardless of how the entry was clicked, because the README says automatic clicking and OCR are decoupled.

Separately, per-minute request limiting has been tightened. The README states that many high-concurrency, multi-window scripts that reuse captcha tickets have failed broadly, and that the project's answer is one window and one request at a time with live OCR. It recommends a single window explicitly, and if you believe you are being flagged, raising the captcha click delay in the configuration panel rather than opening more windows. The default random delay is 250-400ms, with 300-450ms and 350-500ms offered as more conservative settings.

The failure mode that matters most is not technical. The README says Zhipu has released almost no stock recently and that this is a supply-side decision, not a script defect: "no matter how fast, it is useless if there is no stock." There is also a practical signal to learn: a payment page without an amount means you did not get the plan, and you should close it and keep trying. And the README states plainly that success depends on stock, rate limits, account state and payment speed, and that the script cannot guarantee a purchase.

How this differs from ticket-pooling and cloud-captcha userscripts

The obvious alternative in this niche is the high-concurrency userscript that opens many windows, pre-solves captchas, and reuses the resulting tickets across attempts. That approach optimizes for request throughput. This project optimizes for request freshness and for keeping the image local, and the README argues the throughput approach is now counterproductive because Zhipu's per-minute limiting returns system-busy, 500 or 555 responses to dense traffic. The trade is real in both directions: a ticket-pooling script can theoretically fire faster when it works, while this one is slower by design and depends on a local service being up.

A second alternative is a cloud OCR API called from the userscript. That removes the Python environment and the models/ directory entirely, and it works on any machine that can run a browser extension. The difference is where the captcha image goes. This project's README treats local inference as the point, so a cloud service is not a drop-in substitute if that property is what you need. A third option is simply doing it by hand with the page open; the README's own guidance about manual clicking on the discounted-subscribe entry suggests that is a legitimate fallback when automatic clicking is blocked.

Outside the captcha layer, the README points to a sibling project, LLM API Ledger, which crowdsources real usage figures for coding plans from several vendors. That is a comparison tool, not a competitor to this script, and it answers a different question: what you get after you have a plan.

Maintenance, release cadence and the GPL-3.0 licence

The repository is not archived, and the last push was on 2026-07-30, which is roughly seven weeks before the date of this writing. The release history shows three tagged builds in about five weeks: v2026.06.26-0145, v2026.06.27-2125 and v2026.07.30-1030. That cadence matches a project tracking a moving target, since the README's own notes are dated by the day a vendor changed something. It also means upgrade cost is not zero: a new release can change backend dependencies, so a working environment is worth keeping rather than rebuilding blindly.

The practical upgrade path is the one the README describes for first install. Re-download the Release archive, extract it over or beside the old directory, and relaunch with one-click-start.cmd, one-click-start.command or ./one-click-start.sh. The README states that the launcher detects and repairs a damaged environment, and that the first run after an upgrade may reinstall dependencies. Fixes are logged in CHANGELOG.md, which is the file to read before assuming a behaviour change is a bug. Backend tuning lives in docs/backend_config.md, and platform setup notes live in docs/macos-setup.md and docs/linux-setup.md.

The licence is GPL-3.0. That matters if you intend to redistribute a modified build: GPL-3.0 carries source-disclosure obligations for derivative works. It does not restrict private use. Nothing here is legal advice, and the repository does not appear to ship a separate commercial-licence option in the files reviewed.

Editorial conclusion

Use it if you already run Chrome or Edge, are comfortable launching a local Python backend, and want captcha recognition that never uploads images to a third party. Do not use it if you expect a purchase guarantee, if you rely on Firefox or Safari (the README says only Chrome and Edge are supported), or if you plan to run many parallel windows; the README states that more windows mean denser requests and more rate-limit risk. Before relying on it, verify that the userscript is enabled, that the backend answers on http://127.0.0.1:8888, and that your display is set near 1920p with 100%-125% desktop scaling, which is the range the author reports testing.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes