GLM Coding Helper: A Tampermonkey Script That Automates Chinese Click Captchas for Zhipu's GLM Coding Plan
GLM Coding Plan CPU/GPU OCR. Zhipu GLM Coding Plan snap-up assistant, one-click snap-up oil monkey script, local CPU/GPU OCR automatic recognition Chinese click verification code, supports multi-window concurrency, current limit retry and payment page protection
At a glance
- What is it?
- This project pairs a Tampermonkey userscript with a local CPU/GPU OCR backend to automate the purchase flow for Zhipu's GLM Coding Plan, including Chinese click captcha recognition. It is a niche tool for a shrinking supply, and its value depends on how long the official sale continues.
- Who is it for?
- Adopt this if you are a GLM Coding Plan subscriber on Chrome or Edge who faces the daily 10:00 purchase window and wants to reduce manual refresh and captcha clicking. Do not adopt it if you expect guaranteed purchase success, because the README is explicit that Zhipu has tightened supply and risk control, and even manual clicks can be blocked.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 48 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 14, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What This Script Actually Does
The project solves a narrow problem: buying a Zhipu GLM Coding Plan subscription during a limited daily sale at 10:00, where the page shows a Chinese click captcha that requires selecting characters in order. The README lists the core features: it removes the disabled state from subscription buttons, switches plans and billing cycles according to a configured order, and when a captcha appears, it calls a local OCR backend to recognize the target text and click it. The script also supports multi-window monitoring, rate-limit retry, and a rush mode that waits until a target time before auto-clicking. The intended user is someone who subscribes to GLM Coding Plan, uses Chrome or Edge, and is willing to run a local backend on Windows, macOS, or Linux. The project explicitly states it only works on Chrome and Edge, and recommends Chrome. The README also notes that the original discount entry via invite code has been discontinued, so the script now opens the GLM Coding page directly.
The Local OCR Backend: CPU and GPU, No Third-Party Upload
The captcha solving is not done in the browser. The Tampermonkey script communicates with a local backend that runs a captcha_server on http://127.0.0.1:8888. The backend can run on CPU or GPU, and the README says it automatically selects between them. A key design point is privacy: the captcha image is never uploaded to a third-party service. The backend is Python-based, and the release packages include either a portable CPU version with model files bundled or an online installer that fetches the environment on first run. The README directs users to docs/backend_config.md for details on GPU/CPU selection, worker count, and OCR configuration. The backend also includes a Tk GUI on Windows and macOS, while Linux runs headless. This local-first approach is a deliberate contrast to cloud OCR services, which would add latency and potential privacy risk. However, the trade-off is that the user must install and maintain a Python environment, which is a significant barrier for non-technical users.
Getting It Running: Release Packages and One-Click Starters
The README gives a clear five-step setup. First, download a release zip from the GitHub Releases page. For Windows, the portable-cpu package is recommended because it bundles model files; for macOS and Linux, the online-installer is the smaller option. Second, extract to a short, purely ASCII path like C:\glm-coding-helper, because deep paths can trigger Windows path length limits during pip install. Third, install the Tampermonkey userscript, either from Greasy Fork or by copying the local glm-coding-helper.user.js file into a new script. Fourth, start the backend: on Windows double-click one-click-start.cmd, on macOS run one-click-start.command, on Linux run ./one-click-start.sh after chmod +x. The backend listens on port 8888. Fifth, open https://www.bigmodel.cn/glm-coding. The README also lists specific Chrome extension settings: enable developer mode, allow user scripts, and for incognito use, enable the script in incognito windows. This is a concrete, reproducible setup, but it assumes the user can follow multi-step instructions and troubleshoot environment issues.
The Purchase Flow and Rush Mode Timing
The script's behavior during the sale is carefully timed. The README describes a rush mode with a default target of 10:00:00. In this mode, the script scans the page but does not auto-click the subscription button before the target time. After the target time, it enters the purchase chain. The captcha confirm button is released based on measured round-trip time (RTT), with a conservative formula: max(0, RTT/2 - 20ms) early. This means the script tries to click confirm at the predicted safe point, not before the server responds. The README also warns that Zhipu has upgraded risk control, and even manual clicks can be blocked with a message about URL security threats. In that case, the recommended response is to wait about 10 seconds and retry, or manually click the special offer entry. The captcha OCR and the subscription click are decoupled, so the OCR will still handle the captcha even if the entry is clicked manually. This timing logic is the core value of the script, but it is also fragile because it depends on server-side behavior that the project cannot control.
Rate Limits, Risk Control, and the Single-Window Advice
The README is unusually honest about the failure modes. It states that Zhipu upgraded RPM (requests per minute) risk control in June 2026, and that many competing scripts using high-concurrency multi-window and ticket reuse have largely failed, returning errors like 500 or 555. The project's approach is single-window, single-request with fresh captchas on each request, avoiding ticket reuse. The README strongly advises using only one window, because more windows mean denser requests and a higher chance of triggering risk control. It also recommends increasing the captcha click delay from the default 250-400ms to 300-450ms or even 350-500ms if rate limiting is severe. This is a direct admission that the script's own concurrency feature is counterproductive under current conditions. The multi-window support exists, but the project itself recommends against using it. This is a genuine limitation: the tool's headline feature is undermined by the very risk control it tries to bypass.
What the Script Does Not Do by Default
Several actions are disabled by default to avoid triggering risk control. The script does not auto-click the subscription button until the user presses F9 or enables it in the config panel. It does not auto-click the captcha confirm button unless explicitly enabled. It does not auto-close invalid payment links or rate-limit popups unless enabled. The README explains this is intentional: before the sale opens, normal users cannot press the purchase entry, so auto-clicking would hit critical APIs and trigger risk control. This means the user must actively configure the script to perform the full automation. The default behavior is to observe and remind, not to act. This is a sensible safety design, but it also means the script is not truly one-click out of the box. A user who expects full automation must read the config panel and enable the right toggles. The README also notes that if a payment page shows no amount, that means the purchase failed, and the user should close it and continue.
Maintenance, License, and the Supply Problem
The project is under active development, with releases dated 2026-06-25, 2026-06-27, and 2026-07-30. The CHANGELOG.md file tracks fixes, and the README mentions automatic environment repair on Windows if the backend is corrupted. This suggests the project is maintained, but the maintenance burden falls on the user: each release may change the backend or script, and the user must update both. The license is GPL-3.0, which means any derivative work must be distributed under the same license. This is relevant if someone wants to modify the script for another platform or another captcha service. The biggest maintenance concern is external: the README's top warning from July 2026 says Zhipu's domestic GLM Coding Plan is barely releasing inventory, making the purchase extremely difficult. The project even redirects users to a comparison list of other coding plans from other vendors. This means the script's usefulness is directly tied to a supply that the project itself describes as nearly gone. If the sale ends, the script becomes obsolete. The project's own Telegram group and sister project, LLM API Ledger, suggest the author is moving toward broader plan comparison rather than just purchase automation.
Editorial conclusion
Adopt this if you are a GLM Coding Plan subscriber on Chrome or Edge who faces the daily 10:00 purchase window and wants to reduce manual refresh and captcha clicking. Do not adopt it if you expect guaranteed purchase success, because the README is explicit that Zhipu has tightened supply and risk control, and even manual clicks can be blocked. Before using it, verify your display scaling (1920p, 100%-125% desktop zoom, 100% browser zoom), confirm you can run a local Python backend, and check the docs/backend_config.md for OCR worker settings. The project is GPL-3.0, so any redistribution of modified scripts must carry the same license. The core judgement: this is a well-documented automation for a specific, shrinking sale, not a general-purpose purchase bot.
Community notes