Skip to main content
Grok Build with the Consus Gateway supports two compliance configurations — ITAR and FedRAMP High (see Step 2). They are identical except for the model IDs and their :level suffix. Pick the one your data classification and authorization require, and do not mix levels within a single profile.The gateway enforces the compliance boundary for the models it serves, but it does not control client-side behavior — local tool execution, file access, outbound destinations, etc. Client-side behavior is the customer’s responsibility.
Grok Build is xAI’s coding-agent CLI. Despite the name, it is not limited to Grok models: it speaks the OpenAI Chat Completions API to any endpoint you configure, so through Consus Gateway it drives Claude, GPT, and Grok models alike, with the same tools, streaming, and reasoning support for each, and lets you switch between them mid-session.

​
Before you start

You need:
  • Grok Build installed. The grok CLI, v1.0.30 or newer. See the Grok Build docs if you don’t have it yet.
  • A Consus API key. Get one from your Consus admin.
You do not need a Grok account or grok login. The gateway is the only endpoint the CLI talks to.

​
Step 1 (recommended): Set up an isolated Consus profile

If you use Grok Build for anything else (personal xAI account or another organization) we recommend setting up an isolated Consus Gateway profile. This keeps your Consus credentials, model catalog, and settings fully isolated. Add this alias to your shell profile (~/.zshrc or ~/.bashrc):
Then source ~/.zshrc (or source ~/.bashrc) to pick up the alias, and create the directory:
The rest of this guide uses grok-gateway and ~/.grok-gateway/ throughout. If you skip this step, substitute grok and ~/.grok/.

​
Step 2: Configure your gateway settings

Create ~/.grok-gateway/config.toml with one of the configurations below — the one that matches your data classification. The two are identical except for the model IDs.

​
Option A — ITAR

Use this when handling ITAR / export-controlled data. Every call is served by a model with ITAR authorization: Grok 4.6 (the default, on AWS GovCloud Bedrock; it is authorized for ITAR only, so it uses the standalone :itar ID), Claude Opus 5 and Claude Sonnet 5 on Bedrock, and GPT-5.6 Sol on Azure Government and GPT-5.4 on Bedrock, all carrying :il5+itar. Switch between them at any time with /model.

​
Option B — FedRAMP High

Use this for FedRAMP High (non-ITAR) workloads. Same structure as Option A — only the model IDs change to carry the :fedramp-high level, which gives you Claude Opus 5 (the default, served from Vertex AI), Claude Sonnet 5, GPT-5.6 Sol, GPT-5.4, and Gemini 3.8 Flash. Grok 4.6 is authorized for ITAR only and has no FedRAMP High ID, so it does not appear here.
env_http_headers reads your key from the CONSUS_API_KEY environment variable, so export it in your shell before launching Grok Build:
Add that line to your ~/.zshrc or ~/.bashrc to make it persist across sessions.
Model IDs must include a compliance level (e.g. claude-sonnet-5:il5+itar). A bare model name without a :level suffix is rejected with a 400. Pick the model and level your authorization requires — run curl -H "x-api-key: $CONSUS_API_KEY" https://api.consus.io/v1/models to see what’s available, and add any of them as another [model.<name>] entry in the same shape.
Keep your CONSUS_API_KEY out of source control — set it via the environment as shown above rather than hardcoding the key into ~/.grok-gateway/config.toml. env_http_headers reads the variable at startup and never writes the value to disk.
Quote section names that contain a dot. [model."gpt-5.4-itar"] must be written with the quotes. TOML treats an unquoted dot as a nested-table separator, so [model.gpt-5.4-itar] parses as a table named gpt-5 with a child 4-itar, and Grok Build silently drops the model. Names without a dot (claude-sonnet-5-itar) can go unquoted.The TUI rewrites this file. Changing settings inside a session (for example /model) makes Grok Build rewrite config.toml. Your keys are preserved but comments are dropped and tables may be reformatted; re-check fork_secondary_model afterwards.

​
Step 3: Start your session

That’s it. Every request now routes through Consus Gateway at the compliance level you configured.

​
Step 4: Verify

List the catalog. It must contain only the Consus models from your config:
If any model appears without your suffix (-itar or -fedramp), the [models] block did not load — check the file for the quoting issue in Step 2. Then ask Grok Build to do something real:
The file should appear on disk and the run output should be the actual numbers, not a hallucinated transcript. Inside the session, /model claude-sonnet-5-itar (or Ctrl+M) switches models; the next turn, tool calls included, is served by the new model.

​
What gets served

Every request from Grok Build — coding turns, tool use, image description, session titles, forks — is served by the model you configure in Step 2, at the compliance level in its ID. With Option A that’s Grok 4.6, Claude Opus 5, Claude Sonnet 5, GPT-5.6 Sol, and GPT-5.4, all with ITAR authorization; with Option B it’s Claude Opus 5, Claude Sonnet 5, GPT-5.6 Sol, GPT-5.4, and Gemini 3.8 Flash at FedRAMP High. The gateway routes each request to whichever government-authorized provider hosts that model at the requested compliance level (AWS GovCloud Bedrock, GCP Assured Workloads Vertex AI, Azure Government OpenAI); the compliance boundary is enforced at the gateway architecture level. The response header x-consus-served-model confirms the model that served each successful request (e.g. grok-4.6). Grok Build’s own defaults send nothing from your conversation to xAI, and the [cli] and [features] blocks above turn off the CLI’s remaining outbound calls (its startup catalog fetch, remote configuration patches, /feedback, and auto-update), so the gateway is the only endpoint it contacts.

​
What each setting does

[model."<name>"] : A custom model entry. <name> is what you type after /model or -m; model is the composite ID sent to the gateway and must include a :level suffix. base_url : Routes Grok Build’s requests to the gateway (https://api.consus.io/v1). Grok Build appends /chat/completions. env_http_headers : Reads CONSUS_API_KEY from your shell environment and sends it as the x-api-key header on every request. The gateway authenticates with x-api-key, not Authorization: Bearer, so this setting is what carries your credential. env_key : Also points at CONSUS_API_KEY. Grok Build refuses to build a client with no credential at all; this satisfies that check. The bearer token it produces is ignored by the gateway. context_window : Must be set on every entry. Without it Grok Build assumes 200K tokens for every custom model, which compacts history far too early on the 1M-context models and too late on Grok 4.6. The values above match what the gateway enforces. allowed_models : Glob allowlist for the picker, the default, and -m. Anything not matching — including the CLI’s built-in xAI-hosted models — is removed from the catalog, so only gateway models are ever selectable. image_description, session_summary, and fork_secondary_model : The models Grok Build uses for background work (describing pasted images, naming sessions, the second agent on a fork). Each defaults to a built-in xAI-hosted model, so the configs pin them to gateway IDs. Image description needs a vision-capable model, which is why it points at Claude. disable_web_search : Removes the CLI’s web_search tool, which would otherwise run on an xAI-hosted model outside the boundary. [cli] and [features] : Turn off auto-update, the startup catalog fetch (remote_fetch), remote configuration patches (campaigns, managed_config), and /feedback. Product telemetry is already off by default; the line pins it.