Short answer
Yes, you can run an xAI Grok model locally: xAI’s official GitHub repository provides open weights and example code for Grok-1. But Grok-1 is a specific 314-billion-parameter model—not the current Grok 4.7 model listed in xAI’s API documentation. The repository warns that running its example requires enough GPU memory and that its Mixture-of-Experts implementation is inefficient. [1]
There is another important distinction: the released Grok-1 weights are a raw base-model checkpoint, not a dialogue-ready assistant. xAI says the release was not fine-tuned for a specific application such as dialogue. So runnable weights do not, by themselves, establish an assistant experience equivalent to the hosted API. [2]
The practical choice is therefore not simply “local Grok or cloud Grok.” It is Grok-1 base weights on your own hardware, which may need further adaptation for your intended use, versus a hosted API model such as grok-4.7. The right fit depends on whether you need self-hosting and can support Grok-1’s hardware and adaptation needs, or prefer managed API access.
What “Grok local model” can mean
| Option | What runs the inference? | What it means |
|---|---|---|
| Grok-1 open weights | Your own machine or infrastructure | xAI’s documented local option. The repository includes example code to load and run Grok-1 weights. It has 314B parameters and an 8,192-token maximum sequence length. The release is a raw base checkpoint, not fine-tuned for a specific application such as dialogue. [1][2] |
| Grok API | xAI’s hosted service | The official model documentation lists grok-4.7. An API call sends a request to xAI’s service; it does not run Grok-4.7 on your computer. [3] |
| Another local model connected to a Grok-branded tool | The separate local model | A tool or router can hand work to a local model without that model being Grok. Check which model actually produces the response. |
Grok-1: locally runnable, but not a ready-made chat assistant
The official xAI repository provides example code to load and run Grok-1, and instructions to download the checkpoint, install its Python requirements, and run python run.py. It identifies the model as 314B parameters, with an 8,192-token maximum sequence length. The repository cautions that its example implementation is inefficient and requires enough GPU memory; it does not specify a minimum GPU or memory configuration. [1]
The checkpoint’s training stage matters for model selection. xAI describes the released weights as the raw base checkpoint from Grok-1’s pre-training phase, and says it was not fine-tuned for a specific application such as dialogue. The release therefore establishes that the weights can be run, but not that they provide a ready-to-use chat assistant equivalent to the hosted Grok API. [2]
The repository says the Grok-1 code and associated weights in that release are licensed under Apache 2.0. That statement applies to those repository files and Grok-1 weights; review the license and your intended use before deployment. [1]
Choose this route if you specifically need Grok-1 weights under your own infrastructure and have the engineering and hardware capacity to run and, if needed, adapt a base model. Do not assume these weights are a local version of the newer Grok 4.7 API model or a dialogue-tuned assistant.
The Grok API: hosted access to a listed current model
The official model page lists grok-4.7 with a 500,000-token context window. It specifies text and image input, and says supported reasoning effort settings are low, medium, high, and xhigh. The page lists API prices of $2.00 per million input tokens and $6.00 per million output tokens. Those are API token prices, not a comparison with the total cost of buying and operating local hardware. [3]
The official quickstart shows requests using the grok-4.7 model identifier and the https://api.x.ai/v1 base URL. It says users need an account, an API key, and credits to use the API. That is hosted inference, not local execution. [4]
Choose the API if your application needs a hosted model with the listed text/image input or reasoning-effort options, or you prefer managed access over running and adapting Grok-1 weights. Confirm that the documented settings fit your workload before committing.
Don’t mistake a router or project name for local Grok
Two examples help explain the terminology:
- OpenGrok is a separate project. Its page describes it as based on Phi-3-mini and says its datasets are not derived from Grok and that the project has no affiliation with X Corp. Its “Run Grok on your local computer” title is not evidence that xAI’s Grok model is running locally. These are statements made by the project page. [5]
- Grok Bot can route to a local model without that model being Grok. In one personal setup, Grok Bot routes requests to an oMLX server on a Mac; the article’s example local model is Qwen. That describes a router plus a local model, not local inference using xAI Grok weights. [6]
A useful check for any setup: which exact model identifier produced the answer, and where did that inference run? A Grok-branded interface or an OpenAI-compatible local endpoint alone does not answer either question.
Which should you choose?
- Choose local Grok-1 when running that specific base model on your own hardware is the requirement, and you can meet its substantial, unspecified GPU-memory needs and handle any adaptation needed for your application. The released checkpoint is not fine-tuned for dialogue. [1][2]
- Choose the hosted API when you need a model listed in the current API documentation—such as grok-4.7—and hosted access fits your product, budget, and data-handling requirements. Check the official model page for the input modalities and reasoning settings relevant to your workload. [3]
- Choose another local model behind a router when local execution is the goal but Grok-1’s documented scale or base-checkpoint status is not practical. Verify and label the actual local model; do not describe it as Grok.
Local inference can avoid sending a request to a hosted model for that inference, but that alone does not establish a complete privacy or security guarantee. Consider the full application path, including the router, logs, and any other services it calls. A personal account of one oMLX/Qwen setup also describes trade-offs such as memory contention, extra routing latency, maintenance, and possible differences in model quality, but reports no measured comparison. [6]