เพิ่มทุกโมเดลในแคตตาล็อกเข้า Chatbox ด้วย custom provider เดียว

คำตอบสั้น ๆ: dialog เดียวในการตั้งค่า Model Provider

เปิด Settings ของ Chatbox แล้วสลับไปที่แท็บ Model Provider คลิก Add แล้วคลิก Add Custom Provider กรอก dialog ด้วยห้าค่า: Name (APIsRouter), API Mode ตั้งเป็น OpenAI API Compatible, key ของคุณใน API Key, https://api.apisrouter.com/v1 ใน API Host และปล่อย API Path ไว้ที่ค่าเริ่มต้น /chat/completions ที่ Chatbox เติมให้เมื่อ host ลงท้ายด้วย /v1 จากนั้นเพิ่มโมเดล ปุ่ม Fetch จะดึงรายการโมเดลของ endpoint ผ่าน /v1/models เพื่อให้คุณเปิดใช้ id จากแคตตาล็อกได้โดยตรง และ New ให้คุณพิมพ์ id ด้วยมือถ้าคุณต้องการ picker ที่คัดสรรสั้น ๆ คลิก Check ข้างฟิลด์ key แล้ว Chatbox จะรัน request จริง สัญลักษณ์ยืนยันสีเขียวแปลว่า provider เชื่อมต่อแล้ว เราตรวจสอบ flow นี้เป๊ะ ๆ กับ Chatbox web app เวอร์ชันปัจจุบัน และ dialog เดียวกันมีใน build ของ desktop และมือถือด้วย

Chatbox คุยกับ custom provider อย่างไร

Chatbox (chatboxai บน GitHub มีดาวราว 41K) คือหนึ่งใน AI chat client ที่ถูกติดตั้งมากที่สุด: แอป native สำหรับ Windows, macOS และ Linux, build มือถือสำหรับ iOS และ Android และเวอร์ชันเบราว์เซอร์ที่ web.chatboxai.app มันมี entry แบบ first-party ให้ vendor ใหญ่ ๆ แต่ละตัวต้องการ key ของตัวเอง และ dialog custom provider คือเส้นทางที่มีเอกสารรองรับสำหรับทุกอย่างที่เหลือ custom provider ในโหมด OpenAI API Compatible เป็นแค่คำอธิบายของ endpoint ธรรมดา ๆ: host, path, key และรายการ model id ทุกเทิร์นของบทสนทนาจะกลายเป็น request chat-completions มาตรฐานไปที่ host นั้น โดย model id จาก picker เดินทางไปเป็นสตริง Chatbox ไม่สนใจว่าโมเดลหลัง id ถูกฝึกโดย vendor ไหน ซึ่งเป็นสิ่งที่ทำให้ gateway หลาย vendor มีประโยชน์ตรงนี้พอดี: provider entry เดียวนำ claude-sonnet-4-6, gpt-5.5, gemini-3.5-flash และ deepseek-v4-flash มาไว้ใน picker เดียวกัน เก็บเงินผ่าน key เดียวกัน ความต่างในทางปฏิบัติจากการวาง provider แบบ first-party ทีละสี่ตัวไม่ใช่แค่เรื่อง key น้อยลง Chatbox sync การตั้งค่าต่อเครื่อง ดังนั้นบัญชี vendor ทุกตัวที่คุณเพิ่มคือ key อีกตัวที่ต้องวางลงในมือถือ, laptop และ web app ของคุณ custom provider ตัวเดียวคือการวางครั้งเดียวต่อเครื่อง และการสลับบทสนทนาจาก Claude ไปเป็น DeepSeek เป็นแค่การเปลี่ยน picker ไม่ใช่การเปลี่ยน provider

ตั้งค่าแบบเต็ม: ทุกฟิลด์ใน dialog

Name เป็นแค่ label APIsRouter ทำให้ picker อ่านง่าย API Mode ต้องเป็น OpenAI API Compatible ซึ่งบอก Chatbox ให้พูด chat completions มาตรฐาน โหมดอื่นใน dropdown มีไว้สำหรับ endpoint แบบ Gemini-native ซึ่งไม่ใช่สิ่งที่ gateway ต้องการ API Host และ API Path ประกอบกันเป็น URL ของ request และคู่นี้คือจุดที่การตั้งค่ามักผิดพลาด ด้วย host ตั้งเป็น https://api.apisrouter.com/v1 path คือ /chat/completions และ Chatbox จะกรอกค่านี้เป๊ะ ๆ ให้เมื่อมันจำได้ว่า host ลงท้ายด้วย /v1 เอกสารของ Chatbox ยังอธิบายธรรมเนียม host เปล่าด้วย ที่ host ไม่มี /v1 และ path ค่าเริ่มต้นคือ /v1/chat/completions ทั้งสองแบบประกอบเป็น URL เดียวกัน ดังนั้นเลือกรูปทรงใดรูปทรงหนึ่งแล้วปล่อยอีกฟิลด์ไว้ที่ค่าเริ่มต้น สิ่งที่พังคือการผสมทั้งสอง host แบบ /v1 กับ path แบบ /v1/chat/completions ซึ่งสร้าง URL /v1/v1 ที่ 404 label ของฟิลด์และพฤติกรรม autofill ขยับเล็กน้อยระหว่าง release ของ Chatbox ดังนั้นเชื่อ URL ที่ประกอบแล้วมากกว่าความจำ สำหรับโมเดล Fetch คือเส้นทางที่ออกแรงน้อยที่สุด: Chatbox ลิสต์ทุกอย่างที่ endpoint เสิร์ฟแล้วคุณ toggle เปิดสิ่งที่ต้องการ New คือเส้นทางที่คัดสรร: พิมพ์ id ด้วยมือแล้ว picker จะสั้น แต่ละแถวโมเดลมีสวิตช์ capability (vision, tool use) ปล่อยมันไว้เป็นปิดเว้นแต่คุณรู้ว่าโมเดลรองรับ capability นั้น เพราะโมเดลที่ไม่ได้ตั้งค่าจะถูกปฏิบัติเป็นแชทข้อความธรรมดา ซึ่งเป็นค่าเริ่มต้นที่ปลอดภัย จบด้วย Check แล้วเปิดบทสนทนาแล้วเลือกโมเดลใต้ชื่อ provider ใหม่ของคุณ

Name:      APIsRouter
API Mode:  OpenAI API Compatible
API Key:   sk-YOUR-APISROUTER-KEY
API Host:  https://api.apisrouter.com/v1
API Path:  /chat/completions   (autofilled)

Models: Fetch (pull the catalog) or New (type ids)
Then:   Check → green confirmation

เลือกโมเดลสำหรับ chat client ที่ใช้ทุกวัน

เพราะทุกโมเดลที่เปิดใช้เก็บเงินผ่าน key เดียว การเปรียบเทียบสอง id เป็นแค่การสลับใน picker ไม่ใช่การตัดสินใจเรื่องบัญชี รันบทสนทนาประเภทเดียวกันบนทั้งคู่เป็นเวลาสองสามวัน แล้วอ่านค่าใช้จ่ายต่อโมเดลใน console ของ APIsRouter และเก็บตัวที่คุ้มค่าไว้

• คำถามประจำวันและการเขียนใหม่เร็ว ๆ เป็นงานแบบ burst claude-haiku-4-5-20251001 และ gemini-3.5-flash ตอบเร็วพอที่แอปจะรู้สึกไวทันที และแบก traffic ประจำวันส่วนใหญ่ได้ดี
• การร่างยาว, reasoning อย่างระมัดระวัง และการพูดคุยเรื่องโค้ดคุ้มค่ากับ claude-sonnet-4-6 หรือ gpt-5.5 เปิดใช้แต่ละระดับไว้หนึ่งตัวแล้วสลับต่อบทสนทนาแทนที่จะสลับต่อ provider
• deepseek-v4-flash คือตัวเลือกปริมาณมากถ้า Chatbox คือ sidebar ที่เปิดตลอดของคุณ บทสนทนาเล็ก ๆ ต่อเนื่องสะสมกัน และระดับเร็วทำให้ยอดคงเหลือลดลงช้า ๆ
• บทสนทนาที่มี input รูปภาพต้องการ id ที่รองรับ vision พร้อมเปิดสวิตช์ vision บนแถวโมเดลนั้น ยืนยัน capability กับเอกสารของโมเดลก่อนเปิดสวิตช์
• เปิดใช้โมเดลน้อยตัวอย่างตั้งใจแทนที่จะ fetch ทั้งหมด: แต่ละ toggle คือหนึ่งแถวใน picker และการเพิ่ม id อีกตัวทีหลังเป็นการแก้ไขสิบวินาที

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

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

รูปแบบความล้มเหลวเฉพาะของ Chatbox

path ที่ซ้ำกันคือกรณีคลาสสิก 404 ในทุกข้อความหมายความว่า API Host และ API Path ทั้งคู่มี /v1 หรือ path ซ้ำกับสิ่งที่ host ลงท้ายไว้แล้ว เปิด provider entry แล้วอ่านสองฟิลด์นี้เป็น URL เดียว ผลลัพธ์ว่างเปล่าจาก Fetch มักหมายความว่า key ผิดหรือหายไป เพราะการลิสต์โมเดลเองก็เป็น request ที่ต้องยืนยันตัวตน เช็กฟิลด์ API Key แล้วใช้ปุ่ม Check ซึ่งแสดง error ยืนยันตัวตนตรง ๆ โมเดลที่ error แค่บางบทสนทนามักเป็นสวิตช์ capability: เปิด vision บนโมเดลที่ไม่รับ input รูปภาพ หรือ flow ที่พึ่งพา tool ไปชนกับโมเดลที่ปิด tool ไว้ รีเซ็ตแถวโมเดลกลับเป็นค่าเริ่มต้นแล้วเปิด capability ทีละอย่าง และจำไว้ว่า provider entry อยู่ต่อการติดตั้ง การเพิ่ม APIsRouter บน desktop ไม่ได้ตั้งค่าให้มือถือของคุณ ทำ dialog ซ้ำที่นั่น หรือใช้ feature แชร์ config ของ Chatbox เองถ้าเวอร์ชันของคุณมี สิ่งเดียวที่ไม่ต้องทำซ้ำเลยคือการสมัคร vendor เพราะ key เดียวครอบคลุมทุกโมเดลบนทุกเครื่อง

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

• คนที่ต้องการ Claude, GPT, Gemini และ DeepSeek ใน picker เดียว โดยไม่ต้องดูแลบัญชี vendor สี่บัญชีกับ key สี่ตัวข้ามสามเครื่อง
• ผู้ใช้ในภูมิภาคที่การสมัคร vendor บางตัวยุ่งยาก การเข้าถึงแบบเติมเงินโดยไม่ต้องใช้บัตรตัดการพึ่งพาต่อ provider ออกไป
• นักพัฒนาที่ route เครื่องมือ editor และ terminal ผ่าน gateway อยู่แล้ว และต้องการให้ chat client ของตัวเองใช้ key และ usage log เดียวกัน
• นักช้อปโมเดลที่เปรียบเทียบ id บนบทสนทนาจริงก่อนตัดสินใจในโปรเจกต์เดียว แต่ละตัวเลือกคือหนึ่งแถวใน picker ไม่ใช่บัญชี
• ครัวเรือนและทีมเล็กที่ทำให้เป็นมาตรฐานด้วย endpoint เดียว ยอดคงเหลือเดียว และการเห็น usage ต่อ key แทนที่ค่าสมาชิกที่กระจัดกระจาย

ตรวจสอบ endpoint และ debug ข้อความแรก

พิสูจน์ฝั่ง gateway นอก Chatbox ก่อน: ดูรายการโมเดลด้วย key ของคุณ แล้วรัน chat completion หนึ่งครั้งกับ id ที่คุณวางแผนจะเปิดใช้ ถ้าทั้งสองผ่าน ที่เหลือทั้งหมดอยู่ใน dialog ของ provider ใน Chatbox ปุ่ม Check คือสัญญาณที่เร็วที่สุด error ยืนยันตัวตนคือฟิลด์ key error not-found ตอนส่งคือ id ไม่ตรงกัน ซึ่งมักเกิดกับ entry แบบ New ที่พิมพ์ด้วยมือ ก็อปปี้ id จาก output ของ /v1/models แทนความจำ 404 ในทุก request คือการประกอบ host/path ที่กล่าวไว้ข้างต้น เมื่อข้อความไหลลื่นแล้ว console ของ APIsRouter แสดงโมเดลต่อ request, จำนวน token และค่าใช้จ่าย chat client สร้าง request เล็ก ๆ จำนวนมากตลอดวัน และ usage log คือที่ที่พฤติกรรมนั้นกลายเป็นตัวเลขต่อโมเดล ต่อวันที่คุณอ่านได้จริง

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

curl -s https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $APISROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-haiku-4-5-20251001",
       "messages":[{"role":"user","content":"ping"}]}'

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