How to access Grok 4.5 API: Responses API, price, EU availability and prompt cache settings

Grok 4.5 is xAI’s model for coding, agents, and knowledge work. The model is named grok-4.5. If your project already uses OpenAI SDK, you can call it by pointing baseURL to https://api.x.ai/v1; for new projects, you can choose xAI SDK, OpenAI SDK compatibility or directly request the REST API.

This article only discusses API access. Model availability in Grok Build, Cursor, and Office plug-ins are not exactly the same as region, account, and billing status in the API Console. Do not confuse them when troubleshooting.

Confirm three things before accessing

Before you start you need:

1. Create an API key in the xAI API Console and save it in the environment variable XAI_API_KEY.
2. Confirm that the target account can use the API Console; as of the official document update, EU users cannot yet use Grok 4.5 in the API Console, which is expected to be available later in the month.
3. Make it clear whether you want to use the Responses API or Chat Completions. New access is preferred to use the Responses API; existing projects based on chat.completions can keep the existing interface first, and then add cache routing settings separately.

Don’t write API keys into front-end JavaScript, client applications, or Git repositories. Browsers, mobile and desktop clients should request their own backend first, which then calls the xAI API.

Grok 4.5 Price and Capability Range

The basic text prices listed in the official documentation are as follows:

The price list is not the final bill. Actual cost is also affected by input length, output length, inference intensity, tool calls, cache hits, rate limiting, and team pricing. First use small traffic to record input, output and cache tokens, and then decide whether to increase inference intensity or expand concurrency.

Call Responses API using OpenAI SDK

If the project has installed the official openai Python SDK, you can access it as follows. The key is to keep base_url="https://api.x.ai/v1" and write the model name as grok-4.5:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["XAI_API_KEY"],
    base_url="https://api.x.ai/v1",
)

response = client.responses.create(
    model="grok-4.5",
    input="请审查这段 Python 函数，指出边界条件问题并给出修正版。",
)

print(response.output_text)

The equivalent HTTP request is:

1
2
3
4
5
6
7

curl https://api.x.ai/v1/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $XAI_API_KEY" \
  -d '{
    "model": "grok-4.5",
    "input": "请审查这段 Python 函数，指出边界条件问题并给出修正版。"
  }'

When the request returns an error, first check the API key, base_url, model name and account region, and then check the quota or organization-level policy. Don’t rewrite the key into a code file and test it again and again just because the model is not available.

Why set prompt_cache_key

Long conversations, codebase analysis, and agent loops often repeatedly send system prompt words, tool instructions, and historical context. xAI’s cache is maintained on a per-server basis; if a request for the same session is not reliably routed to the same server, it may fall to a cache-cold server and be billed as a full input.

In Responses API, prompt_cache_key should be passed in as the request body field. For the same continuous session, use an identifier that is stable, unpredictable, and does not contain sensitive source text, such as a UUID generated by the server:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["XAI_API_KEY"],
    base_url="https://api.x.ai/v1",
)

response = client.responses.create(
    model="grok-4.5",
    input="继续根据刚才的约束补全测试用例。",
    extra_body={
        "prompt_cache_key": "7f26e7a8-1f8f-4c34-9f93-4e9e1d40d7a1"
    },
)

print(response.output_text)
print(response.usage.input_tokens_details.cached_tokens)

The purpose of this key is to allow the same session to be routed to the same server more stably, thereby increasing the chance of cache reuse; it does not force all requests into one session, nor can it save your own session state on your behalf. Users, projects, tenants, or tasks that need to be isolated should use different keys.

Chat Completions are not the same field

If you continue to use Chat Completions in existing projects, do not copy prompt_cache_key directly. This interface uses the HTTP request header x-grok-conv-id:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_XAI_API_KEY",
    base_url="https://api.x.ai/v1",
)

response = client.chat.completions.create(
    model="grok-4.5",
    messages=[
        {"role": "system", "content": "You are a careful code reviewer."},
        {"role": "user", "content": "Review this change and list regressions."},
    ],
    extra_headers={
        "x-grok-conv-id": "conv_abc123",
    },
)

print(response.choices[0].message.content)

The purpose of both interfaces is the same: to allow the same session to hit the same server cache as much as possible. Different field positions are a common source of errors: Responses API uses request body prompt_cache_key, and Chat Completions uses x-grok-conv-id request header.

How to design cache keys so that they will not become invalid

You can think of cache keys as server-side routing tags within the same reusable context. Recommended strategy:

• Consecutive requests by a user within an explicit session share the same key;
• Generate new keys when changing projects, models, system prompt word versions, or permission ranges;
• Use a database ID, a random UUID, or a hashed internal session ID without directly concatenating email, prompt text, or customer data;
• Record short summaries of keys and cache tokens in application logs instead of logging full keys or full user input;
• Observe cached_tokens and use real hits to determine whether the design is effective.

Generating a new UUID every round, or cramming all unrelated tasks for the same user into one key, will undermine the value of the caching strategy. The former makes reuse difficult, and the latter makes debugging, isolation, and cost attribution confusing.

How to deal with EU and multi-region deployment

The official documentation states that Grok 4.5 is not yet available to EU users in the API Console and is expected to be launched later this month. Therefore, products targeting users in multiple regions should include region availability as part of the startup check:

1. Before creating a call on the backend, confirm whether the account and deployment region are eligible for access.
2. Return a clear feature unavailability message for ineligible regions instead of infinite retries.
3. Do not use proxies, shared accounts, or forged region information to bypass service restrictions.
4. Prepare authorized alternative models or manual processing paths for critical processes and test for degradation behavior before going live.

Whether the EU has been opened, specific prices and limits may change. Before publishing to the production environment, the API Console, model details page, and latest pricing page should be used as standards, not just the release time of this article.

Common access issues

Return 401 or 403

Prioritize checking whether XAI_API_KEY is actually injected into the running environment, whether the request is sent to https://api.x.ai/v1, and whether the account is qualified for API Console and regional access. Do not print the Authorization header in the error log.

Cache token is always 0

Verify that consecutive requests use the same prompt_cache_key and the field is placed in the Responses API request body; if using Chat Completions, check the x-grok-conv-id header. Cache hits are also affected by context and server routing, and policy failure cannot be determined by just one short request.

Costs higher than expected

First split the input, output and cache tokens, check whether High inference intensity is used by default, whether long contexts are sent repeatedly, whether there are too many tool calls, and then adjust prompt words, session segmentation and cache keys. Don’t just guess based on the total bill it’s a model unit price issue.

Summary

The shortest path to Grok 4.5 is to save XAI_API_KEY in the backend, point the OpenAI SDK’s base_url to https://api.x.ai/v1, call the Responses API with grok-4.5, and set up a stable prompt_cache_key for the same continuous session. For existing Chat Completions projects, use x-grok-conv-id. Before going online, check EU availability, real-time prices, limits, and cached tokens to turn sample calls into a controllable production workflow.

Official information:

• https://docs.x.ai/developers/grok-4-5
• https://docs.x.ai/developers/advanced-api-usage/prompt-caching/maximizing-cache-hits
• https://x.ai/news/grok-4-5