grok-register

xinxinshuhao-create/grok-register is ranked 17,822 among these 8 peers; labteral/chatgpt-python is ranked 17,817.

grok-register Automated account registration toolkit for x. ai (Grok) with SSO token extraction, OAuth Device Flow minting, and auto-replenish daemon for API gateway integration. Architecture Deliberately abstract: this section explains **why the system is shaped this way**. Separation of concerns This repository owns **account acquisition and lifecycle**. A gateway (grok2api) owns **routing and load-balancing**, and may itself sit behind a multi-channel proxy layer. The handoff between the two is a directory of credential files: this repo

writes them, the gateway imports them. Keeping those apart means the acquisition logic never needs to know about request routing, and the gateway never needs to know how an account was obtained. The practical consequence is isolation: a failure in the OAuth path degrades the Build pool without touching the Web pool, and vice versa. ** The pipeline pushes the Web pool before attempting OAuth. The Web push only needs the SSO token, which registration already produced; the Build push depends

on an OAuth exchange that can fail. Ordering it this way means a partial failure still yields usable accounts instead of nothing. ** A solver-backed engine (paid CAPTCHA API, HTTP-only) is the default because it has the higher success rate and runs faster. A browser-backed engine (headless-capable stealth browser, solves the challenge in-page) exists as a free fallback. Neither is strictly better: the paid path costs money per attempt, the browser path is several times slower

and needs a real rendering environment. The choice is exposed as a flag rather than hard-coded, so the operator can trade cost against reliability per situation. ** The PKCE flow is lighter but was blocked by the upstream bot filter, so a Device Authorization Grant flow was added as the primary path: it drives a real browser session through the consent screen. The selection falls back automatically when the preferred module is unavailable. **Egress binding is a hard precondition, not

an optimisation. ** A Web-pool account is only counted as *available* once it has an egress node assigned. Binding is therefore part of the import path, not a separate maintenance step. **Thresholds carry headroom, and batches are capped. ** The replenisher triggers on the *worse* of the two pools rather than either one, so a healthy pool cannot mask a starving one. The cap is deliberate: registering in bulk is exactly the pattern upstream anti-abuse systems look for. ** Expiring credentials

are refreshed in place before they lapse; credentials whose *refresh* token has been revoked cannot be refreshed at all and are re-minted from the original SSO. The second path is strictly more expensive, which is why refresh runs continuously and re-minting is an explicit operation. ** Batch uploads were measured to fail far more often than one-at-a-time uploads against the same endpoint, so the pipeline trades round-trips for reliability. Removed by choice: proxy rotation An

earlier version rotated the outbound proxy between registrations. Registration and minting now share one static outbound proxy. The tradeoff is