POST /v1/responses is the main Codex interface for this connection. It supports text requests and history, instructions, client functions, non-streaming and streaming replies. Keys have no product modes; a server prompt is configured separately.
| Input | Support |
|---|---|
input | A string or message-item array with input_text; also function_call and function_call_output for continuing a client-tool loop |
| Generation | max_output_tokens, stream; application of temperature and top_p depends on the model and thinking |
| Client tools | type: "function" tools, tool_choice, and a compatible parallel tool loop; the client executes each function |
| Response | output_text and function_call; streaming ends with response.completed, while output-limit truncation returns status: "incomplete" |
bash
curl https://api.guardrelay.ai/v1/responses \
-H "Authorization: Bearer $GUARD_API_KEY" \
-H "content-type: application/json" \
-d '{
"model": "claude-sonnet-5",
"instructions": "Answer briefly",
"input": "Connection check: reply OK",
"max_output_tokens": 64
}'- PDF /
input_file,input_image, native citations, and server-side Web/MCP tools are outside the Responses contract. Use Messages for PDFs and images. top_k, explicitcache_control, native thinking/reasoning blocks, and structuredtext.formatare outside the supported contract.claude-fable-5andclaude-fable-5-1are available here without an applied server prompt, including streaming and client functions. This endpoint retains its data-type limitations.- Explicitly forbidden types or semantics receive a local
400before billing. Compatibility-only fields such asprevious_response_id,include,truncation, orprompt_cache_keymay be accepted without effect, so do not rely on them.
All three families work here: Kimi, Composer and Grok. The surface is the same one; what is shorter is their list of accepted fields.
Kimi is served here: the key and the address are the ordinary ones, model takes an exact Kimi id, and the text or the history goes into input. The ready Codex configuration for this surface is on the Codex page. If your client is happier with OpenAI Chat Completions, the same key works there too.
bash
curl -X POST https://api.guardrelay.ai/v1/responses \
-H "Authorization: Bearer gd-your-key" \
-H "Content-Type: application/json" \
-d '{
"model": "k3",
"input": "Hello!",
"max_output_tokens": 128
}'bash
curl https://api.guardrelay.ai/v1/responses \
-H "Authorization: Bearer gd-your-key" \
-H "Content-Type: application/json" \
-d '{
"model": "cursor-grok-4.6-low",
"instructions": "Answer briefly",
"input": "Connection check: reply OK",
"max_output_tokens": 64
}'bash
curl https://api.guardrelay.ai/v1/responses \
-H "Authorization: Bearer gd-your-key" \
-H "Content-Type: application/json" \
-d '{
"model": "composer-2.5",
"instructions": "Answer briefly",
"input": "Connection check: reply OK",
"max_output_tokens": 64
}'| What | How it works for Composer and Grok |
|---|---|
| Request fields | model, input, instructions, max_output_tokens, stream, tools |
input | a string or an array of type: "message" items with roles user, assistant, system, developer |
| Content blocks | input_text and output_text with type and text; cache_control is accepted and ignored. Grok also accepts input_image with inline base64. |
function_call, function_call_output | part of the client tool loop, served |
web_search_call, file_search_call, computer_call and other provider-hosted items | rejected with 400 cursor_client_tools_unavailable |
reasoning, temperature, top_p, store, include, truncation, metadata, previous_response_id, prompt_cache_key, thinking | accepted and silently dropped |
parallel_tool_calls: true, service_tier auto/default, tool_choice: "auto" | accepted at the default value only |
text, any other value of the fields above | not accepted, 400 cursor_parameter_unavailable |
| Response | status: "completed", text in output_text and in output[0].content[0].text, cache in usage.input_tokens_details.cached_tokens |
| Response with a tool call | a type: "function_call" item is added to output with call_id, name and arguments; you answer it with a function_call_output item in the next request |