Запустіть 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, приблизно 51 тис. зірок) — автономний інженерний агент від Block, що планує завдання, редагує файли, запускає команди shell і керує розширеннями на основі MCP. Усе це тримається на одній розмові з моделлю: кожен крок циклу — це запит /v1/chat/completions з прикріпленими визначеннями інструментів, тож конфігурація провайдера вирішує, де працює весь агент. Конфігурація має шари. Інтерактивний шлях — goose configure, який для провайдера openai запитує API-ключ і опційний кастомний хост, тоді записує несекретні налаштування на кшталт GOOSE_PROVIDER і GOOSE_MODEL у ~/.config/goose/config.yaml; десктопний застосунок відкриває ті самі налаштування провайдера через власний інтерфейс. Секрети обробляються окремо: ключі йдуть у системний keychain або надходять зі змінних середовища, а ключ, вставлений напряму в config.yaml, ігнорується, а не зчитується. Змінні середовища перевизначають файл, і саме це робить шлях через середовище вище робочим будь-де — від shell на ноутбуці до CI-раннера. Оскільки Goose передає GOOSE_MODEL як звичайний рядок, ID може бути будь-яким, що обслуговує ендпоінт за OPENAI_HOST: ID Claude сьогодні, ID Kimi чи Qwen завтра — різниця в одній змінній.

Декларативний шлях: файл кастомного провайдера.

Крім перевизначення через середовище, поточна документація Goose також описує декларативних кастомних провайдерів: файл JSON, розміщений у ~/.config/goose/custom_providers/ (специфічний для платформи каталог конфігурації у Windows), що реєструє іменованого провайдера поряд із вбудованими. Файл оголошує engine (openai для ендпоінтів chat-completions), яка змінна середовища тримає ключ, URL ендпоінта і моделі, які пропонує провайдер. Зважайте на конвенцію URL тут, бо вона знову перевертається: на відміну від OPENAI_HOST, base_url кастомного провайдера — це повний URL запиту, включно зі шляхом, https://api.apisrouter.com/v1/chat/completions. Кожен запис models несе context_limit, щоб Goose знав вікно, яке може запакувати. Декларативний файл підходить краще, коли ви хочете, щоб шлюз з'явився як власний іменований провайдер у списку провайдерів Goose, з власною змінною ключа, а не займав слот openai. Перевизначення через середовище підходить краще для 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 знову і введіть ключ, коли запитають. Десктопні сесії не бачать експортів shell. Десктопний застосунок нічого не успадковує з профілю вашого термінала. Налаштуйте провайдера через інтерфейс налаштувань десктопу або запускайте з shell, у якому встановлені змінні. Нашаровані джерела конфігурації. Старий експорт OPENAI_HOST може перевизначити те, що ви щойно встановили в config.yaml, оскільки середовище перемагає файл. Коли маршрутизація виглядає неправильно, виведіть відповідні змінні в тому самому shell, що запускає Goose, перш ніж звинувачувати будь-який із шарів.

Хто маршрутизує Goose через шлюз.

• Інженери, що використовують Goose як основний щоденний інструмент і хочуть мати Claude, GPT, Kimi і Qwen доступними за одним ключем, замість одного набору облікових даних на постачальника.
• Команди, що впроваджують Goose у CI чи заплановані завдання. Шлях лише через середовище означає, що раннеру потрібні точно дві змінні маршрутизації і один секрет — легко впровадити й легко ротувати.
• Розробники, що порівнюють моделі агентів на реальних завданнях. Кожен кандидат — це одне значення GOOSE_MODEL проти того самого ендпоінта, автоматично оцінене за використанням за ключем.
• Команди платформ, що хочуть бачити витрати агента за ключем і за моделлю на одній поверхні білінгу, замість звірки кількох панелей постачальників.
• Розробники без доступу до білінгу певного постачальника. Доступ на основі поповнення без вимоги картки прибирає залежність від реєстрації в кожного провайдера.

Перевірте ендпоінт і налагодьте першу сесію.

Підтвердьте, що шлюз обслуговує ID у GOOSE_MODEL, перш ніж починати сесію; список /v1/models — авторитетне написання, включно з суфіксами версій. Збої першої сесії послідовні. 404 означає, що хост і шлях склались неправильно, майже завжди /v1 в OPENAI_HOST. 401 означає, що ключа немає там, де його шукає Goose: не експортовано в shell, який його запустив, не в keychain, або марно сидить всередині config.yaml. Помилка «модель не знайдено» від шлюзу — це помилка в написанні ID у GOOSE_MODEL. Якщо сесія стартує, але виклики інструментів поводяться дивно, перевірте, чи ви на моделі, яка справді підтримує використання інструментів; усі ID в таблиці вище підтримують. Щойно цикл запрацює, консоль APIsRouter показує модель на кожен запит, кількість токенів і витрати. Автономний агент — це навантаження, де це має найбільше значення: сесії довгі, ходів з викликом інструментів багато, і погляд на використання — це спосіб побачити, скільки насправді коштувало пообіддя з Goose.

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

Поширені запитання