> ## Documentation Index
> Fetch the complete documentation index at: https://docs.routerbase.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Responses

> OpenAI Responses API endpoint (stateless). The wire modern coding agents like the Codex CLI speak.

## Endpoint

```
POST https://routerbase.com/v1/responses
```

Compatible with the OpenAI [Responses API](https://platform.openai.com/docs/api-reference/responses) in **stateless** mode. Every chat model in the catalog is available through it, with the same billing, quotas, and logging as [Chat Completions](/api-reference/chat-completions).

The main reason this endpoint exists: recent versions of the **Codex CLI** only speak the Responses wire (`wire_api = "chat"` was removed), so this is what lets Codex — and any other Responses-only client — use RouterBase as its provider.

## Using RouterBase with Codex

Add a provider to `~/.codex/config.toml`:

```toml theme={null}
[model_providers.routerbase]
name = "RouterBase"
base_url = "https://routerbase.com/v1"
env_key = "ROUTERBASE_API_KEY"
wire_api = "responses"

# make it the default
model_provider = "routerbase"
model = "deepseek/deepseek-v4"
```

Then export your key and run Codex as usual:

```bash theme={null}
export ROUTERBASE_API_KEY=sk-rb-xxxxxxxxxxxx
codex "explain this repository"
```

Codex's default stateless behavior for custom providers (resend the full history, `store: false`) is exactly what this endpoint expects — no extra configuration needed.

## Request Headers

| Header          | Value                       |
| --------------- | --------------------------- |
| `Authorization` | `Bearer sk-rb-xxxxxxxxxxxx` |
| `Content-Type`  | `application/json`          |

## Request Body

<ParamField body="model" type="string" required>
  Model ID (chat models only). See the [Model Overview](/overview) or the live [Models API](/api-reference/models).
</ParamField>

<ParamField body="input" type="string | array" required>
  A plain string (treated as a single user message) or an array of input items. Supported item types: `message` (roles `user`, `assistant`, `system`, `developer` — `developer` maps to `system`), `function_call`, `function_call_output`, and `reasoning` (accepted and skipped). Message content may be a string or typed parts (`input_text`, `output_text`, `input_image`).
</ParamField>

<ParamField body="instructions" type="string">
  System-level instructions, prepended as a system message.
</ParamField>

<ParamField body="max_output_tokens" type="integer">
  Maximum tokens to generate.
</ParamField>

<ParamField body="temperature" type="number">
  Sampling temperature, 0–2.
</ParamField>

<ParamField body="top_p" type="number">
  Nucleus sampling probability, 0–1.
</ParamField>

<ParamField body="stream" type="boolean">
  If `true`, the response is a Server-Sent Events stream of `response.*` events: `response.created` → `response.output_item.added` → `response.output_text.delta` … → `response.output_item.done` → `response.completed`. Function-call items arrive complete in `response.output_item.done`.
</ParamField>

<ParamField body="tools" type="array">
  Function tools in the flat Responses shape: `{"type": "function", "name": "...", "description": "...", "parameters": {...}}`. Server-side tool types (`web_search`, …) are accepted and silently dropped — RouterBase does not host them; the model simply does not get that tool.
</ParamField>

<ParamField body="tool_choice" type="string | object">
  `"auto"`, `"none"`, `"required"`, or `{"type": "function", "name": "..."}`.
</ParamField>

## Stateless by design

`previous_response_id` and server-side conversation storage are **not supported** — requests carrying `previous_response_id` return a 400 with guidance. Send the full item history each turn (with `store: false` if your client sends it; the field is accepted and ignored). This is the default mode for Codex with custom providers and for most Responses SDK usage.

## Examples

<CodeGroup>
  ```bash cURL theme={null}
  curl -X POST https://routerbase.com/v1/responses \
    -H "Authorization: Bearer sk-rb-xxxxxxxxxxxx" \
    -H "Content-Type: application/json" \
    -d '{
      "model": "deepseek/deepseek-v4",
      "input": "What is 2+2?"
    }'
  ```

  ```python Python theme={null}
  from openai import OpenAI

  client = OpenAI(
      api_key="sk-rb-xxxxxxxxxxxx",
      base_url="https://routerbase.com/v1",
  )

  resp = client.responses.create(
      model="deepseek/deepseek-v4",
      input="What is 2+2?",
  )
  print(resp.output_text)
  ```

  ```javascript JavaScript theme={null}
  import OpenAI from "openai";

  const client = new OpenAI({
    apiKey: "sk-rb-xxxxxxxxxxxx",
    baseURL: "https://routerbase.com/v1",
  });

  const resp = await client.responses.create({
    model: "deepseek/deepseek-v4",
    input: "What is 2+2?",
  });
  console.log(resp.output_text);
  ```
</CodeGroup>

## Response

```json theme={null}
{
  "id": "resp_...",
  "object": "response",
  "created_at": 1755600000,
  "status": "completed",
  "model": "deepseek/deepseek-v4",
  "output": [
    {
      "type": "message",
      "id": "msg_...",
      "status": "completed",
      "role": "assistant",
      "content": [{ "type": "output_text", "text": "4", "annotations": [] }]
    }
  ],
  "parallel_tool_calls": true,
  "usage": {
    "input_tokens": 12,
    "input_tokens_details": { "cached_tokens": 0 },
    "output_tokens": 1,
    "output_tokens_details": { "reasoning_tokens": 0 },
    "total_tokens": 13
  }
}
```

When the model calls a tool, the `output` array carries `function_call` items (`call_id`, `name`, `arguments`); return each result as a `function_call_output` item in the next request's `input`.

## Billing

Identical to [Chat Completions](/api-reference/chat-completions): the request runs through the same pipeline, is metered by the same token pricing, and appears in your generation logs the same way.
