# เอเจนต์ AI ตัวเดียวบนหลายโมเดล: คู่มือการกำหนดเส้นทางแบบหลายโมเดลสำหรับ Octomind > ใช้โมเดลเดียวทำทุกอย่างแล้วแพงและติดลิมิตอัตราคำขอ นี่คือวิธีที่เรากำหนดเส้นทางคำขอระหว่าง LLM ภายในเอเจนต์ Octomind ตัวเดียว — โมเดลราคาถูกสำหรับงานหนักที่ซ้ำซาก โมเดลระดับแนวหน้าสำหรับการเรียกที่สำคัญ — พร้อมคีย์คอนฟิกจริง รายชื่อผู้ให้บริการ และตารางสรุปการเลือกโมเดล บิลที่จุดชนวนเรื่องนี้คือ 312 ดอลลาร์ในบ่ายวันเดียว นักพัฒนาคนเดียว เซสชัน Octomind หนึ่งเซสชัน โมเดลตัวเดียวทำทุกงาน: อ่านไฟล์ รัน grep สรุป diff ตัดสินใจว่าจะบีบอัดคอนเท็กซ์เมื่อไร และทำการให้เหตุผลที่ยากจริง ๆ ทั้งหมดนั้นบนโมเดลระดับแนวหน้า เพราะนั่นคือสิ่งที่คุณเอื้อมไปหยิบเมื่ออยากให้เอเจนต์เก่ง แล้ว OpenRouter ก็เริ่มคืนค่า 429 กลางการรีแฟกเตอร์ และผมก็เฝ้าดูเอเจนต์ค้างอยู่กับลิมิตอัตราคำขอขณะทำสิ่งที่โมเดลราคาถูกกว่าสิบเท่าก็ทำได้สมบูรณ์แบบ นั่นคือจังหวะที่สิ่งที่เห็นได้ชัดเข้าที่: **สิ่งที่เอเจนต์ทำส่วนใหญ่ไม่ได้ยาก** การไล่รายชื่อไฟล์ไม่ยาก การปรับงานที่คลุมเครือให้ชัดขึ้นไม่ยาก การตัดสินใจว่าเซสชันใหญ่พอจะบีบอัดหรือยังไม่ยาก การอ่านกองข้อมูลจากการค้นคว้าแล้วดึงสามไฟล์ที่เกี่ยวข้องออกมาไม่ยาก คุณไม่ต้องใช้โมเดลที่ดีที่สุดของคุณกับสิ่งใดในนั้นเลย คุณต้องใช้มันสำหรับสักสิบเปอร์เซ็นต์ของการเรียก — การรีวิว การตัดสินใจออกแบบที่ยุ่งยาก diff ที่แตะ authentication อีกเก้าสิบเปอร์เซ็นต์เป็นงานหนักซ้ำซาก และงานหนักซ้ำซากคือที่ที่โมเดลราคาถูกและโมเดลโลคัลเปล่งประกายพอดี นี่คือเรื่องราวของการกระจายเอเจนต์ Octomind ตัวเดียวไปยังหลายโมเดล โดยยึดกับคีย์คอนฟิกจริงที่มันมาพร้อมตัว พอจบ คุณจะมีการตั้งค่าแบบหลายโมเดลที่ใช้งานได้ ตารางสรุปการเลือกโมเดล และคำตอบที่ชัดเจนต่อคำถามที่สำคัญ: _เอาอะไรไปไว้ตรงไหน_ --- ## หนึ่งสตริง บนแบ็กเอนด์ใดก็ได้ Octomind คุยกับผู้ให้บริการทุกรายผ่านไลบรารีเดียว — [octolib](https://github.com/muvon/octolib) ซึ่งผม[เขียนถึงไปก่อนหน้านี้](/blog/octolib-the-engine-behind-our-ai-stack) สิ่งที่ octolib ให้คุณ สิ่งที่ทำให้ทั้งหมดนี้เป็นไปได้ คือทุกโมเดลถูกตั้งชื่อแบบเดียวกัน: สตริง `provider:model` ```toml 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 ของเอเจนต์: ```toml [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 และสิทธิ์เครื่องมือ — และโมเดล (ไม่บังคับ) ทุกเซสชันรันด้วยโรล โรลตัดสินว่าเอเจนต์ทำอะไรได้ _และ_ โมเดลใดเป็นคนทำ คอนฟิกที่มาพร้อมตัวก็ทำตามที่บทความนี้สั่งสอนอยู่แล้ว มันกำหนดสี่โรลธรรมดา และสามในนั้นจงใจรันบนโมเดลที่ถูกกว่าโมเดลหลัก — โดยตรงนี้ปรับสตริงโมเดลเป็นรุ่นปัจจุบันแล้ว: ```toml # การปรับคำขอแบบเบา ๆ — ทำงานคลุมเครือให้ชัดขึ้น ไม่มีเครื่องมือ [[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 ไม่ผ่าน: ```toml # คอนเท็กซ์กว้างราคาถูกสำหรับการกวาดดูโค้ดเบส [[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 และเครื่องมือไปด้วย ส่วนเลเยอร์บอกว่าบทสนทนาไหลเข้าและออกจากสเตจนั้นอย่างไร ฟิลด์มีไม่มากและฟิลด์โหมดทั้งหมดเป็นข้อบังคับ: ```toml [[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 ` — ดังนั้นคำสั่ง `reduce` ที่มาพร้อมตัวจึงเป็นเลเยอร์เองที่รันโรล `reduce` ราคาถูกเพื่อบีบอัดประวัติตามต้องการ แบบจำลองในใจ: โรลตอบ "โมเดลใดสำหรับ _เซสชัน_ นี้" เลเยอร์ตอบ "โมเดลใดสำหรับ _สเตจ_ นี้" รวมกันแล้วมันให้คุณกำหนดเส้นทางคำขอเดียวผ่านไปป์ไลน์ถูกแล้วแพงโดยไม่ต้องเขียนโค้ดออร์เคสเตรชัน — ทั้งหมดเป็น TOML > หมายเหตุ: รายการ `[[layers]]` ต้องมีโรลที่ตรงกันใน `[[roles]]` โมเดลอยู่ในโรล ไม่เคยอยู่ในเลเยอร์ ถ้าคุณพบว่าตัวเองอยากตั้งโมเดลบนเลเยอร์ สิ่งที่คุณกำลังมองหาคือโรล --- ## การบีบอัดมีโมเดลของตัวเอง — และมันควรราคาถูก ยังมีการเลือกโมเดลอีกอย่างที่พลาดได้ง่ายและคืนทุนทันที Octomind บีบอัดเซสชันยาวโดยอัตโนมัติ และการเรียกแบบตัดสินใจ-บวก-สรุปที่ขับเคลื่อนการบีบอัดรันบนโมเดลที่กำหนดค่าไว้ _ของมันเอง_ แยกจากตัวหลัก: ```toml [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:`: ```toml 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 บนเครือข่าย: ```toml model = "cli:codex/gpt-5.2-codex" ``` รูปแบบคือ `cli:/` โดย backend เป็นหนึ่งใน `codex`, `claude`, `cursor`, `gemini` หรือคำสั่งทั่วไป เนื่องจากมันรันผ่าน CLI ในเครื่อง **จึงไม่ต้องใช้คีย์ API** — Octomind ข้ามการตรวจสอบเครเดนเชียลทั้งหมดสำหรับโมเดล `cli:` พฤติกรรมปรับแต่งด้วยตัวแปรสภาพแวดล้อมเฉพาะ backend (สำหรับ backend codex คือ `CODEX_COMMAND`, `CODEX_REASONING_EFFORT` และพวกพ้อง) โมเดลโลคัลคุ้มค่าตรงไหน: งานปริมาณมากเดิมพันต่ำที่ความหน่วงและความเป็นส่วนตัวสำคัญกว่าคุณภาพไม่กี่แต้มสุดท้าย การสรุปจำนวนมาก การจัดหมวดหมู่ การค้นคว้ารอบแรก อะไรก็ตามที่คุณรันเป็นพัน ๆ ครั้ง ใส่โมเดลโลคัลบนโรล `researcher` แล้วเฟสสำรวจไม่เสียค่าใช้จ่ายต่อโทเค็นเลย เก็บโมเดลบนคลาวด์ไว้ที่โรล `reviewer` ที่ช่องว่างด้านคุณภาพเห็นได้จริง --- ## OctoHub: การกำหนดเส้นทางและการสำรองด้านล่าง จนถึงตอนนี้การกำหนดเส้นทางเป็นแบบต่อโรลและต่อเลเยอร์ ตัดสินในคอนฟิก Octomind ของคุณ แต่ยังมีชั้นด้านล่าง — พร็อกซีจริง — และนั่นคือที่ที่การสำรอง (fallback) การกระจายโหลด และการบัญชีแบบรวมศูนย์อาศัยอยู่ [OctoHub](https://github.com/muvon/octohub) คือพร็อกซี LLM โอเพนซอร์สของเรา สำหรับ Octomind มันก็แค่ผู้ให้บริการอีกราย: คุณตั้งโมเดลแบบ `octohub:my-model` ชี้ Octomind ไปยังเอนด์พอยต์ของ OctoHub แล้วจากฝั่ง Octomind มันก็เป็นสตริง `provider:model` อีกหนึ่งตัว สิ่งที่ OctoHub ทำเบื้องหลังสตริงนั้นคือที่ที่มันมีประโยชน์ คอนฟิกของมันแมปชื่อโมเดลสั้น ๆ ไปยัง _รายการ_ ของเป้าหมาย `provider:model` แบบเต็มรูปแบบ และสุ่มเลือกหนึ่งตัวต่อคำขอ: ```toml [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 จริง | กฎใต้ตาราง: **ใช้จ่ายกับการเรียกตามสัดส่วนที่คุณภาพเอาต์พุตเปลี่ยนผลลัพธ์** การรีวิวไม่จับบั๊กก็ไม่จับ — ใช้จ่ายตรงนั้น รายชื่อไฟล์กลับมาเหมือนกันจากโมเดลใดก็ตาม — อย่าใช้จ่าย --- ## คอนฟิกหลายโมเดลฉบับสมบูรณ์ ประกอบทุกอย่างเข้าด้วยกัน นี่คือคอนฟิกที่กระจายงานข้ามสี่โมเดล — ค่าเริ่มต้นราคาถูก รีวิวเวอร์ที่แข็งแกร่ง รีเสิร์ชเชอร์ในเครื่อง และการตัดสินใจบีบอัดราคาถูก — บวกเพดานการใช้จ่ายแบบแข็งเพื่อให้ลูปที่หลุดการควบคุมไม่ทำให้คุณตกใจ: ```toml # ค่าเริ่มต้นที่ถูกและมีความสามารถ กำหนดเส้นทางผ่านคีย์ 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"] ``` ตรวจสอบความถูกต้องก่อนเชื่อใจมัน: ```bash octomind config --validate octomind config --show # confirms which provider keys were detected ``` จากนั้นรันเส้นทางราคาถูกเป็นค่าเริ่มต้น และเรียกตัวแพงเฉพาะเมื่อคุณตั้งใจ: ```bash 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 ในรีโปของคุณ](/blog/custom-mcps-belong-in-your-repo) ประกอบเข้ากับโรลหลายโมเดลได้อย่างสะอาด — เครื่องมือที่แคบและโมเดลขนาดพอดีดึงไปในทิศทางเดียวกัน --- ## คำถามที่พบบ่อย **ผมต้องใช้ 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](https://github.com/muvon/octomind) เป็นโอเพนซอร์สภายใต้ Apache-2.0 และ [octolib](https://github.com/muvon/octolib) กับ [OctoHub](https://github.com/muvon/octohub) ก็เช่นกัน การกำหนดเส้นทางหลายโมเดลคือคอนฟิก ไม่ใช่ปลั๊กอิน — ถ้าผู้ให้บริการที่คุณต้องการขาดไป มันจะลงใน octolib และโผล่ใน Octomind โดยอัตโนมัติ [เปิด issue](https://github.com/muvon/octomind/issues) ถ้ามีอะไรในนี้ที่ไม่ตรงตามจริง_