OAuth Bridge

progrok is built around one idea: your xAI OAuth session is already the account authority for Grok. progrok activates that session as a local tool surface so SDKs, CLI workflows, and agent tools can call Grok without each integration having to implement OAuth, token refresh, model routing, and media polling on its own.

Positioning

progrok is not a separate model host, an API-key reseller, or a bypass. It is a local OAuth bridge. It signs in with your xAI account, stores the refreshable token locally, and uses that token to enable Grok access through familiar developer surfaces.

Why OAuth first

The practical problem is not just calling one endpoint. A real developer setup needs chat, Responses, reasoning, web search, X search, coding models, image jobs, video jobs, model discovery, status checks, and scriptable metadata. API keys are convenient for servers, but many Grok workflows are tied to the same xAI account session used by Grok web and related developer tools. progrok keeps that account session local and turns it into a stable operating surface.

Account authority

Your xAI account and subscription decide what you can access.

Local credential

The refreshable OAuth session is stored at ~/.progrok/auth.json.

Tool activation

progrok exposes proxy, search, media, model, and capability commands.

Client compatibility

OpenAI-compatible clients keep using base_url and a placeholder key.

Shared token lineage

progrok uses the shared xAI OAuth client identifier documented by Hermes Agent and OpenClaw. The same OAuth lineage matters because Hermes, OpenClaw, and Grok Build-style coding workflows are all trying to solve the same operational problem: unlock Grok through an authenticated xAI account session, then make it usable from tools that expect a normal programmable endpoint.

That is why progrok is intentionally small and local. It does not ask every client to understand xAI browser login. It performs the login once, refreshes the bearer token when needed, and injects that credential at the boundary where OpenAI-compatible clients send requests.

Request path

OpenAI SDK / agent tool / curl
  -> http://127.0.0.1:18645/v1/*
  -> progrok loads or refreshes ~/.progrok/auth.json
  -> progrok replaces the placeholder Authorization header
  -> https://api.x.ai/v1/*
  -> response returns to the original client

Direct command path

Some tasks are awkward through a generic proxy because they need polling, output files, source selection, or model-specific request shapes. progrok also ships direct commands that use the same OAuth credential without requiring the proxy process to be running.

Command	What it activates	Why it exists
`progrok search`	Responses with web and X tools	One command for current research, citations, JSON, and reasoning effort.
`progrok image`	Imagine image generation/editing	Handles reference files, output folders, and result extraction.
`progrok video`	Imagine video jobs	Submits async jobs, polls status, and downloads completed files.
`progrok models`	Live model catalog	Shows aliases, model purpose, context, and cost assumptions before automation.
`progrok capabilities`	Machine-readable metadata	Lets agents discover ports, commands, models, and supported workflows.

What it does not do

It does not bypass xAI access, quotas, subscriptions, pricing, or product limits.
It does not make remote callers safe automatically; the proxy binds to localhost by default for a reason.
It does not turn OAuth into a permanent API key. Tokens expire and are refreshed through the stored session.
It does not proxy WebSocket realtime streams directly; use HTTP client-secret minting where available.

When to use progrok

Use progrok when you want Grok available inside an existing developer workflow: an OpenAI-compatible SDK, a local agent runner, a coding CLI, a research script, or an automation pipeline that can point at a local base URL. Login once, activate the local tool surface, and then let the rest of your stack talk to Grok through standard HTTP shapes.