Uruchom Goose na niestandardowym endpoincie kompatybilnym z OpenAI.

Szybka odpowiedź: zostaw provider openai, nadpisz host.

Goose ma udokumentowaną ścieżkę niestandardowego endpointu: zostaw GOOSE_PROVIDER ustawione na openai i nadpisz, dokąd wskazuje ten provider. OPENAI_HOST zastępuje domyślny host api.openai.com, OPENAI_API_KEY uwierzytelnia, a GOOSE_MODEL wybiera model po dokładnym identyfikatorze. Ścieżka żądania jest osobna: OPENAI_BASE_PATH domyślnie to v1/chat/completions i zwykle nie wymaga zmiany. Uważnie przyjrzyj się temu kształtowi, bo jest odwrotny do większości narzędzi tej klasy: OPENAI_HOST przyjmuje sam host, https://api.apisrouter.com, bez sufiksu /v1. Część /v1/chat/completions żyje w OPENAI_BASE_PATH. Dopisanie /v1 do hosta podwaja ścieżkę i produkuje błędy 404, które wyglądają jak zepsuta bramka.

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

Jak Goose rozmawia ze swoim providerem.

Goose (block na GitHubie, ok. 51 tys. gwiazdek) to autonomiczny agent inżynieryjny od Block, który planuje zadania, edytuje pliki, uruchamia polecenia powłoki i napędza rozszerzenia oparte na MCP. Wszystko to opiera się na jednej konwersacji modelu: każdy krok pętli to żądanie /v1/chat/completions z dołączonymi definicjami narzędzi, więc konfiguracja providera decyduje, gdzie działa cały agent. Konfiguracja jest warstwowa. Interaktywną ścieżką jest goose configure, które dla providera openai pyta o klucz API i opcjonalny niestandardowy host, a następnie zapisuje niesekretowe ustawienia, takie jak GOOSE_PROVIDER i GOOSE_MODEL, do ~/.config/goose/config.yaml; aplikacja desktopowa udostępnia te same ustawienia providera przez swój UI. Sekrety są obsługiwane osobno: klucze trafiają do systemowego keychaina albo pochodzą ze zmiennych środowiskowych, a klucz wklejony bezpośrednio do config.yaml jest ignorowany, a nie odczytywany. Zmienne środowiskowe nadpisują plik, co sprawia, że powyższa ścieżka ze zmienną działa wszędzie, od powłoki na laptopie po runner CI. Ponieważ Goose przekazuje GOOSE_MODEL jako zwykły string, identyfikator może być dowolny, jaki obsługuje endpoint za OPENAI_HOST: dziś identyfikator Claude, jutro Kimi albo Qwen, o jedną zmienną dalej.

Ścieżka deklaratywna: plik niestandardowego providera.

Poza nadpisaniem przez zmienne środowiskowe, aktualna dokumentacja Goose opisuje też deklaratywnych niestandardowych providerów: plik JSON umieszczony w ~/.config/goose/custom_providers/ (katalog konfiguracji per platforma na Windowsie), który rejestruje nazwanego providera obok wbudowanych. Plik deklaruje engine (openai dla endpointów chat-completions), którą zmienną środowiskową trzyma klucz, URL endpointu oraz modele oferowane przez providera. Uważaj tu na konwencję URL, bo znów się odwraca: w przeciwieństwie do OPENAI_HOST, base_url niestandardowego providera to pełny URL żądania łącznie ze ścieżką, https://api.apisrouter.com/v1/chat/completions. Każdy wpis w models niesie context_limit, żeby Goose wiedziało, jakie okno może zapakować. Plik deklaratywny lepiej pasuje, gdy chcesz, żeby bramka pojawiła się jako własny, nazwany provider na liście providerów Goose, z własną zmienną klucza, zamiast zajmować slot openai. Nadpisanie przez zmienną środowiskową lepiej pasuje do CI i szybkiego przełączania. Oba kończą się na tym samym endpoincie; wybierz jedno i unikaj ich nakładania.

{
  "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
}

Dobór modelu dla autonomicznego agenta.

Praktyczny workflow to trzymanie zestawu zadań na stałe i rotowanie GOOSE_MODEL między dwoma albo trzema kandydatami przez kilka sesji każdy. Ponieważ każdy kandydat jest kierowany przez ten sam klucz, widok użycia per klucz wycenia każdy eksperyment bez żadnej księgowości po Twojej stronie.

• Goose działa przez odcinki bez nadzoru: planuj, edytuj, uruchamiaj, czytaj output, powtarzaj. Niezawodność wywołań narzędzi liczy się bardziej niż surowa elokwencja, dlatego claude-sonnet-4-6 i claude-opus-4-7 to domyślne wybory, do których ludzie się zbiegają dla głównej pętli.
• Identyfikatory dostrojone pod kodowanie, takie jak kimi-k2.7-code, warto przetestować przy sesjach z dużą ilością refaktoryzacji; przez bramkę ten test to jedna zmiana GOOSE_MODEL, a nie migracja providera.
• Długie sesje kumulują kontekst. Model z prawdziwym oknem 200k, zadeklarowanym uczciwie przez context_limit w ścieżce deklaratywnej, pozwala Goose nieść więcej historii sesji, zanim ją streszcza.
• Do użycia w skryptach albo CI identyfikator średniego poziomu (gpt-5.4, qwen3.7-max) często wystarcza do precyzyjnie zakresowanych zadań za ułamek flagowego wydatku; zmierz to na własnych zadaniach, zanim domyślnie wybierzesz coś droższego.

Płatność za użycie · poniżej cen oficjalnych

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

Tryby awarii charakterystyczne dla Goose.

/v1 dopisane do OPENAI_HOST. Zmienna host przyjmuje sam host; ścieżka żyje w OPENAI_BASE_PATH, które domyślnie już jest v1/chat/completions. https://api.apisrouter.com/v1 jako host daje żądania /v1/v1/... i błędy 404. To pojedynczy najczęstszy błąd, dokładnie dlatego, że każde inne narzędzie chce sufiksu /v1. Konwencja pełnego URL w plikach niestandardowego providera. Deklaratywne base_url to kompletny URL żądania łącznie z /v1/chat/completions — odwrotna konwencja niż w OPENAI_HOST. Skopiowanie samego hosta do pliku niestandardowego providera psuje go równie pewnie, jak skopiowanie pełnego URL do OPENAI_HOST. Klucze w config.yaml nie uwierzytelniają. Goose odczytuje sekrety z keychaina albo środowiska i ignoruje wartości kluczy umieszczone w config.yaml. Jeśli 401 utrzymuje się po edycji pliku, to właśnie dlatego; wyeksportuj zmienną albo uruchom ponownie goose configure i wpisz klucz, gdy o niego poprosi. Sesje desktopowe nie widzą eksportów powłoki. Aplikacja desktopowa niczego nie dziedziczy z profilu Twojego terminala. Skonfiguruj providera przez UI ustawień aplikacji desktopowej, albo uruchom ją z powłoki, w której ustawione są zmienne. Nakładające się źródła konfiguracji. Stary export OPENAI_HOST może nadpisać to, co właśnie ustawiłeś w config.yaml, bo środowisko bije plik. Gdy routing wygląda źle, wypisz odpowiednie zmienne w tej samej powłoce, która uruchamia Goose, zanim obwinisz którąkolwiek z warstw.

Kto kieruje Goose przez bramkę.

• Inżynierowie używający Goose na co dzień, którzy chcą mieć Claude, GPT, Kimi i Qwen osiągalne za jednym kluczem, zamiast jednego zestawu poświadczeń na dostawcę.
• Zespoły wpinające Goose w CI albo zaplanowane zadania. Ścieżka wyłącznie ze zmiennymi środowiskowymi oznacza, że runner potrzebuje dokładnie dwóch zmiennych routingu i jednego sekretu, łatwych do wstrzyknięcia i rotacji.
• Deweloperzy porównujący modele agentowe na prawdziwych zadaniach. Każdy kandydat to jedna wartość GOOSE_MODEL względem tego samego endpointu, automatycznie wyceniana przez użycie per klucz.
• Zespoły platformowe, które chcą widzieć wydatki agenta per klucz i per model na jednej powierzchni rozliczeniowej, zamiast uzgadniać kilka paneli od różnych dostawców.
• Deweloperzy bez dostępu do rozliczeń danego dostawcy. Dostęp oparty na doładowaniu, bez wymogu karty, usuwa zależność od rejestracji u każdego providera.

Zweryfikuj endpoint i debuguj pierwszą sesję.

Potwierdź, że bramka obsługuje identyfikator z GOOSE_MODEL, zanim rozpoczniesz sesję; lista /v1/models to autorytatywna pisownia, łącznie z sufiksami wersji. Awarie pierwszej sesji są spójne. 404 oznacza, że host i ścieżka złożyły się źle, prawie zawsze przez /v1 w OPENAI_HOST. 401 oznacza, że klucza nie ma tam, gdzie szuka go Goose: nie wyeksportowany w powłoce, która je uruchomiła, nie w keychainie, albo bezużytecznie siedzący wewnątrz config.yaml. Błąd model-not-found z bramki to literówka w identyfikatorze w GOOSE_MODEL. Jeśli sesja się zaczyna, ale wywołania narzędzi zachowują się dziwnie, sprawdź, czy jesteś na modelu, który naprawdę obsługuje użycie narzędzi; wszystkie identyfikatory z powyższej tabeli to obsługują. Gdy pętla już działa, konsola APIsRouter pokazuje model per żądanie, liczbę tokenów i wydatki. Autonomiczny agent to obciążenie, w którym ma to największe znaczenie: sesje są długie, tur wywołań narzędzi jest wiele, a widok użycia to sposób, żeby zobaczyć, ile faktycznie kosztowało popołudnie z Goose.

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

Częste pytania