Automated account registration toolkit for x.ai (Grok) with SSO token extraction, OAuth Device Flow minting, and auto-replenish daemon for API gateway integration.

• Account registration (grok.py) — curl_cffi-based engine, supports YesCaptcha for Turnstile solving
• SSO → CPA token minting (sso_to_cpa.py) — OAuth PKCE flow (with consent-form submit), converts SSO tokens to access/refresh tokens
• Device Flow minting (device_mint.py) — OAuth 2.0 Device Authorization Grant, the fallback path used by the re-mint helper when PKCE is blocked by Cloudflare
• Auto-replenish daemon (auto_replenish.py) — monitors account pool, registers new accounts on demand, pushes to API gateway
• Token refresh daemon (token_daemon.py) — keeps tokens alive
• OAuth token re-minting (remint_oauth.py) — re-mints revoked tokens when xAI invalidates them; delegates to device_mint.py (Device Flow)
• Turnstile solver (turnstile_solver_local.py) — local CAPTCHA solving service (Patchright)
• CloakBrowser solver (cloakbrowser_solver.py) — stealth-Chromium CAPTCHA solving service (CloakBrowser)
• Email service (email_service.py) — multi-provider support (LuckMail, MailNest)
• Clash proxy rotator (clash_rotator.py) — ⚠️ no longer wired into the pipeline (rotation removed 2026-09-18; registration/minting now use a single static proxy via GROK_PROXY). File retained for reference only.

Deliberately abstract: this section explains why the system is shaped this way. Host addresses, node identifiers, proxy providers and pool sizes are intentionally omitted — see the source for operational detail.

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.

Accounts land in one of two pools, and they are not interchangeable:

The split exists because the two upstream surfaces authenticate differently and expose different capabilities. The practical consequence is isolation: a failure in the OAuth path degrades the Build pool without touching the Web pool, and vice versa.

  acquire                      mint                       pool
  ───────                      ────                       ────
  ┌────────────────────┐   ┌──────────────────────┐   ┌──────────────────┐
  │ registration engine│   │ OAuth exchange       │   │ gateway:         │
  │  · solver-backed   │──▶│  · PKCE (primary)    │──▶│   Build pool     │
  │  · browser-backed  │   │  · Device (fallback) │   └──────────────────┘
  └────────────────────┘   └──────────────────────┘
            │                                                  ▲
            │  SSO — usable as-is, no OAuth needed             │
            └──────────────────────────────────────────────────┘
                    direct push → Web pool  (+ egress binding)

  ┌──────────────────────────────────────────────────────────┐
  │ replenisher: counts both pools → decides whether to act   │
  │ token daemon: refreshes before expiry                     │
  │ re-mint: rebuilds credentials whose refresh token died    │
  └──────────────────────────────────────────────────────────┘

Fail-soft ordering — the cheap path runs first. 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. The cost is that a silently failing OAuth step leaves the Build pool lagging while the Web pool looks healthy — the two counts must be read separately to notice.

Two registration engines — a cost/reliability dial. 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.

Two OAuth flows — one is fragile, the other is heavier. 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. Maintaining two flows is more code, but the alternative — depending on the one the filter blocks — was a hard outage. 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. An imported-but-unbound account exists in the database yet is invisible to the replenisher, so it will never be used and never be counted — the pool looks smaller than it is. 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. It then registers one more than the shortfall — attrition between checks is expected — and caps the batch size regardless of how large the shortfall is. The cap is deliberate: registering in bulk is exactly the pattern upstream anti-abuse systems look for.

Two-tier token recovery. 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.

Imports are sequential. 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.

An earlier version rotated the outbound proxy between registrations. It was removed because rotation depended on a separate proxy controller and its subscription groups — infrastructure with no relationship to account registration — making the pipeline sensitive to failures in a system it did not own. Registration and minting now share one static outbound proxy.

The tradeoff is real and accepted: less IP diversity during registration means more exposure to anti-abuse heuristics. It was judged worth removing a whole class of unrelated failure modes.

• No request routing. It does not proxy inference traffic; the gateway does.
• No load balancing. Choosing which account serves a request is the gateway's job.
• No model-name logic. Model availability is discovered by the gateway at runtime, so a new upstream model needs no change here.

• Python 3.12+
• uv (recommended) or pip
• YesCaptcha API key (for Turnstile solving)
• Email provider account (LuckMail / MailNest)
• A running grok2api instance (for auto-replenish integration)

# Clone
git clone https://github.com/xinxinshuhao-create/grok-register.git
cd grok-register

# Install dependencies
uv sync

# Configure
cp .env.example .env
# Edit .env with your API keys

# Create output directory
mkdir -p keys

# Run registration
uv run python grok.py

Copy .env.example to .env and fill in:

⚠️ xAI actively blocks shared disposable-mail domains (mail.tm, gptmail domains). For Grok registration prefer luckmail (Outlook addresses) or gmail/outlook (your own accounts). Maintainer's production setup uses luckmail. The free providers above are provided as options for other users; their availability may change without notice.

The outlook provider reads codes via Microsoft OAuth (XOAUTH2 IMAP). Authorize each account once:

# uses the same authorization flow as unified-mail's graph_auth.py
uv run python outlook_auth.py your@outlook.com

The resulting refresh token is stored in OUTLOOK_TOKENS_FILE (default ./outlook_tokens.json), format: {"your@outlook.com": {"refresh_token": "..."}}. Only accounts with a valid refresh token are used for registration.

# Basic
uv run python grok.py

# With luckmail provider and 8 threads
uv run python grok.py --email-provider luckmail --threads 8

Output:

• keys/grok.txt — SSO token list
• keys/accounts.txt — email:password:sso format

uv run python sso_to_cpa.py --all

Converts SSO tokens to OAuth access/refresh tokens via Device Flow.

uv run python auto_replenish.py --daemon 600 --min 2

Monitors account pool every 600s, registers new accounts when pool drops below 2.

uv run python token_daemon.py

When xAI invalidates refresh tokens (happens on model releases or account policy changes), re-mint them:

uv run python remint_oauth.py

Re-runs Device Flow with existing SSO tokens to obtain fresh access/refresh tokens.

uv run python turnstile_solver_local.py

Local HTTP service for CAPTCHA solving (Patchright + system Chrome).

# Install CloakBrowser (once)
pip install cloakbrowser
cloakbrowser install

# Start the HTTP service
uv run python cloakbrowser_solver.py

Uses CloakBrowser's stealth Chromium to pass Cloudflare Turnstile without a paid API. Set GROK_PROXY env var to route through a proxy (optional).

uv run python cloakbrowser_solver.py --once --url https://example.com --key YOUR_SITE_KEY

Registered accounts and minted tokens can be used with grok2api to access the following models.

These are the models you get immediately after registration — no SuperGrok subscription needed:

✅ Models above verified working end-to-end as of 2026-09-22 (Build pool: grok-4.7 / grok-4.6 / grok-4.5).

Note: After the Grok 4.6 release, xAI temporarily removed grok-4.5 from the Build pool (8/14), but it was reinstated via the CPA auths import API (2026-09-05). grok-4.7 was added on 2026-09-21 and needs no client-side upgrade — grok2api discovers the model catalog from upstream at runtime. Use remint_oauth.py or the grok2api admin import API to re-mint tokens if xAI revokes them.

Image generation (re-verified 2026-09-22): grok-imagine-image-lite, grok-imagine-image and grok-imagine-image-2.0 all return real JPEGs (HTTP 200, ffd8ff magic). grok-imagine-image-quality-lite no longer exists — the model id returns HTTP 404 model_not_found. Image editing / HD / video require a Super subscription. Output is portrait ~2:3 (832×1248) with basic prompt following.

The following models are available in the codebase but require a paid account tier:

Other Build/Console models available via Device Flow: grok-4.3, grok-4.20-0309-reasoning, grok-4.20-0309-non-reasoning, grok-4.20-multi-agent-0309, grok-build-0.1 (code/composer, 256K output).

Two flows are implemented; pick based on whether Cloudflare blocks the consent page:

remint_oauth.py re-mints revoked tokens through the Device Flow path (device_mint.sso_to_device).

Both flows request the corrected scope:

openid profile email offline_access grok-cli:access api:access

This was validated against the upstream OAuth endpoint and successfully mints access/refresh tokens.

This project builds upon and references work from:

• AaronL725/grok-register
• kaibush/grok-register

MIT

本工具仅用于教育和技术研究目的。使用者须自行承担全部责任。

• 本项目提供的账号注册与临时邮箱方案可能违反相关平台的《服务条款》（包括但不限于 xAI/Grok、Google、Microsoft 等），平台有权随时封禁账号、撤销凭据或追究责任。
• 在部分国家和地区，批量注册账号、使用临时邮箱、绕过验证机制等行为可能违反当地法律法规。使用者有责任确认并遵守所在地法律，本项目作者不承担任何因使用本工具导致的直接或间接后果（包括但不限于账号损失、法律纠纷、经济损失）。
• 项目内各邮箱服务（LuckMail、FreeCustom.Email、Tmail、GPTMail 等）为第三方服务，其可用性、价格与合规性以其官方为准；本仓库不对第三方服务的任何行为负责。
• 示例中出现的账号、令牌均为占位或已撤销；请勿将任何真实凭据提交到本仓库或任何公开位置。
• 使用本仓库代码即表示你已阅读并同意上述条款。

This project is for educational and research purposes only. Users assume all responsibility.

• Account registration and temporary-email tooling may violate the Terms of Service of the target platforms (xAI/Grok, Google, Microsoft, etc.). Platforms may ban accounts, revoke credentials, or pursue other actions at any time.
• In some jurisdictions, bulk account registration, disposable-email usage, or bypassing verification mechanisms may be illegal. You are solely responsible for ensuring compliance with your local laws and regulations. The authors accept no liability for any direct or indirect consequences (including account loss, legal disputes, or financial damages).
• All third-party email services (LuckMail, FreeCustom.Email, Tmail, GPTMail, etc.) are provided by their respective operators. Availability, pricing, and compliance are subject to their official terms; this repository is not responsible for their actions.
• Sample accounts and tokens shown in this repository are placeholders or revoked. Never commit real credentials here or anywhere public.
• By using this code, you confirm that you have read and agree to the above.