API discovery: xAI’s Responses API is the provider’s recommended replacement for legacy Chat Completions. The move changes more than the endpoint: requests use input, the API can continue server-side state with previous_response_id, and it has a defined surface for tools and encrypted reasoning. Pi’s new xAI route sends all of its built-in catalog models through Responses, uses store: false, and explicitly asks for reasoning.encrypted_content.
Try it
Build a non-production release-note triage: give a reasoning model a short batch of public release notes, ask it to return a migration matrix, then make a follow-up turn that turns the highest-risk row into a test checklist. The important design choice is not the topic—it is deciding whether the follow-up uses provider-side state or only the encrypted continuity material your client has deliberately retained. xAI’s reference documents both the Grok 4.6 Responses request shape and the encrypted-reasoning include.
Copy-paste agent instruction
Build a disposable xAI Responses API smoke test for a two-turn release-note triage. Use an environment variable for the API key; send `input`, `store: false`, and `include: ["reasoning.encrypted_content"]` on the first request. Keep returned encrypted state only in a local, approved test fixture, then make one follow-up request that converts the first response into a migration-test checklist. Do not log the key or the encrypted state. Before running it, show me the endpoint, model, expected request shape, and an estimate of any account-dependent cost or access risk.Test caveat
This is source-backed guidance, not a live xAI test. You need an API key and model entitlement; availability, price, rate limits, and latency are account- and model-dependent. Pi’s public change contains request-shape tests, while its live provider test is skipped without an xAI key. Treat encrypted reasoning as opaque provider data and retain it only inside an approved boundary.