OAuth login for xAI subscriptions (X Premium, SuperGrok, etc.) so you can use Grok models without an API key. It's the standard device-code flow: generates a verification URL, you approve in browser, it polls for the token. Your subscription tier determines which models you get access to, from baseline grok-4.3 up to grok-build-0.1 and multi-agent variants on SuperGrok Heavy. The source is unusually thorough about failure modes, specifically calling out that some accounts get blocked by xAI's backend gate even with active subscriptions, in which case you fall back to the BYOK API key path instead. Worth knowing that connected models bypass the platform proxy and hit api.x.ai directly.
npx -y skills add starchild-ai-agent/official-skills --skill xai-grok-onboarding --agent claude-codeInstalls into .claude/skills of the current project.
Use any active xAI account — X Premium, X Premium+, SuperGrok, or SuperGrok Heavy — for grok-4.3, grok-build-0.1, grok-4.20-* and multi-agent models. No separate API key needed.
This is standard OAuth 2.0 (RFC 8628 Device Authorization Grant), not a vendor-custom flow.
The JWT issued by auth.x.ai carries a tier claim; higher tiers unlock more models from /v1/models. Observed mapping (xAI does not publish this officially):
| Tier | Subscription | Approx. model access |
|---|---|---|
| 1 | X Premium ($8/mo) | grok-4.3 baseline |
| 2 | X Premium+ ($16/mo) | + grok-4.20-0309 variants |
| 3 | SuperGrok ($30/mo) | + reasoning models |
| 4 | SuperGrok Heavy ($300/mo) | + grok-build-0.1 + multi-agent |
status() reports the user's tier so they know which models will be available.
This is a script-mode skill — no tools registered. Read this file, then call the exports from a bash block.
byok-custom-model skill — for vendor-key BYOK setup (xAI API key from console.x.ai, different mechanism — bills per-token, NOT subscription-backed)chatgpt-codex-onboarding skill — same pattern, for ChatGPT/Codex subscriptionconfig/context/references/model-onboarding.md — overall model-selection landscapeThis skill depends on the core.xai_grok Python package inside the platform image (shipped 2026-05-22). On older images the skill loads cleanly but every public function returns:
{
"ok": false,
"error": "xai_oauth_backend_unavailable",
"detail": "ModuleNotFoundError: core.xai_grok not found in any of: [/app, /data/workspace/starchild-clawd]",
"hint": "Update the platform image OR fall back to byok-custom-model with an xAI API key."
}
If you see this response, do NOT retry — the platform itself needs an update. Either wait for the image refresh or guide the user to byok-custom-model with an API key from console.x.ai.
✅ Use when the user EXPLICITLY says one of:
❌ Do NOT use for:
byok-custom-model (the xAI template)byok-custom-modelThe two paths are mutually exclusive billing-wise. Subscription OAuth uses the user's monthly quota; BYOK API key uses console.x.ai pay-per-token credits.
xAI has a known backend gate that denies OAuth grants for some accounts even with an active SuperGrok subscription. This is upstream xAI behavior, not a client bug. Symptoms:
access_denied from the token endpointIf poll() returns AccountAccessDenied:
byok-custom-model skill, xAI template, key from https://console.x.ai)Do NOT silently retry — the gate is deterministic per account, retrying wastes time.
The flow has 4 user-visible steps. Drive it like this:
python3 - <<'EOF'
import json, sys
sys.path.insert(0, '/data/workspace/skills/xai-grok-onboarding')
from exports import start
print(json.dumps(start(), indent=2))
EOF
Returns verification_url_with_code — tell the user to open it in their browser, log in (if needed), and click Approve.
⚠️ Wait for explicit user confirmation before calling poll(). Polling too eagerly burns tokens for a "still pending" state.
python3 - <<'EOF'
import json, sys
sys.path.insert(0, '/data/workspace/skills/xai-grok-onboarding')
from exports import poll
print(json.dumps(poll(), indent=2))
EOF
Three terminal outcomes:
status="connected" → success; show the user default_model_id to switch tostatus="pending" → user hasn't approved yet; ask them to confirm before re-pollingok=false with access_denied → see "account gate" section aboveok=false with expired → device code timed out (15 min); call start() againWhen poll() returns status='connected', the first thing you must do is tell the user:
"Connection successful. Please refresh your browser page — once it reloads, the new
xai-grok/*models will appear in the model picker."
The web frontend caches the model list client-side and does not auto-refresh after an OAuth connect completes. Without a manual page refresh the user will not see their newly available models and will think the connection failed. Always include this instruction in your reply — do not assume the picker updates on its own.
After the refresh, the default model is xai-grok/grok-4.3. Other available models depend on the subscription tier (SuperGrok Heavy unlocks grok-build-0.1).
To switch: /model xai-grok/grok-4.3 or use the picker.
| Function | Args | Returns |
|---|---|---|
status() | — | Current credential state + available models + expiry |
start() | — | Device code prompt: {verification_url_with_code, user_code, expires_in_seconds} |
poll(pending_id=None) | optional pending_id | {status: connected/pending} + credential info |
logout() | — | Delete credential + flush agent cache |
refresh() | — | Force-refresh access token (debug; normally automatic) |
models(force=False) | — | List available models from the OAuth endpoint |
force=True on models bypasses the cache TTL.
All functions return a dict with ok: True on success or ok: False, error: "..." on failure.
Models surface with the xai-grok/ prefix:
xai-grok/grok-4.3 — primary chat model (default)xai-grok/grok-build-0.1 — Grok Build coding model (SuperGrok Heavy tier only)xai-grok/grok-4.20-0309-reasoning — reasoning variantxai-grok/grok-4.20-0309-non-reasoning — faster, no reasoningxai-grok/grok-4.20-multi-agent-0309 — multi-agent variant (uses /v1/responses internally)User switches via /model xai-grok/grok-4.3 or the model picker UI.
The provider auto-routes based on model id:
https://api.x.ai/v1/responses (Responses API)https://api.x.ai/v1/chat/completions (OpenAI-compatible)Users do not need to know which dialect each model speaks — passing the standard messages=[...] shape works for both. For multi-agent, an optional thinking={"effort": "low"|"medium"|"high"} controls how many agents collaborate.
Subsequent chat calls hit https://api.x.ai/v1 directly using the OAuth bearer — bypasses the platform proxy. Subscription usage limits apply (not the platform credit balance). Image / video models (grok-imagine-*) are filtered out of the chat picker but accessible via image generation tools.
Critical context (verified from independent implementations, 2026-05): xAI's backend maintains an internal allowlist on the OAuth API surface and frequently returns HTTP 403 to OAuth tokens even when the user's subscription is active and the device-code flow itself succeeded. This is documented by Hermes Agent (their xAI OAuth troubleshooting) and confirmed by independent OpenCode plugin authors. It is not a bug in our adapter — switching to PKCE flow does not bypass it (both grant types hit the same allowlist).
| Subscription | Price | OAuth typical outcome |
|---|---|---|
| X Premium (X.com only) | $8 /mo | ❌ Often rejected — not enough entitlement |
| X Premium+ (linked X account) | $16 /mo | ✅ Usually works — xAI auto-links via X account |
| SuperGrok (grok.com direct) | $30 /mo | ⚠️ Mixed — some users blocked, some pass |
| SuperGrok Heavy | $300 /mo | ✅ Reliably works |
If the user has a standalone X Premium subscription (not Premium+) or a SuperGrok base subscription and is hitting frontend rejection, tell them to do this first, in order:
A large share of reported "OAuth login fails / device code never accepted" cases trace back to missing X account link — xAI's backend can't verify the Premium status without the link, and the front door silently rejects the device code.
The standard fix in the community (Hermes, OpenCode plugin, etc.) is stop fighting OAuth, switch to API key:
XAI_API_KEY path uses a different xAI backend (console.x.ai pay-per-token) that is not subject to the OAuth allowlist.byok-custom-model skill with the xAI template. Setup is two minutes.access_denied — it will keep failing; recommend preflight or BYOK insteadxAI does not publish exact daily caps or RPM the way OpenAI does. Practical reality for OAuth-backed Grok usage:
429 or "rate limit exceeded" messages from xAI, they've hit the fair-use ceiling for that feature. Wait it out (limits reset on a rolling window, not a fixed daily clock) or switch billing modes.If the user wants predictable, spend-based high-volume access — or if they're hitting limits often — they can switch to a regular xAI API key:
byok-custom-model skill with the xAI templateBoth paths can coexist; the user picks per request. OAuth = subscription quota (good default). BYOK = clearer rate limits + per-token billing (good for heavy automation or when you want cost transparency).
| Symptom | Cause | Action |
|---|---|---|
429 / "rate limit exceeded" on chat | OAuth fair-use ceiling hit | Wait for soft reset, or switch this request to BYOK |
403 / access_denied at OAuth time | xAI account gated | Use BYOK (see preflight section above) |
Repeated 401 after refresh() | Token revoked / subscription canceled | logout() + restart, or switch to BYOK |
503 / 5xx upstream | xAI infra issue | Retry shortly. BYOK uses the same upstream, won't help |
Tokens auto-refresh via refresh_token (6h access token TTL — relatively generous vs Codex's 1h). If a 401 surfaces:
refresh() — try the manual refresh pathlogout() + restart from start()accounts.x.ai/oauth2/device?user_code=XXXX already embeds the code — just open it.start and poll. Auto-polling wastes API calls and produces stale "pending" responses.access_denied, do NOT retry blindly. Explain the gate, suggest BYOK fallback.sickn33/antigravity-awesome-skills
moizibnyousaf/ai-agent-skills
github/awesome-copilot