บิลที่จุดชนวนเรื่องนี้คือ 312 ดอลลาร์ในบ่ายวันเดียว นักพัฒนาคนเดียว เซสชัน Octomind หนึ่งเซสชัน โมเดลตัวเดียวทำทุกงาน: อ่านไฟล์ รัน grep สรุป diff ตัดสินใจว่าจะบีบอัดคอนเท็กซ์เมื่อไร และทำการให้เหตุผลที่ยากจริง ๆ ทั้งหมดนั้นบนโมเดลระดับแนวหน้า เพราะนั่นคือสิ่งที่คุณเอื้อมไปหยิบเมื่ออยากให้เอเจนต์เก่ง
แล้ว OpenRouter ก็เริ่มคืนค่า 429 กลางการรีแฟกเตอร์ และผมก็เฝ้าดูเอเจนต์ค้างอยู่กับลิมิตอัตราคำขอขณะทำสิ่งที่โมเดลราคาถูกกว่าสิบเท่าก็ทำได้สมบูรณ์แบบ นั่นคือจังหวะที่สิ่งที่เห็นได้ชัดเข้าที่: สิ่งที่เอเจนต์ทำส่วนใหญ่ไม่ได้ยาก การไล่รายชื่อไฟล์ไม่ยาก การปรับงานที่คลุมเครือให้ชัดขึ้นไม่ยาก การตัดสินใจว่าเซสชันใหญ่พอจะบีบอัดหรือยังไม่ยาก การอ่านกองข้อมูลจากการค้นคว้าแล้วดึงสามไฟล์ที่เกี่ยวข้องออกมาไม่ยาก
คุณไม่ต้องใช้โมเดลที่ดีที่สุดของคุณกับสิ่งใดในนั้นเลย คุณต้องใช้มันสำหรับสักสิบเปอร์เซ็นต์ของการเรียก — การรีวิว การตัดสินใจออกแบบที่ยุ่งยาก diff ที่แตะ authentication อีกเก้าสิบเปอร์เซ็นต์เป็นงานหนักซ้ำซาก และงานหนักซ้ำซากคือที่ที่โมเดลราคาถูกและโมเดลโลคัลเปล่งประกายพอดี
นี่คือเรื่องราวของการกระจายเอเจนต์ Octomind ตัวเดียวไปยังหลายโมเดล โดยยึดกับคีย์คอนฟิกจริงที่มันมาพร้อมตัว พอจบ คุณจะมีการตั้งค่าแบบหลายโมเดลที่ใช้งานได้ ตารางสรุปการเลือกโมเดล และคำตอบที่ชัดเจนต่อคำถามที่สำคัญ: เอาอะไรไปไว้ตรงไหน
หนึ่งสตริง บนแบ็กเอนด์ใดก็ได้
Octomind คุยกับผู้ให้บริการทุกรายผ่านไลบรารีเดียว — octolib ซึ่งผมเขียนถึงไปก่อนหน้านี้ สิ่งที่ octolib ให้คุณ สิ่งที่ทำให้ทั้งหมดนี้เป็นไปได้ คือทุกโมเดลถูกตั้งชื่อแบบเดียวกัน: สตริง provider:model
model = "anthropic:claude-sonnet-5"
model = "openai:gpt-5.5"
model = "deepseek:deepseek-chat"
model = "openrouter:google/gemini-3.5-flash"
model = "ollama:glm-5"
ฟิลด์เดียวกัน รูปแบบเดียวกัน ทุกที่ที่กำหนดค่าโมเดล octolib แยกพรีฟิกซ์ กำหนดเส้นทางไปยังแบ็กเอนด์ที่ถูกต้อง และทำให้คำตอบเป็นมาตรฐาน — การใช้โทเค็น ต้นทุน เอาต์พุตแบบมีโครงสร้าง — เพื่อให้ส่วนที่เหลือของ Octomind ไม่ต้องสนใจว่าผู้ให้บริการรายใดตอบ
พรีฟิกซ์ผู้ให้บริการที่ octolib รู้จัก ณ รุ่นปัจจุบัน มีดังนี้:
openrouter openai anthropic google amazon
cloudflare deepseek cerebras groq together
fireworks nvidia minimax moonshot zai
byteplus featherless octohub ollama local
ผู้ให้บริการบนเครือข่ายยี่สิบราย บวกกับเมตา-โปรไวเดอร์พิเศษ cli สำหรับเอเจนต์ที่อิงกับ CLI ในเครื่อง (รายละเอียดด้านล่าง) moonshot และ kimi เป็นชื่อแทนของผู้ให้บริการเดียวกัน ผู้ให้บริการใหม่ลงใน octolib แล้วพร้อมใช้งานใน Octomind โดยอัตโนมัติ — ไม่ต้องออก Octomind รุ่นใหม่
อ้อ คีย์ API มาจากตัวแปรสภาพแวดล้อมเท่านั้น คุณใส่มันในไฟล์คอนฟิกไม่ได้ นั่นถูกถอดออกด้วยเหตุผลด้านความปลอดภัย คุณ export OPENROUTER_API_KEY=... (หรือวางไฟล์ .env ในไดเรกทอรีทำงาน) แล้ว octomind config --show จะบอกคุณว่ามันตรวจพบคีย์ใดและมาจากไหน คีย์ OpenRouter ตัวเดียวให้คุณเข้าถึงแคตตาล็อกได้เกือบทั้งหมดผ่านพรีฟิกซ์เดียว ส่วนคีย์ของผู้ให้บริการเฉพาะให้ส่วนที่เหลือ
โมเดลถูกเลือกที่ไหน
ก่อนกระจายงานข้ามโมเดล คุณต้องรู้สี่จุดที่สามารถตั้งโมเดลได้ และจุดไหนชนะเมื่อมีมากกว่าหนึ่งจุดที่มีผล Octomind แก้ปัญหาว่าโมเดลใดทำงานจริงตามลำดับนี้ ลำดับความสำคัญสูงสุดก่อน:
CLI --model > role.model > config.model
บวกตะเข็บที่สี่สำหรับเอเจนต์ tap: รายการ [taps] จะแทนที่ config.model สำหรับแท็กของเอเจนต์ tap เฉพาะตัว
config.model— ค่าเริ่มต้นที่ราก ในคอนฟิกที่เพิ่งสร้างใหม่จะเป็น Claude คลาส Sonnet ที่ส่งผ่าน OpenRouter — วันนี้คุณจะตั้งเป็นopenrouter:anthropic/claude-sonnet-5ทุกอย่างจะตกกลับมาที่นี่เมื่อไม่มีการตั้งค่าที่เจาะจงกว่านี้role.model— การแทนที่ต่อโรล นี่คือคันโยกหลัก แต่ละโรลตั้งชื่อโมเดลของตัวเองได้ และโมเดลของโรลจะถูกเคารพโดยตรงเหนือค่าเริ่มต้นที่ราก- การแทนที่
[taps]— สำหรับเอเจนต์ tap (เอเจนต์category:variantที่คุณติดตั้งจากรีจิสทรี) คุณปักหมุดโมเดลต่อแท็กได้โดยไม่ต้องแตะ manifest ของเอเจนต์:
[taps]
"developer:general" = "anthropic:claude-sonnet-5"
"octomind:assistant" = "openai:gpt-5.5"
- CLI
--model— ชนะทุกอย่างสำหรับการรันหนึ่งครั้ง:octomind run -m anthropic:claude-sonnet-5และกลางเซสชันคุณสลับสด ๆ ได้ด้วย/model deepseek:deepseek-chatหรือปรับระดับความพยายามในการให้เหตุผลด้วย/effort high
ดังนั้นกลยุทธ์จึงตรงไปตรงมา: เลือกค่าเริ่มต้นที่เหมาะสมใน config.model แล้วแทนที่ต่อโรลตรงที่งานเฉพาะสมควรได้โมเดลที่ต่างออกไป การประหยัดส่วนใหญ่มาจากชั้นโรล
โรล: หน่วยของการเลือกโมเดล
โรล ใน Octomind คือชุดพฤติกรรมที่มีชื่อ: system prompt หนึ่ง temperature หนึ่ง ชุดของเซิร์ฟเวอร์ MCP และสิทธิ์เครื่องมือ — และโมเดล (ไม่บังคับ) ทุกเซสชันรันด้วยโรล โรลตัดสินว่าเอเจนต์ทำอะไรได้ และ โมเดลใดเป็นคนทำ
คอนฟิกที่มาพร้อมตัวก็ทำตามที่บทความนี้สั่งสอนอยู่แล้ว มันกำหนดสี่โรลธรรมดา และสามในนั้นจงใจรันบนโมเดลที่ถูกกว่าโมเดลหลัก — โดยตรงนี้ปรับสตริงโมเดลเป็นรุ่นปัจจุบันแล้ว:
# การปรับคำขอแบบเบา ๆ — ทำงานคลุมเครือให้ชัดขึ้น ไม่มีเครื่องมือ
[[roles]]
name = "task_refiner"
model = "openrouter:openai/gpt-5.4-mini"
# ...
# การสำรวจ — รวบรวมคอนเท็กซ์ อ่านไฟล์ รายงานสิ่งที่พบ
[[roles]]
name = "task_researcher"
model = "openrouter:google/gemini-3.5-flash"
# ...
# การบีบอัดประวัติเซสชัน — สรุปและลดทอน
[[roles]]
name = "reduce"
model = "openrouter:openai/gpt-5-mini"
# ...
อ่านการเลือกโมเดลเหล่านั้นเป็นคำประกาศเชิงออกแบบ การปรับคำขอที่คลุมเครือเป็นงานสำหรับโมเดลเล็กและเร็ว (gpt-5.4-mini) การค้นคว้าที่อ่านไฟล์เยอะ ๆ ต้องการหน้าต่างคอนเท็กซ์ใหญ่และราคาถูก (gemini-3.5-flash) การบีบอัดประวัติเป็นงานสรุปแบบมีโครงสร้างที่โมเดลให้เหตุผลขนาดเล็กจัดการได้ดี (gpt-5-mini) ไม่มีตัวไหนต้องใช้โมเดลระดับแนวหน้า และคอนฟิกเริ่มต้นก็ไม่เปลืองโมเดลแบบนั้นไปกับมัน
คุณกำหนดโรลของคุณเองด้วยวิธีเดียวกัน ทุกฟิลด์ยกเว้น model เป็นข้อบังคับ — system, welcome, temperature, top_p และ top_k ต้องมีครบ ไม่งั้นคอนฟิกจะ parse ไม่ผ่าน:
# คอนเท็กซ์กว้างราคาถูกสำหรับการกวาดดูโค้ดเบส
[[roles]]
name = "researcher"
model = "openrouter:google/gemini-3.5-flash"
temperature = 0.3
top_p = 0.7
top_k = 20
system = "You gather context and report findings. You do not modify files."
welcome = ""
[roles.mcp]
server_refs = ["filesystem"]
allowed_tools = ["view"]
# ความแม่นยำตรงที่สำคัญ — การรีวิวและการตัดสินใจที่ยาก
[[roles]]
name = "reviewer"
model = "anthropic:claude-opus-4-8"
temperature = 0.2
top_p = 0.7
top_k = 20
system = "You review changes for correctness, security, and edge cases."
welcome = "Reviewer ready."
[roles.mcp]
server_refs = ["filesystem"]
allowed_tools = ["view", "ast_grep"]
ตอนนี้ octomind run researcher กวาดดู repo บนโมเดลคอนเท็กซ์ใหญ่ราคาถูก และ octomind run reviewer นำโมเดลราคาแพงออกมาเฉพาะงานที่คุ้มค่าเท่านั้น สลับระหว่างกันกลางเซสชันด้วย /role reviewer เอเจนต์เดียวกัน เซสชันเดียวกัน สองโมเดล — เลือกตามงาน
เลเยอร์: ร้อยโมเดลในรอบเดียว
โรลให้ คุณ เลือกโมเดลต่อเซสชัน เลเยอร์ ให้ระบบร้อยโมเดลอัตโนมัติภายในโฟลว์เดียว
เลเยอร์คือสเตจที่เรียกใช้ผ่าน ACP ซึ่งอ้างอิงโรลผ่านฟิลด์ command โรลพาโมเดล system prompt และเครื่องมือไปด้วย ส่วนเลเยอร์บอกว่าบทสนทนาไหลเข้าและออกจากสเตจนั้นอย่างไร ฟิลด์มีไม่มากและฟิลด์โหมดทั้งหมดเป็นข้อบังคับ:
[[layers]]
name = "analysis"
description = "Detailed analysis of code, systems, or requirements"
command = "octomind acp analysis" # spawns the `analysis` role over ACP
input_mode = "last" # last | all | summary
output_mode = "append" # none | append | replace | last | restart
output_role = "assistant"
เนื่องจากเลเยอร์ชี้ไปยังโรล และโรลพาโมเดลไปด้วย เลเยอร์แต่ละตัวในห่วงโซ่จึงรันบนโมเดลที่ต่างกันได้ โมเดลราคาถูกรวบรวมคอนเท็กซ์ ส่งเอาต์พุตไปยังสเตจถัดไป โมเดลที่แข็งแกร่งกว่าให้เหตุผลกับมัน โครงสร้าง LayerConfig เดียวกันยังหนุน [[commands]] — เลเยอร์ที่คุณทริกเกอร์แบบโต้ตอบด้วย /run <name> — ดังนั้นคำสั่ง reduce ที่มาพร้อมตัวจึงเป็นเลเยอร์เองที่รันโรล reduce ราคาถูกเพื่อบีบอัดประวัติตามต้องการ
แบบจำลองในใจ: โรลตอบ "โมเดลใดสำหรับ เซสชัน นี้" เลเยอร์ตอบ "โมเดลใดสำหรับ สเตจ นี้" รวมกันแล้วมันให้คุณกำหนดเส้นทางคำขอเดียวผ่านไปป์ไลน์ถูกแล้วแพงโดยไม่ต้องเขียนโค้ดออร์เคสเตรชัน — ทั้งหมดเป็น TOML
หมายเหตุ: รายการ
[[layers]]ต้องมีโรลที่ตรงกันใน[[roles]]โมเดลอยู่ในโรล ไม่เคยอยู่ในเลเยอร์ ถ้าคุณพบว่าตัวเองอยากตั้งโมเดลบนเลเยอร์ สิ่งที่คุณกำลังมองหาคือโรล
การบีบอัดมีโมเดลของตัวเอง — และมันควรราคาถูก
ยังมีการเลือกโมเดลอีกอย่างที่พลาดได้ง่ายและคืนทุนทันที Octomind บีบอัดเซสชันยาวโดยอัตโนมัติ และการเรียกแบบตัดสินใจ-บวก-สรุปที่ขับเคลื่อนการบีบอัดรันบนโมเดลที่กำหนดค่าไว้ ของมันเอง แยกจากตัวหลัก:
[compression.decision]
model = "openai:gpt-5-mini" # ถูกโดยการออกแบบ
max_tokens = 16000
temperature = 0.3
ค่าเริ่มต้นที่มาพร้อมตัวคือ openai:gpt-5-mini ด้วยเหตุผล: การเรียกนี้ยิงซ้ำ ๆ ตลอดเซสชันยาว และคุณไม่อยากให้โมเดลระดับแนวหน้ามาตัดสินว่าจะบีบอัดหรือไม่ anthropic:claude-haiku-4-5 เป็นทางเลือกที่ดีถ้าคุณใช้ Anthropic อยู่แล้ว ประเด็นเดียวกันกับทุกที่ในบทความนี้ — งานปกติเชิงโครงสร้างได้โมเดลปกติราคาถูก และการประหยัดทบต้นเพราะมันรันบ่อย
ตัวเครื่องบีบอัดเองก็ตระหนักถึงต้นทุน: ก่อนบีบอัด มันคำนวณประโยชน์สุทธิโดยใช้ราคาต่อโมเดลที่ดึงมาจากผู้ให้บริการ และข้ามการบีบอัดเมื่อมันจะมีต้นทุนมากกว่าที่ประหยัดได้ สำหรับโมเดลเซสชันฟรี/ราคาศูนย์ — เช่นโมเดล Ollama ในเครื่อง — มันบีบอัดเสมอ เพราะต้นทุนไม่เกี่ยว และคุณสนใจแค่ว่าคอนเท็กซ์ยังจัดการได้ ซึ่งนำเข้าสู่หัวข้อถัดไปได้พอดี
โมเดลโลคัลสำหรับงานปริมาณมาก
ไม่ใช่ทุกการเรียกต้องออกจากเครื่องของคุณ Octomind คุยกับโมเดลโลคัลได้สองทาง
Ollama และเอนด์พอยต์ที่เข้ากันได้กับ OpenAI ผ่านพรีฟิกซ์ ollama: และ local::
model = "ollama:glm-5"
model = "local:my-finetune" # set LOCAL_API_URL to your endpoint
ollama: ชี้ไปยังเดมอน Ollama ในเครื่องของคุณ local: ชี้ไปยังเซิร์ฟเวอร์ที่เข้ากันได้กับ OpenAI ใด ๆ ผ่าน LOCAL_API_URL ทั้งสองเป็นสตริง provider:model เดียวกันกับที่คอนฟิกส่วนที่เหลือใช้ — ใส่มันลงในฟิลด์ model ของโรล แล้วโรลนั้นจะรันในเครื่อง
เอเจนต์ CLI ในเครื่อง ผ่านเมตา-โปรไวเดอร์พิเศษ cli: ซึ่งรันเอเจนต์บรรทัดคำสั่งในเครื่องของคุณแทนการเรียก API บนเครือข่าย:
model = "cli:codex/gpt-5.2-codex"
รูปแบบคือ cli:<backend>/<model> โดย backend เป็นหนึ่งใน codex, claude, cursor, gemini หรือคำสั่งทั่วไป เนื่องจากมันรันผ่าน CLI ในเครื่อง จึงไม่ต้องใช้คีย์ API — Octomind ข้ามการตรวจสอบเครเดนเชียลทั้งหมดสำหรับโมเดล cli: พฤติกรรมปรับแต่งด้วยตัวแปรสภาพแวดล้อมเฉพาะ backend (สำหรับ backend codex คือ CODEX_COMMAND, CODEX_REASONING_EFFORT และพวกพ้อง)
โมเดลโลคัลคุ้มค่าตรงไหน: งานปริมาณมากเดิมพันต่ำที่ความหน่วงและความเป็นส่วนตัวสำคัญกว่าคุณภาพไม่กี่แต้มสุดท้าย การสรุปจำนวนมาก การจัดหมวดหมู่ การค้นคว้ารอบแรก อะไรก็ตามที่คุณรันเป็นพัน ๆ ครั้ง ใส่โมเดลโลคัลบนโรล researcher แล้วเฟสสำรวจไม่เสียค่าใช้จ่ายต่อโทเค็นเลย เก็บโมเดลบนคลาวด์ไว้ที่โรล reviewer ที่ช่องว่างด้านคุณภาพเห็นได้จริง
OctoHub: การกำหนดเส้นทางและการสำรองด้านล่าง
จนถึงตอนนี้การกำหนดเส้นทางเป็นแบบต่อโรลและต่อเลเยอร์ ตัดสินในคอนฟิก Octomind ของคุณ แต่ยังมีชั้นด้านล่าง — พร็อกซีจริง — และนั่นคือที่ที่การสำรอง (fallback) การกระจายโหลด และการบัญชีแบบรวมศูนย์อาศัยอยู่
OctoHub คือพร็อกซี LLM โอเพนซอร์สของเรา สำหรับ Octomind มันก็แค่ผู้ให้บริการอีกราย: คุณตั้งโมเดลแบบ octohub:my-model ชี้ Octomind ไปยังเอนด์พอยต์ของ OctoHub แล้วจากฝั่ง Octomind มันก็เป็นสตริง provider:model อีกหนึ่งตัว สิ่งที่ OctoHub ทำเบื้องหลังสตริงนั้นคือที่ที่มันมีประโยชน์ คอนฟิกของมันแมปชื่อโมเดลสั้น ๆ ไปยัง รายการ ของเป้าหมาย provider:model แบบเต็มรูปแบบ และสุ่มเลือกหนึ่งตัวต่อคำขอ:
[models]
# ชื่อแทนหนึ่งชื่อ หลายแบ็กเอนด์จริง — สุ่มเลือกต่อคำขอ = การกระจายโหลดแบบง่าย
"fast" = ["minimax:minimax-m3", "ollama:minimax-m3"]
แมปเดียวนั้นให้คุณการกระจายโหลดและรูปแบบ failover แบบนุ่ม ๆ: ถ้าแบ็กเอนด์หนึ่งถูกจำกัดอัตราหรือล่ม ตัวอื่นในรายการก็รับทราฟฟิกแทน OctoHub ยังทำการบันทึกคำขอ/คำตอบแบบเต็ม คีย์ API แบบหลายผู้เช่า (เพื่อให้นักพัฒนาหรือบริการแต่ละรายมีคีย์ของตัวเองและติดตามการใช้งานแยกกัน) และวิเคราะห์การใช้งานแบบรวมตามคีย์และช่วงเวลา สำหรับทีมที่รันเอเจนต์จำนวนมาก นั่นคือความต่างระหว่าง "เดือนที่แล้วเราใช้กับ LLM ไปสี่พันดอลลาร์" กับ "ไปป์ไลน์รีวิวบนบริการ auth ใช้ไปสี่พันดอลลาร์เดือนที่แล้ว นี่คือรายละเอียดแยกตามคีย์"
การแบ่งงานชัดเจน:
- octolib คือไลบรารีที่รู้วิธี คุย กับผู้ให้บริการแต่ละราย — รูปแบบคำขอ การ parse คำตอบ ตารางต้นทุน
- OctoHub คือพร็อกซีที่อยู่หน้าผู้ให้บริการและตัดสินว่าคำขอ ไปโดน รายใด บันทึกมัน และวัดต่อคีย์
- Octomind คือเอเจนต์ที่ตัดสิน ต่อโรลและต่อเลเยอร์ ว่าจะส่ง สตริงโมเดลใด ตั้งแต่แรก
คุณรัน Octomind โดยไม่มีพร็อกซีเลยก็ได้ และกำหนดเส้นทางผ่านโรลและ OpenRouter ล้วน ๆ คุณเพิ่ม OctoHub เมื่ออยากได้การควบคุมแบบรวมศูนย์: ที่เดียวสำหรับหมุนคีย์ ปรับสมดุลทราฟฟิกใหม่ และดูว่าเงินไปไหน
ตารางสรุปการเลือกโมเดล
นี่คือที่ที่ผมจะวางโมเดลแต่ละประเภทจริง ๆ ปฏิบัติต่อชื่อโมเดลเฉพาะเป็นตัวอย่างปัจจุบัน ไม่ใช่บัญญัติ — โมเดลที่ถูกในไตรมาสนี้จะไม่ใช่โมเดลที่ถูกในไตรมาสหน้า แต่ รูปร่าง ของการตัดสินใจยังคงอยู่
| งานในเอเจนต์ | ประเภทโมเดล | ตัวอย่างรูปธรรม | ทำไม |
|---|---|---|---|
| รีวิวขั้นสุดท้าย การตัดสินใจออกแบบที่ยาก diff ใกล้ auth | แนวหน้า | anthropic:claude-opus-4-8 |
คุณภาพคุ้มราคาในส่วน 10% ที่สำคัญ |
| ลูปพัฒนาหลัก | แข็งแกร่ง มีแคช | anthropic:claude-sonnet-5 |
โค้ดดิ้งดี + แคช prompt ทำให้ต้นทุนสมเหตุสมผล |
| ค้นคว้า / กวาดคอนเท็กซ์ | คอนเท็กซ์ใหญ่ ราคาถูก | openrouter:google/gemini-3.5-flash |
อ่านไฟล์เยอะ ไม่ต้องเก่งเป็นเลิศ |
| ปรับงาน | เล็ก เร็ว | openrouter:openai/gpt-5.4-mini |
จัดระเบียบคำขอที่คลุมเครือ — งานเล็กน้อย |
| การตัดสินใจบีบอัด | เล็ก ราคาถูก | openai:gpt-5-mini |
ยิงตลอด อย่าใช้โมเดลแนวหน้าตรงนี้เด็ดขาด |
| ลดทอนเซสชัน / สรุป | ให้เหตุผลขนาดเล็ก | openrouter:openai/gpt-5-mini |
สรุปแบบมีโครงสร้าง รันบ่อย |
| ปริมาณมาก / สูง / เป็นส่วนตัว | โลคัล | ollama:glm-5, cli:codex/gpt-5.2-codex |
ความหน่วง + ความเป็นส่วนตัว + ต้นทุนต่อโทเค็นเป็นศูนย์ |
| คลาวด์สำรองประหยัด | เนทีฟราคาถูก | deepseek:deepseek-chat |
ต้นทุนต่ำสุดเมื่อยังต้องใช้ API จริง |
กฎใต้ตาราง: ใช้จ่ายกับการเรียกตามสัดส่วนที่คุณภาพเอาต์พุตเปลี่ยนผลลัพธ์ การรีวิวไม่จับบั๊กก็ไม่จับ — ใช้จ่ายตรงนั้น รายชื่อไฟล์กลับมาเหมือนกันจากโมเดลใดก็ตาม — อย่าใช้จ่าย
คอนฟิกหลายโมเดลฉบับสมบูรณ์
ประกอบทุกอย่างเข้าด้วยกัน นี่คือคอนฟิกที่กระจายงานข้ามสี่โมเดล — ค่าเริ่มต้นราคาถูก รีวิวเวอร์ที่แข็งแกร่ง รีเสิร์ชเชอร์ในเครื่อง และการตัดสินใจบีบอัดราคาถูก — บวกเพดานการใช้จ่ายแบบแข็งเพื่อให้ลูปที่หลุดการควบคุมไม่ทำให้คุณตกใจ:
# ค่าเริ่มต้นที่ถูกและมีความสามารถ กำหนดเส้นทางผ่านคีย์ OpenRouter เดียว
model = "openrouter:anthropic/claude-sonnet-5"
# เพดานแข็ง — บังคับใช้ ไม่ใช่แค่คำแนะนำ
max_request_spending_threshold = 0.50 # USD ต่อคำขอ หยุดการทำงาน
max_session_spending_threshold = 5.00 # USD ต่อเซสชัน ถาม/หยุด
# การบีบอัดรันบนโมเดลราคาถูก แยกจากตัวหลัก
[compression.decision]
model = "openai:gpt-5-mini"
max_tokens = 16000
temperature = 0.3
# โมเดลโลคัลสำหรับเฟสสำรวจปริมาณมาก
[[roles]]
name = "researcher"
model = "ollama:glm-5"
temperature = 0.3
top_p = 0.7
top_k = 20
system = "You gather context and report findings. You do not modify files."
welcome = ""
[roles.mcp]
server_refs = ["filesystem"]
allowed_tools = ["view"]
# โมเดลแนวหน้าสำหรับงานที่คุ้มค่า
[[roles]]
name = "reviewer"
model = "anthropic:claude-opus-4-8"
temperature = 0.2
top_p = 0.7
top_k = 20
system = "You review changes for correctness, security, and edge cases."
welcome = "Reviewer ready."
[roles.mcp]
server_refs = ["filesystem"]
allowed_tools = ["view", "ast_grep"]
ตรวจสอบความถูกต้องก่อนเชื่อใจมัน:
octomind config --validate
octomind config --show # confirms which provider keys were detected
จากนั้นรันเส้นทางราคาถูกเป็นค่าเริ่มต้น และเรียกตัวแพงเฉพาะเมื่อคุณตั้งใจ:
octomind run researcher # local model, free per token
octomind run reviewer # frontier model, on purpose
octomind run -m deepseek:deepseek-chat # one-off override for a session
ดูว่ามันมีต้นทุนจริงเท่าไรด้วย /info สำหรับภาพรวมเซสชัน และ /report สำหรับรายละเอียดต่อคำขอ ครั้งแรกที่คุณรันงานจริงแบบนี้แล้วเห็นว่าเฟสค้นคว้าไม่เสียอะไรเลยขณะที่การรีวิวเสียไม่กี่เซนต์ การแบ่งงานจะหยุดเป็นแค่ทฤษฎี
อะไรเปลี่ยนไปหลังแบ่งงาน
บ่ายราคา 312 ดอลลาร์ไม่เกิดขึ้นอีกแล้ว และไม่ใช่เพราะเราใช้เอเจนต์น้อยลง ทราฟฟิกค้นคว้าและปรับงานย้ายไปยังโมเดลราคาถูกและโมเดลโลคัล การตัดสินใจบีบอัดเลิกขี่โมเดลแนวหน้า และโมเดลราคาแพงตอนนี้โผล่มาเฉพาะการรีวิวและการตัดสินใจที่ยากจริง ๆ สัดส่วนของโมเดลแนวหน้าในจำนวนการเรียกทั้งหมดลดลงเหลือราว ๆ สิบเปอร์เซ็นต์ที่มันควรเป็นมาตลอด
อาการค้างจากลิมิตอัตราคำขอก็หายไปด้วย ซึ่งผมไม่ได้คาดไว้ การกระจายทราฟฟิกข้ามผู้ให้บริการ — บางส่วนผ่าน OpenRouter บางส่วนตรง บางส่วนในเครื่อง บางส่วนหลังการแมปสุ่มเลือกของ OctoHub — หมายความว่า 429 ของผู้ให้บริการรายเดียวไม่หยุดทั้งเซสชัน เอเจนต์ที่เคยค้างอยู่กับลิมิตอัตราของ upstream รายหนึ่งตอนนี้แค่กำหนดเส้นทางอ้อมมันไป
ไม่มีสิ่งใดในนี้ต้องการเฟรมเวิร์ก ไลบรารีกำหนดเส้นทาง หรือโค้ดออร์เคสเตรชัน มันคือสตริง provider:model ใน TOML โรลพิเศษไม่กี่ตัว และโมเดลบีบอัดราคาถูกหนึ่งตัว ส่วนที่ยากไม่ใช่การเดินสาย — octolib และ Octomind มีมันครบอยู่แล้ว ส่วนที่ยากคือการเปลี่ยนกรอบคิด: เลิกจ่ายราคาระดับแนวหน้าให้งานหนักซ้ำซาก และวางโมเดลที่ดีที่สุดของคุณเฉพาะตรงที่คุณภาพเอาต์พุตเปลี่ยนสิ่งที่จะเกิดขึ้นต่อไปจริง ๆ
ถ้าคุณกำลังห่อเครื่องมือเฉพาะโปรเจกต์ให้เอเจนต์เหล่านี้ด้วย รูปแบบ custom MCP ในรีโปของคุณ ประกอบเข้ากับโรลหลายโมเดลได้อย่างสะอาด — เครื่องมือที่แคบและโมเดลขนาดพอดีดึงไปในทิศทางเดียวกัน
คำถามที่พบบ่อย
ผมต้องใช้ OpenRouter ไหม หรือใช้ผู้ให้บริการโดยตรงได้?
ได้ทั้งสองอย่าง OPENROUTER_API_KEY เดียวให้คุณเข้าถึงแคตตาล็อกเกือบทั้งหมดผ่านพรีฟิกซ์ openrouter: ซึ่งเริ่มได้ง่ายสุด หรือตั้งคีย์แยก (ANTHROPIC_API_KEY, DEEPSEEK_API_KEY, …) แล้วใช้พรีฟิกซ์เนทีฟ คุณผสมทั้งสองในคอนฟิกเดียวได้ — โรลต่าง ๆ ไปโดนผู้ให้บริการที่ต่างกันโดยสิ้นเชิงได้
ผมสลับโมเดลโดยไม่แก้คอนฟิกได้อย่างไร?
ต่อการรัน: octomind run -m anthropic:claude-sonnet-5 กลางเซสชัน: /model deepseek:deepseek-chat แฟล็ก CLI ชนะโมเดลของโรลและคอนฟิก คำสั่งสแลชสลับเซสชันสด ๆ และบันทึกมัน
โมเดลถูกตัดสินที่ไหนกันแน่?
ลำดับการแก้ปัญหาคือ CLI --model > role.model > config.model โดยมีการแทนที่ [taps] เสียบเข้าที่ระดับ config.model สำหรับเอเจนต์ tap ตั้ง config.model ค่าเริ่มต้นที่เหมาะสม แล้วแทนที่ต่อโรลสำหรับงานที่สมควรได้โมเดลที่ต่างออกไป
ขั้นตอนต่าง ๆ ของงานเดียวใช้โมเดลต่างกันได้ไหม?
ได้ — นั่นคือสิ่งที่เลเยอร์มีไว้ เลเยอร์อ้างอิงโรล โรลพาโมเดล ดังนั้นห่วงโซ่ของเลเยอร์จึงรันห่วงโซ่ของโมเดล โมเดลราคาถูกรวบรวมคอนเท็กซ์ โมเดลแข็งแกร่งให้เหตุผลกับมัน ทั้งหมดในโฟลว์เดียว
โมเดลโลคัลจะทำให้การติดตามต้นทุนพังไหม?
ไม่ โมเดลฟรีหรือราคาศูนย์ถูกจัดการอย่างชัดเจน: การติดตามต้นทุนรายงานเป็นศูนย์ และตัวเครื่องบีบอัดบีบอัดเสมอสำหรับโมเดลแบบนั้น (เพราะเกตต้นทุนไม่มีผล) เพื่อให้คอนเท็กซ์ยังจัดการได้
OctoHub เพิ่มอะไรที่โรลไม่มี?
โรลกำหนดเส้นทางในคอนฟิกของคุณ OctoHub กำหนดเส้นทางที่พร็อกซี มันแมปชื่อแทนหนึ่งไปยังแบ็กเอนด์จริงหลายตัวพร้อมการกระจายโหลดแบบสุ่ม บันทึกทุกคำขอ ออกคีย์ API ต่อคีย์สำหรับการติดตามการใช้งานแบบหลายผู้เช่า และรวมการวิเคราะห์ คุณต้องการมันเมื่อทีมต้องการที่เดียวเพื่อปรับสมดุลทราฟฟิกใหม่และคิดบัญชีค่าใช้จ่าย
ประเด็นไม่เคยเป็น "ใช้โมเดลที่ถูกกว่า" มันคือ "ใช้โมเดลที่ ถูกต้อง สำหรับการเรียกแต่ละครั้ง และให้การกำหนดเส้นทางเป็นคอนฟิก ไม่ใช่โค้ด" Octomind ยื่นตะเข็บให้คุณ — ค่าเริ่มต้นที่ราก ต่อโรล ต่อเลเยอร์ ต่อการรัน บวกพร็อกซีด้านล่าง — และสตริง provider:model เดียวร้อยทั้งหมดเข้าด้วยกัน
ใช้จ่ายโมเดลที่ดีที่สุดของคุณตรงที่คำตอบสำคัญจริง ๆ ปล่อยให้ที่เหลือรันราคาถูก
— Don
Octomind เป็นโอเพนซอร์สภายใต้ Apache-2.0 และ octolib กับ OctoHub ก็เช่นกัน การกำหนดเส้นทางหลายโมเดลคือคอนฟิก ไม่ใช่ปลั๊กอิน — ถ้าผู้ให้บริการที่คุณต้องการขาดไป มันจะลงใน octolib และโผล่ใน Octomind โดยอัตโนมัติ เปิด issue ถ้ามีอะไรในนี้ที่ไม่ตรงตามจริง
