Patakbuhin ang Goose sa isang custom OpenAI-compatible endpoint.

Mabilisang sagot: panatilihin ang openai na provider, i-override ang host.

Nagdadala ang Goose ng naka-document na custom-endpoint na path: panatilihing naka-set ang GOOSE_PROVIDER sa openai at i-override kung saan tumuturo ang provider na iyon. Pinapalitan ng OPENAI_HOST ang default na api.openai.com na host, nag-a-authenticate ang OPENAI_API_KEY, at pinipili ng GOOSE_MODEL ang model ayon sa eksaktong id. Hiwalay ang request path: nag-defa-default ang OPENAI_BASE_PATH sa v1/chat/completions at karaniwang hindi na kailangang baguhin. Pansinin nang mabuti ang hugis, dahil kabaligtaran ito ng karamihan ng mga tool sa klaseng ito: kinukuha ng OPENAI_HOST ang bare host, https://api.apisrouter.com, nang walang /v1 suffix. Ang bahaging /v1/chat/completions ay nasa OPENAI_BASE_PATH. Ang pagdaragdag ng /v1 sa host ay nagdodoble sa path at gumagawa ng mga 404 na tila sirang gateway.

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

Paano nakikipag-usap ang Goose sa provider nito.

Ang Goose (block sa GitHub, humigit-kumulang 51K stars) ay isang autonomous na engineering agent mula sa Block na nagpaplano ng mga gawain, nag-e-edit ng mga file, nagpapatakbo ng mga shell command, at nagpapatakbo ng mga MCP-based na extension. Nakasalalay ang lahat ng ito sa isang usapan ng model: bawat hakbang ng loop ay isang /v1/chat/completions na request na may kalakip na mga tool definition, kaya ang provider configuration ang nagpapasya kung saan tatakbo ang buong agent. Layered ang configuration. Ang interactive na path ay goose configure, na para sa openai na provider ay nagtatanong ng API key at isang opsyonal na custom host, pagkatapos ay isinusulat ang mga non-secret na setting tulad ng GOOSE_PROVIDER at GOOSE_MODEL sa ~/.config/goose/config.yaml; inilalantad rin ng desktop app ang parehong provider settings sa pamamagitan ng UI nito. Hiwalay ang paghawak ng mga secret: napupunta ang mga key sa system keychain o galing sa environment variable, at ang isang key na na-paste diretso sa config.yaml ay binabalewala sa halip na basahin. Nag-o-override ang mga environment variable sa file, na siyang dahilan kung bakit gumagana ang env path sa itaas kahit saan, mula sa laptop shell hanggang sa isang CI runner. Dahil ipinapasa ng Goose ang GOOSE_MODEL bilang plain string, maaaring maging kahit ano ang id na si-serve ng endpoint sa likod ng OPENAI_HOST: isang Claude id ngayon, isang Kimi o Qwen id bukas, isang variable lamang ang layo.

Ang declarative na path: isang custom provider file.

Higit sa env override, inilalarawan din ng kasalukuyang dokumentasyon ng Goose ang mga declarative na custom provider: isang JSON file na inilagay sa ~/.config/goose/custom_providers/ (per-platform na config directory sa Windows) na nagpaparehistro ng isang pinangalanang provider katabi ng mga built-in. Idinideklara ng file ang engine (openai para sa mga chat-completions na endpoint), kung aling environment variable ang may hawak ng key, ang endpoint URL, at ang mga model na inaalok ng provider. Bantayan ang convention ng URL dito, dahil muli itong nagbabaligtad: hindi tulad ng OPENAI_HOST, ang base_url ng custom provider ay ang buong request URL kasama ang path, https://api.apisrouter.com/v1/chat/completions. Ang bawat entry ng models ay may dalang context_limit para malaman ng Goose ang window na kaya nitong ipatong. Mas bagay ang declarative na file kapag gusto mong lumitaw ang gateway bilang sarili nitong pinangalanang provider sa listahan ng provider ng Goose, na may sariling variable ng key, sa halip na sakupin ang slot ng openai. Mas bagay ang env override para sa CI at mabilis na pagpapalit. Parehong nagtatapos sa parehong endpoint; pumili ng isa at iwasang i-stack ang dalawa.

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

Pagpili ng model para sa isang autonomous na agent.

Ang praktikal na workflow ay panatilihing nakapirmi ang set ng gawain mo at i-rotate ang GOOSE_MODEL sa dalawa o tatlong kandidato sa loob ng ilang session bawat isa. Dahil dumadaan ang bawat kandidato sa parehong key, pinepresyuhan ng per-key na usage view ang bawat eksperimento nang walang anumang bookkeeping sa panig mo.

• Tumatakbo ang Goose sa mahahabang panahong walang bantay: plano, i-edit, patakbuhin, basahin ang output, ulitin. Mas mahalaga ang reliability ng tool-call kaysa sa raw eloquence, kaya nagsasama-sama ang mga tao sa claude-sonnet-4-6 at claude-opus-4-7 para sa default na main loop.
• Sulit i-test ang mga coding-tuned na id tulad ng kimi-k2.7-code para sa mga session na puno ng refactor; sa pamamagitan ng gateway, ang test na iyon ay isang GOOSE_MODEL na pagbabago lamang, hindi provider migration.
• Nagpapatong ang mahahabang session ng context. Ang isang model na may tunay na 200k na window, idinedeklara nang tapat sa pamamagitan ng context_limit sa declarative na path, ay nagpapahintulot sa Goose na magdala ng mas maraming session history bago mag-summarize.
• Para sa scripted o CI na paggamit, madalas na sumasapat ang isang mid-tier na id (gpt-5.4, qwen3.7-max) para sa mga gawaing malinaw ang saklaw sa isang bahagi lamang ng frontier spend; sukatin sa iyong sariling mga gawain bago mag-default sa mas mataas.

Pay-as-you-go · mas mababa sa opisyal na presyo

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

Ang mga failure mode na specific sa Goose.

Naidagdag ang /v1 sa OPENAI_HOST. Kinukuha ng host variable ang bare host; nasa OPENAI_BASE_PATH ang path, na nag-defa-default na sa v1/chat/completions. Ang https://api.apisrouter.com/v1 bilang host ay gumagawa ng /v1/v1/... na mga request at 404. Ito ang pinaka-karaniwang pagkakamali, dahil eksakto sa dahilang gustong-gusto ng bawat ibang tool ang /v1 suffix. Ang buong-URL na convention sa mga custom provider file. Ang base_url ng declarative ay ang kumpletong request URL kasama ang /v1/chat/completions, ang kabaligtaran ng convention ng OPENAI_HOST. Ang pagkopya ng isang bare host sa isang custom provider file ay sinisira ito nang katiyakan tulad ng pagkopya ng isang buong URL sa OPENAI_HOST. Hindi nag-a-authenticate ang mga key sa config.yaml. Binabasa ng Goose ang mga secret mula sa keychain o environment, at binabalewala ang mga value ng key na inilagay sa config.yaml. Kung nagpapatuloy ang isang 401 pagkatapos i-edit ang file, iyon ang dahilan; i-export ang variable o patakbuhin muli ang goose configure at ipasok ang key kapag hiningi. Hindi nakikita ng mga desktop session ang mga shell export. Walang manang anuman ang desktop app mula sa terminal profile mo. I-configure ang provider sa pamamagitan ng desktop settings UI, o maglunsad mula sa isang shell na may naka-set na mga variable. Nagkakapatong-patong na pinagmumulan ng configuration. Maaaring i-override ng isang lumang OPENAI_HOST na export ang kaka-set mo lang sa config.yaml, dahil mananalo ang environment sa file. Kapag mali ang tila ruta, i-print ang mga kaugnay na variable sa parehong shell na naglulunsad ng Goose bago sisihin ang alinman sa dalawang layer.

Sino ang nagru-route ng Goose sa pamamagitan ng isang gateway.

• Mga engineer na nagpapatakbo ng Goose bilang daily driver na gustong maabot ang Claude, GPT, Kimi, at Qwen sa likod ng isang key sa halip na isang set ng credential bawat vendor.
• Mga team na naglalagay ng Goose sa CI o mga scheduled na job. Ang env-only na path ay nangangahulugang kailangan lamang ng runner ng eksaktong dalawang routing variable at isang secret, madaling i-inject at madaling i-rotate.
• Mga developer na nagkukumpara ng agent models sa tunay na gawain. Bawat kandidato ay isang value ng GOOSE_MODEL laban sa parehong endpoint, awtomatikong pinepresyuhan ng per-key usage.
• Mga platform team na gustong makita ang gastos ng agent bawat key at bawat model sa isang billing surface, sa halip na pagsamahin ang ilang dashboard ng vendor.
• Mga developer na walang access sa billing ng isang partikular na vendor. Inaalis ng top-up based na access na walang kailangang card ang sign-up dependency bawat provider.

I-verify ang endpoint at i-debug ang unang session.

Kumpirmahin na si-serve ng gateway ang id sa GOOSE_MODEL bago magsimula ng session; ang listahan ng /v1/models ang totoong pagbabaybay, kasama ang mga version suffix. Consistent ang mga pagkabigo sa unang session. Ang 404 ay nangangahulugang mali ang pagbubuo ng host at path, halos palaging ang /v1 sa OPENAI_HOST. Ang 401 ay nangangahulugang wala ang key kung saan tumitingin ang Goose: hindi na-export sa shell na naglunsad nito, wala sa keychain, o nakaupong walang kwenta sa loob ng config.yaml. Ang model-not-found na error mula sa gateway ay typo sa id sa GOOSE_MODEL. Kung nagsimula ang session pero kakaiba ang gawi ng mga tool call, suriin kung nasa model ka na talagang sumusuporta sa tool use; ang lahat ng id sa talahanayan sa itaas ay sumusuporta. Kapag tumatakbo na ang loop, ipinapakita ng APIsRouter console ang per-request na model, token counts, at gastos. Ang autonomous na agent ang workload kung saan pinaka-mahalaga ito: mahahaba ang mga session, marami ang mga turn ng tool-call, at ang usage view ang paraan mo para makita kung magkano talaga ang gastos ng isang hapon ng Goose.

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

Mga madalas itanong