Запустите Goose на кастомном OpenAI-совместимом эндпоинте.

Короткий ответ: оставьте провайдера openai, переопределите хост.

Goose поставляется с задокументированным путём кастомного эндпоинта: оставьте GOOSE_PROVIDER установленным в openai и переопределите, куда указывает этот провайдер. OPENAI_HOST заменяет хост api.openai.com по умолчанию, OPENAI_API_KEY аутентифицирует, а GOOSE_MODEL выбирает модель по точному ID. Путь запроса отдельный: OPENAI_BASE_PATH по умолчанию равен v1/chat/completions и обычно не требует изменений. Обратите внимание на форму внимательно, потому что она обратна большинству инструментов этого класса: OPENAI_HOST принимает голый хост, https://api.apisrouter.com, без суффикса /v1. Часть /v1/chat/completions живёт в OPENAI_BASE_PATH. Добавление /v1 к хосту удваивает путь и даёт 404, которые выглядят как сломанный шлюз.

export GOOSE_PROVIDER=openai
export OPENAI_HOST=https://api.apisrouter.com   # bare host, no /v1
export OPENAI_API_KEY=sk-APIsRouter-...
export GOOSE_MODEL=claude-sonnet-4-6

goose session

Как Goose общается со своим провайдером.

Goose (block на GitHub, около 51K звёзд) — автономный инженерный агент от Block, который планирует задачи, редактирует файлы, запускает shell-команды и управляет расширениями на базе MCP. Всё это сидит на одном разговоре с моделью: каждый шаг цикла — это запрос /v1/chat/completions с прикреплёнными определениями инструментов, так что настройка провайдера решает, где работает весь агент. Конфигурация многослойна. Интерактивный путь — goose configure, который для провайдера openai запрашивает API-ключ и опциональный кастомный хост, затем записывает несекретные настройки вроде GOOSE_PROVIDER и GOOSE_MODEL в ~/.config/goose/config.yaml; десктопное приложение выставляет те же настройки провайдера через свой UI. Секреты обрабатываются отдельно: ключи идут в системный keychain или берутся из переменных окружения, а ключ, вставленный прямо в config.yaml, игнорируется, а не читается. Переменные окружения переопределяют файл, что и делает путь через env рабочим везде — от оболочки на ноутбуке до CI-раннера. Поскольку Goose передаёт GOOSE_MODEL как простую строку, ID может быть чем угодно, что обслуживает эндпоинт за OPENAI_HOST: сегодня ID Claude, завтра — ID Kimi или Qwen, разница в одной переменной.

Декларативный путь: файл кастомного провайдера.

Помимо переопределения через env, текущая документация Goose также описывает декларативных кастомных провайдеров: JSON-файл, помещённый в ~/.config/goose/custom_providers/ (или соответствующую по платформе директорию конфига на Windows), который регистрирует именованного провайдера рядом со встроенными. Файл объявляет движок (openai для эндпоинтов chat-completions), какая переменная окружения хранит ключ, URL эндпоинта и модели, которые предлагает провайдер. Обратите внимание на конвенцию URL здесь, потому что она снова переворачивается: в отличие от OPENAI_HOST, base_url кастомного провайдера — это полный URL запроса, включая путь, https://api.apisrouter.com/v1/chat/completions. Каждая запись models несёт context_limit, чтобы Goose знал окно, которое можно упаковать. Декларативный файл — лучший выбор, когда вы хотите, чтобы шлюз появился как собственный именованный провайдер в списке провайдеров Goose, со своей переменной ключа, а не занимал слот openai. Переопределение через env — лучший выбор для CI и быстрого переключения. Оба ведут к одному и тому же эндпоинту; выберите один и избегайте их наложения.

{
  "name": "apisrouter",
  "display_name": "APIsRouter",
  "engine": "openai",
  "api_key_env": "APISROUTER_API_KEY",
  "base_url": "https://api.apisrouter.com/v1/chat/completions",
  "models": [
    { "name": "claude-sonnet-4-6", "context_limit": 200000 },
    { "name": "claude-opus-4-7",   "context_limit": 200000 },
    { "name": "kimi-k2.7-code",    "context_limit": 200000 }
  ],
  "supports_streaming": true,
  "requires_auth": true
}

Выбор модели для автономного агента.

Практический рабочий процесс — зафиксировать набор задач и вращать GOOSE_MODEL между двумя-тремя кандидатами по несколько сессий каждый. Поскольку каждый кандидат идёт через один и тот же ключ, вид использования по ключу тарифицирует каждый эксперимент без какого-либо учёта с вашей стороны.

• Goose работает продолжительными отрезками без присмотра: план, правка, запуск, чтение вывода, повтор. Надёжность вызова инструментов важнее сырого красноречия, поэтому claude-sonnet-4-6 и claude-opus-4-7 — модели по умолчанию, к которым сходятся для основного цикла.
• ID, настроенные под код, вроде kimi-k2.7-code, стоит протестировать на насыщенных рефакторингом сессиях; через шлюз этот тест — одна смена GOOSE_MODEL, а не миграция провайдера.
• Длинные сессии накапливают контекст. Модель с реальным окном 200k, честно объявленным через context_limit в декларативном пути, позволяет Goose нести больше истории сессии, прежде чем суммаризировать.
• Для скриптового или CI-использования ID среднего уровня (gpt-5.4, qwen3.7-max) часто справляется с чётко очерченными задачами за долю флагманских расходов; измеряйте на своих задачах, прежде чем выбирать флагман по умолчанию.

Оплата по факту · дешевле официальных цен

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

Сбои, специфичные именно для Goose.

/v1, дописанный к OPENAI_HOST. Переменная хоста принимает голый хост; путь живёт в OPENAI_BASE_PATH, который уже по умолчанию равен v1/chat/completions. https://api.apisrouter.com/v1 в качестве хоста даёт запросы /v1/v1/... и 404. Это самая частая ошибка именно потому, что каждый другой инструмент хочет суффикс /v1. Конвенция полного URL в файлах кастомного провайдера. Декларативный base_url — это полный URL запроса, включая /v1/chat/completions, — обратная конвенция по сравнению с OPENAI_HOST. Копирование голого хоста в файл кастомного провайдера ломает его так же верно, как копирование полного URL в OPENAI_HOST. Ключи в config.yaml не аутентифицируют. Goose читает секреты из keychain или окружения и игнорирует значения ключей, помещённые в config.yaml. Если 401 не исчезает после правки файла, вот почему; экспортируйте переменную или заново запустите goose configure и введите ключ при запросе. Десктопные сессии не видят экспорты оболочки. Десктопное приложение не наследует ничего из профиля вашего терминала. Настройте провайдера через UI настроек десктопа, либо запускайте из оболочки, где переменные уже заданы. Наложенные источники конфигурации. Старый экспорт OPENAI_HOST может переопределить то, что вы только что задали в config.yaml, потому что окружение важнее файла. Когда маршрутизация выглядит неправильно, выведите соответствующие переменные в той же оболочке, что запускает Goose, прежде чем винить любой из слоёв.

Кто направляет Goose через шлюз.

• Инженеры, использующие Goose как ежедневный инструмент и желающие видеть Claude, GPT, Kimi и Qwen доступными за одним ключом вместо набора учётных данных на каждого вендора.
• Команды, помещающие Goose в CI или запланированные задачи. Путь только через env означает, что раннеру нужны ровно две переменные маршрутизации и один секрет — легко внедрить и легко ротировать.
• Разработчики, сравнивающие агентные модели на реальных задачах. Каждый кандидат — одно значение GOOSE_MODEL против того же эндпоинта, тарифицируемое автоматически по использованию через ключ.
• Платформенные команды, желающие видеть расходы агента по ключу и по модели на одной поверхности биллинга, а не сверять несколько вендорских дашбордов.
• Разработчики без доступа к биллингу конкретного вендора. Доступ на основе пополнения без требования карты убирает зависимость от регистрации у каждого провайдера.

Проверьте эндпоинт и отладьте первую сессию.

Подтвердите, что шлюз обслуживает ID из GOOSE_MODEL, прежде чем начинать сессию; листинг /v1/models — авторитетное написание, включая версионные суффиксы. Сбои первой сессии постоянны. 404 означает, что хост и путь составились неверно, почти всегда /v1 в OPENAI_HOST. 401 означает, что ключ не там, где его ищет Goose: не экспортирован в оболочке, которая его запустила, не в keychain, или бесполезно лежит внутри config.yaml. Ошибка model-not-found от шлюза — это опечатка ID в GOOSE_MODEL. Если сессия стартует, но вызовы инструментов ведут себя странно, проверьте, что вы на модели, которая реально поддерживает использование инструментов; все ID в таблице выше поддерживают. Как только цикл работает, консоль APIsRouter покажет модель на запрос, счётчики токенов и расходы. Автономный агент — это нагрузка, где это важнее всего: сессии длинные, ходов с вызовами инструментов много, и вид использования — это то, как вы видите, во что реально обошёлся вечер с Goose.

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $OPENAI_API_KEY" | head -50

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