รัน Goose บน custom OpenAI-compatible endpoint

คำตอบสั้น ๆ: คง provider openai ไว้ แค่ override host

Goose มีเส้นทาง custom-endpoint ที่มีเอกสารรองรับ: คง GOOSE_PROVIDER ไว้ที่ openai แล้ว override ว่า provider นั้นชี้ไปที่ไหน OPENAI_HOST แทนที่ host เริ่มต้น api.openai.com, OPENAI_API_KEY ยืนยันตัวตน และ GOOSE_MODEL เลือกโมเดลด้วย id เป๊ะ ๆ path ของ request แยกต่างหาก: OPENAI_BASE_PATH ค่าเริ่มต้นคือ v1/chat/completions และปกติไม่ต้องเปลี่ยน สังเกตรูปทรงนี้ให้ดี เพราะมันกลับด้านกับเครื่องมือส่วนใหญ่ในกลุ่มนี้: OPENAI_HOST รับแค่ host เปล่า ๆ https://api.apisrouter.com ไม่มี suffix /v1 ส่วน /v1/chat/completions อยู่ใน OPENAI_BASE_PATH การเติม /v1 ต่อท้าย host จะทำให้ path ซ้ำสองครั้งและเกิด 404 ที่ดูเหมือน 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

Goose คุยกับ provider ของมันอย่างไร

Goose (block บน GitHub มีดาวราว 51K) คือ engineering agent อัตโนมัติจาก Block ที่วางแผนงาน แก้ไขไฟล์ รันคำสั่ง shell และขับเคลื่อน extension แบบ MCP ทั้งหมดนี้อยู่บนบทสนทนาโมเดลเดียว: ทุกขั้นของ loop คือ request /v1/chat/completions ที่แนบ tool definition มาด้วย ดังนั้นการตั้งค่า provider คือตัวตัดสินว่า agent ทั้งตัวรันที่ไหน การตั้งค่าเป็นชั้น ๆ เส้นทาง interactive คือ goose configure ซึ่งสำหรับ provider openai จะถามหา API key และ custom host แบบเสริม แล้วเขียนค่าที่ไม่ใช่ secret อย่าง GOOSE_PROVIDER และ GOOSE_MODEL ลงใน ~/.config/goose/config.yaml แอป desktop เปิดค่าตั้งค่า provider เดียวกันผ่าน UI ของมัน Secret จัดการแยกต่างหาก: key ไปที่ system keychain หรือมาจาก environment variable และ key ที่วางตรง ๆ ใน config.yaml จะถูกเมินแทนที่จะถูกอ่าน Environment variable มีความสำคัญเหนือกว่าไฟล์ ซึ่งเป็นสิ่งที่ทำให้เส้นทาง env ข้างบนใช้ได้ทุกที่ ตั้งแต่ shell บน laptop ไปจนถึง CI runner เพราะ Goose ส่งผ่าน GOOSE_MODEL เป็นสตริงธรรมดา id จึงเป็นอะไรก็ได้ที่ endpoint หลัง OPENAI_HOST เสิร์ฟ: id ของ Claude วันนี้ id ของ Kimi หรือ Qwen พรุ่งนี้ แค่เปลี่ยนตัวแปรเดียว

เส้นทาง declarative: ไฟล์ custom provider

นอกเหนือจาก env override เอกสารปัจจุบันของ Goose ยังอธิบาย custom provider แบบ declarative: ไฟล์ JSON ที่วางไว้ใน ~/.config/goose/custom_providers/ (ไดเรกทอรี config ตามแพลตฟอร์มบน Windows) ที่ลงทะเบียน provider ที่มีชื่อคู่กับตัวที่มีมาให้ ไฟล์นี้ประกาศ engine (openai สำหรับ endpoint แบบ chat-completions), environment variable ไหนถือ key, endpoint URL และโมเดลที่ provider เสนอ ระวังธรรมเนียม URL ตรงนี้ เพราะมันกลับด้านอีกครั้ง: ต่างจาก OPENAI_HOST base_url ของ custom provider คือ request URL แบบเต็มรวม path ด้วย https://api.apisrouter.com/v1/chat/completions แต่ละ entry ใน models ยังมี context_limit เพื่อให้ Goose รู้ window ที่มันบรรจุได้ ไฟล์ declarative เหมาะกว่าเมื่อคุณต้องการให้ gateway ปรากฏเป็น provider ที่มีชื่อของตัวเองในรายการ provider ของ Goose พร้อม environment variable ของ key และรายการโมเดลของตัวเอง แทนที่จะยึดช่อง openai env override เหมาะกว่าสำหรับ CI และการสลับเร็ว ๆ ทั้งสองทางไปจบที่ endpoint เดียวกัน เลือกทางใดทางหนึ่งแล้วหลีกเลี่ยงการซ้อนทับกัน

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

เลือกโมเดลสำหรับ agent อัตโนมัติ

workflow ที่ใช้ได้จริงคือตรึงชุดงานของคุณไว้คงที่ แล้วหมุนเวียน GOOSE_MODEL ข้ามสองหรือสามตัวเลือกครั้งละไม่กี่ session เพราะทุกตัวเลือก route ผ่าน key เดียวกัน มุมมอง usage ต่อ key ตั้งราคาให้แต่ละการทดลองโดยไม่ต้องบันทึกอะไรเพิ่มเลยฝั่งคุณ

• Goose รันเป็นช่วงยาวโดยไม่มีคนคอยดู: วางแผน, แก้ไข, รัน, อ่านผลลัพธ์, ทำซ้ำ ความน่าเชื่อถือของ tool call สำคัญกว่าความคมคายดิบ ๆ ซึ่งเป็นเหตุผลที่ claude-sonnet-4-6 และ claude-opus-4-7 เป็นค่าเริ่มต้นที่คนส่วนใหญ่ลงเอยกันสำหรับ loop หลัก
• id ที่ปรับจูนมาสำหรับโค้ดอย่าง kimi-k2.7-code คุ้มค่าที่จะทดสอบสำหรับ session ที่ refactor หนัก ผ่าน gateway การทดสอบนั้นเป็นแค่การเปลี่ยน GOOSE_MODEL ไม่ใช่การย้าย provider
• session ยาวสะสม context โมเดลที่มี window 200k จริง ๆ ประกาศอย่างซื่อสัตย์ผ่าน context_limit ในเส้นทาง declarative ทำให้ Goose แบกประวัติ session ได้มากขึ้นก่อนจะสรุป
• สำหรับงาน scripted หรือ CI id ระดับกลาง (gpt-5.4, qwen3.7-max) มักผ่านเกณฑ์สำหรับงานที่กำหนดขอบเขตชัดในต้นทุนเพียงเสี้ยวหนึ่งของระดับ frontier วัดผลบนงานของคุณเองก่อนจะตั้งค่าเริ่มต้นให้สูงขึ้น

จ่ายตามการใช้งาน · ถูกกว่าราคาทางการ

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 ตัวแปร host รับแค่ host เปล่า ๆ ส่วน path อยู่ใน OPENAI_BASE_PATH ซึ่งค่าเริ่มต้นคือ v1/chat/completions อยู่แล้ว https://api.apisrouter.com/v1 เป็น host จะให้ request /v1/v1/... และ 404 นี่คือข้อผิดพลาดที่พบบ่อยที่สุด เพราะเครื่องมืออื่นทุกตัวต้องการ suffix /v1 พอดี ธรรมเนียม URL เต็มในไฟล์ custom provider base_url แบบ declarative คือ request URL แบบเต็มรวม /v1/chat/completions ซึ่งเป็นธรรมเนียมตรงข้ามกับ OPENAI_HOST การก็อป host เปล่า ๆ ลงในไฟล์ custom provider ทำให้พังพอ ๆ กับการก็อป URL เต็มลงใน OPENAI_HOST key ใน config.yaml ไม่ยืนยันตัวตน Goose อ่าน secret จาก keychain หรือ environment และเมิน key ที่วางไว้ใน config.yaml ถ้า 401 ยังอยู่หลังแก้ไฟล์แล้ว นี่คือเหตุผล export ตัวแปรหรือรัน goose configure ใหม่แล้วกรอก key ตอนที่มันถาม session ของ desktop ไม่เห็น shell export แอป desktop ไม่สืบทอดอะไรจาก terminal profile ของคุณเลย ตั้งค่า provider ผ่าน UI ของ desktop settings หรือเปิดจาก shell ที่มีตัวแปรตั้งไว้แล้ว แหล่งการตั้งค่าซ้อนทับกัน OPENAI_HOST เก่าที่ export ไว้อาจ override สิ่งที่คุณเพิ่งตั้งใน config.yaml เพราะ environment ชนะไฟล์ เมื่อการ route ดูผิดปกติ ให้ print ตัวแปรที่เกี่ยวข้องใน shell เดียวกับที่เปิด Goose ก่อนโทษชั้นใดชั้นหนึ่ง

ใครที่ใช้ Goose ผ่าน gateway

• วิศวกรที่รัน Goose เป็นตัวขับเคลื่อนประจำวันและต้องการเข้าถึง Claude, GPT, Kimi และ Qwen อยู่หลัง key เดียว แทนที่จะเป็น credential ชุดละหนึ่งต่อ vendor
• ทีมที่นำ Goose เข้าไปใน CI หรือ scheduled job เส้นทางแบบ env-only หมายความว่า runner ต้องการแค่ตัวแปร routing สองตัวกับ secret หนึ่งตัว ฉีดและหมุนเวียนได้ง่าย
• นักพัฒนาที่เปรียบเทียบ agent model บนงานจริง แต่ละตัวเลือกคือค่า GOOSE_MODEL หนึ่งค่ากับ endpoint เดียวกัน ตั้งราคาอัตโนมัติด้วย usage ต่อ key
• ทีม platform ที่ต้องการเห็นค่าใช้จ่าย agent ต่อ key และต่อโมเดลบน surface การเก็บเงินเดียว แทนที่จะกระทบยอด dashboard vendor หลายตัว
• นักพัฒนาที่ไม่มีทางเข้าถึงระบบเก็บเงินของ vendor รายใดรายหนึ่ง การเข้าถึงแบบเติมเงินโดยไม่ต้องใช้บัตรตัดการพึ่งพาการสมัครต่อ provider ออกไป

ตรวจสอบ endpoint และ debug session แรก

ยืนยันว่า gateway เสิร์ฟ id ใน GOOSE_MODEL ก่อนเริ่ม session รายการ /v1/models คือการสะกดที่ถูกต้อง รวมถึง suffix เวอร์ชัน ความล้มเหลวใน session แรกมีรูปแบบคงที่ 404 หมายความว่า host กับ path ประกอบกันผิด เกือบทุกครั้งคือ /v1 ใน OPENAI_HOST 401 หมายความว่า key ไม่ได้อยู่ในที่ที่ Goose มองหา: ไม่ได้ export ใน shell ที่เปิดมัน ไม่ได้อยู่ใน keychain หรืออยู่ใน config.yaml แบบไร้ประโยชน์ error โมเดลไม่พบจาก gateway คือ id พิมพ์ผิดใน GOOSE_MODEL ถ้า session เริ่มได้แต่ tool call ทำงานแปลก ๆ เช็กว่าคุณอยู่บนโมเดลที่รองรับ tool use จริง ๆ ซึ่ง id ในตารางข้างบนทั้งหมดรองรับ เมื่อ loop รันแล้ว console ของ APIsRouter แสดงโมเดลต่อ request, จำนวน token และค่าใช้จ่าย agent อัตโนมัติคืองานที่เรื่องนี้สำคัญที่สุด: session ยาว, tool-call มีหลายเทิร์น และมุมมอง usage คือวิธีที่คุณเห็นว่าบ่ายหนึ่งของ Goose เสียเงินไปเท่าไหร่จริง ๆ

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

คำถามที่พบบ่อย