Codex API: подключение через Responses API go2llm

Q: Что именно вы проверили живым запросом?

2026-09-14, Codex CLI 0.151.0, wireapi = "responses", модель qwen3-8-flash: codex exec прочитал файл тестового проекта, исполнил инструменты, внёс правку и показал корректный diff. Отдельно curl'ом против прода проверены не-поток, поток, вызов инструмента (functioncall с корректными аргументами), отказ на previousresponseid с 400 statefulresponsesunsupported и usage.costusd во всех формах. Списание сошлось до цента. Чего мы не проверяли: интерактивный TUI codex и модели, кроме qwen3-8-flash, — поэтому «работает со всеми моделями» на этой странице вы не увидите.

Q: Что делать при ошибке?

Проверьте ключ, model ID, base URL с /v1 на конце, баланс и HTTP-код. 400 statefulresponsesunsupported означает, что клиент просит серверное состояние — передавайте историю в input. Дальше — справочник ошибок или поддержка, без передачи полного API-ключа.

go2llm даёт единый API для приложений и coding-инструментов, которые умеют работать с OpenAI-совместимым или Anthropic-совместимым base URL. Один ключ gk_sk_… и общий USD-баланс покрывают разработку, автоматизацию и собственные приложения. Расход считается по фактическим запросам, обязательной подписки нет.

Codex CLI (@openai/codex) для кастомных провайдеров говорит только на OpenAI Responses API. У go2llm этот endpoint теперь опубликован:

POST https://go2llm.tech/v1/responses

Это адаптер протокола поверх /v1/chat/completions, а не отдельный маршрут биллинга: авторизация, резерв, лимиты, роутинг и списание — общие, usage.cost_usd приходит в ответе.

Подключение Codex CLI

Что проверено. 2026-09-14 мы прогнали через go2llm настоящий Codex CLI версии 0.151.0 с конфигом из этого раздела. codex exec получил задачу добавить docstring в функцию тестового проекта: прочитал файл, исполнил инструменты, внёс правку и показал корректный diff — 21 432 токена. Это реальная правка файла, а не «эндпоинт вернул 200». Границы проверки. Прогон был на одной модели — qwen3-8-flash; правило остаётся прежним: через /v1/responses доступны те же модели, что на /v1/chat/completions. Гоняли codex exec, интерактивный TUI codex — нет.

1. Ключ и модель

Выпустите отдельный ключ для coding-инструмента и поставьте ему квоту в кабинете. Возьмите model ID из текущего каталога — угадывать или копировать из чужой инструкции его не нужно:

curl https://go2llm.tech/v1/models

Через /v1/responses обслуживаются ровно те модели, что и через /v1/chat/completions: у модели в endpoints должен быть chat.completions. Модель без него (сегодня это картиночные модели) на /v1/responses недоступна.

2. `~/.codex/config.toml`

model = "gpt-5.3-codex"
model_provider = "go2llm"

[model_providers.go2llm]
name = "go2llm"
base_url = "https://go2llm.tech/v1"
env_key = "GO2LLM_API_KEY"
wire_api = "responses"

Разбор полей:

model и model_provider — ключи верхнего уровня. В TOML они обязаны стоять выше любой таблицы […], иначе попадут внутрь неё.
base_url — с /v1 на конце. Без /v1 Codex постучится в https://go2llm.tech/responses и получит 404.
env_key — имя переменной окружения, из которой Codex берёт ключ и шлёт его как Bearer-токен. Сам ключ в config.toml не пишем.
wire_api = "responses" — единственное поддерживаемое значение; оно же значение по умолчанию, если поле опустить.

3. Запуск

export GO2LLM_API_KEY=gk_sk_ВАШ_КЛЮЧ
codex

Если go2llm нужен не как провайдер по умолчанию, а рядом с остальными, положите те же строки в отдельный файл профиля ~/.codex/go2llm.config.toml и запускайте:

codex --profile go2llm

Проверить endpoint без Codex

Этот шаг отделяет «шлюз ответил» от «клиент договорился со шлюзом» — делайте его первым, чтобы не искать причину не там:

curl https://go2llm.tech/v1/responses \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "content-type: application/json" \
  -d '{"model":"gpt-5.3-codex","input":"Ответь одним словом: работает"}'

В ответе — объект response со статусом completed, текстом в output[].content[].text и блоком usage:

{
  "id": "resp_…",
  "object": "response",
  "status": "completed",
  "model": "gpt-5.3-codex",
  "output": [
    {"type": "message", "role": "assistant", "status": "completed",
     "content": [{"type": "output_text", "text": "работает", "annotations": []}]}
  ],
  "usage": {
    "input_tokens": 12, "output_tokens": 3, "total_tokens": 15,
    "input_tokens_details": {"cached_tokens": 0},
    "cost_usd": 0.0000189
  }
}

То же самое из OpenAI SDK — client.responses.create(...) с base_url="https://go2llm.tech/v1".

Что поддержано, а что отклоняется

Шим stateless: истории ответов шлюз не хранит. Это осознанное решение, а не недоделка — хранить response_id значит завести персистентное хранилище с TTL и приватностью ради того, что клиенты и так передают в теле каждого хода.

Поле запроса	Что происходит
`input` строкой или массивом элементов	переводится в `messages`
`instructions`	становится системным сообщением перед историей
`tools`, `tool_choice`, `parallel_tool_calls`	поддержаны; у Responses `tools` плоские, у Chat Completions вложенные — перевод на нашей стороне
`function_call` / `function_call_output`	переводятся в `tool_calls` и `role: "tool"`
`max_output_tokens`	то же, что `max_tokens`
`stream: true`	поток в виде именованных событий Responses (`response.output_text.delta` и далее)
`previous_response_id`	`400 stateful_responses_unsupported` — «передавайте всю историю в `input`»
`store: true`	`400 stateful_responses_unsupported`
`background: true`	`400 background_unsupported` — фоновых задач у шлюза нет, вызов синхронный

Отдельно, чтобы не искать по 400:

usage.cost_usd приходит и в обычном ответе, и в финальном usage-блоке потока — по нему сверяется фактическое списание. В истории usage запросы через /v1/responses учитываются как chat.completions — это тот же маршрут биллинга, двойного списания нет.
Поток, упёршийся в max_output_tokens, закрывается событием response.incomplete (а не response.completed) — так же, как это описано в спецификации Responses API.
В каталоге /v1/models responses не появляется. endpoints описывает, что продаётся на модели, а responses — это то, как с нами можно разговаривать. Читайте chat.completions.
Лимит 20 RPM считается на ключ и суммарно по всем моделям и endpoints; /v1/responses тратит тот же счётчик.
Ошибки приходят в общем конверте: error.type, error.code, error.message, error.request_id. Справочник — коды ошибок.

Почему это год не работало

Раздел оставлен намеренно: если вы пришли сюда с поиска «Codex CLI не подключается к своему API», причина ниже — та самая, и она была настоящей.

Актуальные версии Codex CLI поддерживают для кастомных провайдеров (model_providers в ~/.codex/config.toml) только wire_api = "responses" — формат OpenAI Responses API. Значение wire_api = "chat", которое раньше позволяло говорить обычным Chat Completions, сам Codex CLI отклоняет с ошибкой «no longer supported» — не на первом запросе, а на старте. Обойти это настройкой на стороне клиента нельзя.

У go2llm endpoint /v1/responses не был опубликован. Запрос Codex CLI попадал в общий обработчик промаха и получал 404.

Второй слой той же проблемы, и он же хуже первого: этот 404 уходил плейн-текстом, семь байт, без content-type: application/json. SDK пытался разобрать тело как ошибку API, не находил ни error.type, ни error.message — и показывал человеку мусор вместо причины. Настоящая причина («такого маршрута тут нет») до пользователя не доезжала вовсе.

Починены оба слоя:

/v1/responses опубликован, и 2026-09-14 через него прошёл живой прогон Codex CLI — подробности и границы проверки в разделе «Подключение».
Любой неизвестный путь под /v1/ теперь отвечает JSON-конвертом с error.type, error.message, error.request_id и перечислением доступных маршрутов; известный путь с чужим методом — 405 с заголовком allow. Полный список маршрутов — на странице endpoints.

Урок мы записали прямо здесь, потому что он общий: ошибка обязана называть то, что спрашивал клиент, и в том конверте, который клиент умеет читать.

Альтернативы, проверенные живым запросом

Codex CLI — не единственный проверенный ответ на вопрос «чем писать код через go2llm»:

Claude Code — Anthropic Messages (/v1/messages), ✅ проверено живым запросом. См. инструкцию для Claude Code.
OpenCode — OpenAI Chat Completions (/v1/chat/completions), ✅ проверено живым запросом.
Kilo Code — 📄 по документации Kilo Code, вручную не тестировали.

Точные шаги и честный статус каждого инструмента — на странице «Инструменты для кода».

Если ваш клиент — не официальный Codex CLI

Некоторые продукты и форки называют себя «Codex» или похоже, но остаются обычным OpenAI-совместимым клиентом на Chat Completions. Подключение возможно, если в клиенте задаются свой base URL, API-ключ и модель:

curl https://go2llm.tech/v1/chat/completions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "content-type: application/json" \
  -d '{"model":"gpt-5.3-codex","messages":[{"role":"user","content":"Ответь только: OK"}]}'

Полное руководство — OpenAI-совместимый API. Общая техническая справка — документация.

Модели, расходы и лимиты

Каталог показывает только опубликованные модели, их модальности и поддерживаемые endpoints. Для задач с кодом основная статья расхода — не вход, а чтение кэша: у кодинг-агента профиль нагрузки примерно «вход 10%, выход 5%, чтение кэша 85%».

Пример из опубликованного каталога v38: gpt-5.3-codex — 0.519 $ за 1M входных токенов, 4.15 $ за 1M выходных, 0.05192 $ за 1M чтения кэша; официальный прайс вендора — 1.75 / 14 / 0.175, то есть в 3.3 раза дороже. Полная таблица — на странице цен и в GET /api/pricing.

Деньги: только pay-as-you-go, минимальное пополнение $1, при регистрации на баланс начисляется $1 — этого хватает на первый запрос без пополнения. Шлюз резервирует оценочную стоимость до вызова и списывает фактическую; баланс не уходит ниже нуля.

Prompt caching тарифицируется, но шлюз его сам не включает: кэш работает от того, что положил в тело клиент.

Частые вопросы

Это официальный вход в Codex?

Нет. go2llm — OpenAI-совместимый и Anthropic-совместимый API-шлюз, не реселлер OpenAI. Страница описывает, как направить Codex CLI на наш base URL и что мы при этом проверили сами.

Что именно вы проверили живым запросом?

2026-09-14, Codex CLI 0.151.0, wire_api = "responses", модель qwen3-8-flash: codex exec прочитал файл тестового проекта, исполнил инструменты, внёс правку и показал корректный diff. Отдельно curl'ом против прода проверены не-поток, поток, вызов инструмента (function_call с корректными аргументами), отказ на previous_response_id с 400 stateful_responses_unsupported и usage.cost_usd во всех формах. Списание сошлось до цента. Чего мы не проверяли: интерактивный TUI codex и модели, кроме qwen3-8-flash, — поэтому «работает со всеми моделями» на этой странице вы не увидите.

Codex ругается на `wire_api = "chat"`

Это ожидаемо и не связано с go2llm: актуальные версии Codex CLI такое значение не принимают. Ставьте wire_api = "responses" либо опустите поле — оно и так по умолчанию.

Что делать при ошибке?

Проверьте ключ, model ID, base URL с /v1 на конце, баланс и HTTP-код. 400 stateful_responses_unsupported означает, что клиент просит серверное состояние — передавайте историю в input. Дальше — справочник ошибок или поддержка, без передачи полного API-ключа.

Получить ключ и сделать первый запрос за 3 минуты → https://go2llm.tech/