Gemini 4 Carbon และ Hydrogen ทำงานร่วมกันได้ดีที่สุดเมื่อจับคู่กัน: Carbon วางแผน ส่วน Hydrogen ลงมือสร้าง เพียงมอบหมาย Task ให้กับ Agent ฝั่งวางแผนที่รันบน Carbon ให้เขียนงานย่อยพร้อมเงื่อนไขการตรวจสอบเพื่อยอมรับงาน ส่งต่องานเหล่านั้นให้ Agent ฝั่งปฏิบัติงานและตรวจสอบที่รันบน Hydrogen และหากมีงานใดที่ล้มเหลวซ้ำสองครั้ง ก็ส่งกลับไปยังผู้วางแผน วิธีนี้จะทำให้คุณจ่ายค่าบริการในเรตโมเดลระดับแนวหน้าเฉพาะในเทิร์นที่ต้องอาศัยการตัดสินใจขั้นสูงเท่านั้น
ทำไมต้องจับคู่ Gemini 4 Carbon กับ Hydrogen
Google เปิดตัว Gemini 4 Hydrogen เมื่อวันที่ 12 พฤศจิกายน 2026 โดยขนานนามว่าเป็น “เครื่องมือคู่ใจสำหรับเวิร์กโฟลว์ของ Agent” และก่อนหน้านั้นเพียงสองวัน ในวันที่ 10 พฤศจิกายน หน้า Gemini API changelog ก็ได้ประกาศสถานะ GA ให้กับ Gemini 4 Carbon ทำให้ในเดือนนี้เป็นครั้งแรกที่คุณสามารถใช้งานทั้งโมเดลที่ทรงพลังที่สุดและโมเดลที่ทำงานได้รวดเร็วที่สุดของ Google ร่วมกันใน Task เดียวกันได้
Google เองก็ชูจุดเด่นของ Hydrogen ด้วยการจับคู่ดังกล่าว โดยใน บล็อกโพสต์เปิดตัว ระบุว่า Carbon สามารถทำหน้าที่เป็นผู้ประสานงานหลัก ในขณะที่ Hydrogen ทำหน้าที่ขับเคลื่อน “Agent ฝั่งปฏิบัติงานและตรวจสอบ เพื่อสร้างและทดสอบการเปลี่ยนแปลงไปพร้อมๆ กันในพื้นที่ทำงานที่แยกจากกัน” ส่วนใน คู่มือ Gemini API อธิบายให้เห็นภาพชัดเจนขึ้นว่า ให้ใช้ Carbon ออกแบบอินเทอร์เฟซหรือแก้ปัญหาคอขวดที่ยากๆ แล้วส่งต่องานแก้ไขโค้ด งานย่อยของ Subagent แบบขนาน ตลอดจนการรันชุดทดสอบให้ Hydrogen จัดการ
นี่คือรูปแบบการประสานงาน ไม่ใช่แค่ฟีเจอร์ของตัวโมเดล และคุณสามารถนำมาปรับใช้บนบอร์ดการทำงานของคุณเองได้ตั้งแต่วันนี้ หากคุณต้องการให้บอร์ดทำหน้าที่จัดการรูปแบบนี้แทนการรันสคริปต์บนแล็ปท็อปเครื่องเดียว Sharkly คือแพลตฟอร์มที่รวบรวมทั้ง Tasks, Agents และกระบวนการตรวจสอบทั้งหมดไว้ด้วยกัน
สรุปการทำงานของ Google Orchestrator ในย่อหน้าเดียว
Orchestrator คือตัวเลือกโมเดลภายใน Google Antigravity ที่สลับการทำงานระหว่างผู้วางแผน (Carbon หรือ Argon) กับ Hydrogen ภายในการสนทนาเดียวกัน จากข้อมูลใน เอกสาร Antigravity ผู้วางแผนจะเริ่มด้วยขั้นตอนการอ่านข้อมูลเพียงอย่างเดียว จากนั้นร่างแผนการทำงานพร้อมระบุเงื่อนไขการวางแผนใหม่ไว้อย่างชัดเจน แล้วส่งไม้ต่อให้ Hydrogen ลงมือปฏิบัติการ โดย Hydrogen จะส่งการควบคุมกลับมาเมื่อพบปัญหาติดขัด
เอกสารได้ระบุสัญญาณปัญหาติดขัด 3 ข้อที่น่าหยิบยกมาประยุกต์ใช้:
- ขั้นตอนการตรวจสอบล้มเหลวซ้ำสองครั้ง
- อินเทอร์เฟซทำงานไม่ตรงกับที่คาดการณ์ไว้ในแผน
- การตัดสินใจเชิงออกแบบที่แผนเดิมไม่ได้ระบุไว้ชัดเจน
Google รายงานว่าบนชุดทดสอบ Terminal-Bench นั้น Orchestrator ทำอัตราความสำเร็จของงานได้ใกล้เคียงกับ Carbon แต่ใช้โควตาลดลงถึง 24% และทำงานเสร็จเร็วขึ้นเฉลี่ย 19% ทั้งนี้ บล็อกโพสต์ทั้งสองของ Google ระบุเวอร์ชันของชุดทดสอบไม่ตรงกัน (บล็อกเปิดตัวระบุเวอร์ชัน 4.0 ขณะที่โพสต์ของ Antigravity ระบุ 4.1) ดังนั้นจึงควรอ้างอิงแบบกว้างๆ ว่า Terminal-Bench ไปก่อนจนกว่า Google จะแก้ไขข้อมูลให้ตรงกัน
Orchestrator จะใช้ Agent เพียงตัวเดียวในการสนทนาของคุณ รันด้วยการกำหนดค่าตายตัวโดยไม่สามารถปรับแต่งระดับการคิดได้ และในรูปแบบที่ใช้ Carbon นั้นมีให้ใช้งานเฉพาะบน Google AI Ultra เท่านั้น แต่การใช้บอร์ดการทำงานของทีมจะกระจายการแบ่งบทบาทนี้ไปยัง Agent หลายตัว ทำให้ทุกคนมองเห็นทั้งแผนงานและขั้นตอนการส่งต่องานได้อย่างโปร่งใส
ประเด็นด้านต้นทุน: เปรียบเทียบราคา Gemini 4 Hydrogen กับ Carbon
ราคาโทเค็นจาก หน้าราคาของ Gemini API ณ วันที่ 13 พฤศจิกายน 2026:
| โมเดล | API model id | ขาเข้า / 1 ล้านโทเค็น | ขาออก / 1 ล้านโทเค็น | แผนใช้งานฟรี |
|---|---|---|---|---|
| Gemini 4 Carbon | gemini-4-carbon |
$2.00 จนถึง 30 พ.ย. จากนั้น $4.00 | $10.00 จนถึง 30 พ.ย. จากนั้น $20.00 | ไม่มี |
| Gemini 4 Hydrogen | gemini-4-hydrogen |
$1.50 | $7.50 | มี (จำกัดอัตราการเรียกใช้) |
โปรดตรวจสอบวันที่ให้ดีก่อนนำตัวเลขไปคำนวณงบประมาณ เพราะจนถึงวันที่ 30 พฤศจิกายน Hydrogen จะมีราคาต่อโทเค็นถูกกว่า Carbon เพียง 25% เท่านั้น แต่ตั้งแต่วันที่ 1 ธันวาคมเป็นต้นไป จะถูกกว่าถึง 62.5% โดยทั้งสองตัวเลขเป็นการคำนวณจากราคาประกาศของ Google
เพื่อให้เห็นภาพชัดเจนขึ้น ลองมาดูตัวอย่างการคำนวณต่อหนึ่งรอบการทำงาน: สมมติว่าในเทิร์นของ worker ต้องอ่านข้อมูล 200k โทเค็น และเขียนออกมา 40k โทเค็น (ผลลัพธ์ขาออกนับรวม thinking tokens ด้วย) หากรันบน Carbon หลังวันที่ 1 ธันวาคม ค่าใช้จ่ายจะอยู่ที่ $0.80 + $0.80 = $1.60 แต่หากรันบน Hydrogen จะอยู่ที่ $0.30 + $0.30 = $0.60 หากรันเช่นนี้วันละ 30 ครั้งตลอดทั้ง Sprint ส่วนต่างที่ประหยัดได้ก็จะไม่ใช่แค่เศษเงินอีกต่อไป
ราคาต่อโทเค็นยังสะท้อนความต่างได้ไม่หมด เพราะ Google ระบุว่า Carbon “ใช้ thinking tokens ต่อเทิร์นมากกว่าเพื่อทดสอบสมมติฐานและตรวจสอบกรณีขอบเขต” ซึ่งราคาขาออกก็นับรวมโทเค็นการคิดนี้ด้วย ดังนั้น งานแก้ไขแบบเดียวกันเมื่อรันบน Carbon จึงมักจะคิดเงินจากจำนวนโทเค็นขาออกที่มากกว่า ควบคู่ไปกับอัตราค่าบริการที่สูงกว่าด้วย ทั้งนี้ Google ไม่ได้เผยแพร่ตัวเลขต้นทุนเฉลี่ยต่อ Task สำหรับการใช้งานร่วมกัน คุณจึงควรทดสอบวัดผลบน Repository ของคุณเองก่อนจะสรุปตัวเลขส่วนต่างที่ประหยัดได้
ความเร็วคืออีกหนึ่งจุดเด่นที่สำคัญ: Google รายงานว่า Hydrogen ทำงานเสร็จเร็วกว่า Gemini 3.8 Flash ถึง 2.5 เท่าที่ระดับเริ่มต้น high
แบ่งงานในทีม Agent: จับคู่บทบาทหน้าที่ให้ตรงกับโมเดล
การแบ่งบทบาทระหว่างผู้วางแผนและผู้ปฏิบัติงานคือการแบ่งหน้าที่ความรับผิดชอบอย่างชัดเจน: Agent ตัวหนึ่งรับผิดชอบการวางแผนและการตัดสินใจที่ซับซ้อน ขณะที่ Agent ซึ่งมีต้นทุนต่ำกว่ารับผิดชอบการลงมือทำ และมี verifier คอยตรวจผลลัพธ์ก่อนส่งให้คนตรวจสอบ แต่ละบทบาทจะใช้โมเดลที่มีต้นทุนและขีดความสามารถเหมาะสมกับงานนั้นๆ
| บทบาท | โมเดล | ระดับการคิด (Thinking level) | หน้าที่รับผิดชอบ |
|---|---|---|---|
| ผู้วางแผน (Planner) | gemini-4-carbon |
ค่าเริ่มต้น medium, high สำหรับ Task ยากๆ |
อ่าน codebase, เขียน sub-tasks พร้อม acceptance checks, วางแผนใหม่เมื่อจำเป็น |
| ผู้ปฏิบัติงาน (Worker 1 ถึง n) | gemini-4-hydrogen |
high (ค่าเริ่มต้น) |
แก้ไขโค้ด, อัปเดตแพ็กเกจ, ทดสอบ, รับผิดชอบคนละหนึ่ง sub-task |
| ผู้ตรวจสอบ (Verifier) | gemini-4-hydrogen |
high, xhigh สำหรับ diff ที่มีความเสี่ยงสูง |
รันการตรวจสอบตามเกณฑ์ acceptance criteria ที่ผู้วางแผนกำหนดไว้ |
| บุคคล (Person) | n/a | n/a | อนุมัติแผนงานสำหรับ Task ใหญ่, ตรวจรับผลงานขั้นสุดท้าย |
ตารางนี้อิงตามรายละเอียดสองประการจากเอกสารของ Google: ประการแรก Carbon และ Argon มีค่าเริ่มต้นที่ medium และปรับได้สูงสุดที่ high ในขณะที่ Hydrogen มีค่าเริ่มต้นที่ high และเพิ่มระดับ xhigh เข้ามา ประการที่สอง Google เตือนว่า xhigh จะเพิ่มความหน่วงและปริมาณการใช้โทเค็น ทั้งยัง “อาจทำให้โมเดลคิดซับซ้อนเกินจำเป็นเมื่อเจอกับพรอมต์ที่ไม่ซับซ้อน” ดังนั้นควรเก็บ xhigh ไว้ใช้สำหรับ verifier เมื่อต้องตรวจสอบ diff ที่แตะระบบยืนยันตัวตน, ระบบชำระเงิน หรือการย้ายข้อมูล
ผู้วางแผนควรเขียนอะไรบ้าง?
ผลลัพธ์ของผู้วางแผนเปรียบเสมือนข้อตกลงสำหรับทุกคนในขั้นตอนถัดไป แผนงานที่ดีต้องมีหนึ่ง sub-task ต่อหนึ่งการเปลี่ยนแปลงที่เป็นอิสระจากกัน, ขอบเขตไฟล์ที่ต้องแก้ไข, คำสั่งที่ใช้พิสูจน์ว่างานใช้ได้จริง และเงื่อนไขที่จะส่งงานกลับคืน ถ้า worker ไม่รู้ว่าเมื่อใดที่ถือว่างานเสร็จสิ้น นั่นแปลว่าแผนยังไม่สมบูรณ์
เมื่อใดที่ต้องส่งงานกลับไปให้ผู้วางแผน?
นำรายการทริกเกอร์ของ Google มากำหนดให้ชัดเจน โดย worker จะส่งคืน sub-task เมื่อการตรวจสอบล้มเหลวซ้ำสองครั้ง, เมื่ออินเทอร์เฟซไม่ตรงกับที่ระบุไว้ในแผน หรือเมื่อต้องมีการตัดสินใจเชิงออกแบบ โดยจะส่งคืนพร้อมกับ log, diff ของโค้ดที่ทำไปแล้ว และคำถามที่ต้องการคำตอบ และต้องไม่มีการแอบลองใหม่เงียบๆ บนโมเดลขนาดใหญ่ เพราะการทำเช่นนั้นจะบดบังต้นทุนที่แท้จริงของระดับราคาประหยัดให้อยู่ในบิลของโมเดลราคาแพง
วิธีตั้งค่าใน Sharkly
ใน Sharkly ตัว Agent คือเพื่อนร่วมทีม AI ที่ทำงานผ่าน Runtime บน Computer ที่เชื่อมต่อไว้ และ Crew คือกลุ่มของ Agent และบุคคลที่ประสานงานร่วมกันโดยมี Agent ผู้นำหนึ่งตัว ซึ่งสอดรับกับรูปแบบการแบ่ง planner/worker ได้พอดีโดยไม่ต้องเขียนโค้ดเชื่อมต่อใดๆ เพิ่มเติม โดยผู้วางแผนจะทำหน้าที่เป็นหัวหน้า Crew ส่วน worker และ verifier จะเป็นสมาชิกใน Crew
Agent แต่ละตัวจะมี Runtime และ Default model ของตัวเอง ดังที่แสดงในพาเนลด้านบน (ซึ่งตัวอย่างนั้นรัน Claude Code) สำหรับการตั้งค่านี้ ให้กำหนด Runtime ที่สามารถเชื่อมต่อกับ Gemini API ได้ให้แก่ Agent แต่ละตัว เช่น Gemini CLI แล้วกำหนดโมเดลแยกตาม Agent: เลือก Carbon ให้กับผู้วางแผน และ Hydrogen ให้กับตัวอื่นๆ หากรายชื่อโมเดลยังไม่แสดง ID ใหม่ ให้กำหนดโมเดลในการตั้งค่าของ Runtime เอง โดย Gemini CLI ยังรองรับตัวแปรสภาพแวดล้อม GEMINI_MODEL ตามที่ระบุใน configuration reference และ Agent ก็สามารถรับตัวแปรสภาพแวดล้อมเฉพาะตัวได้เช่นกัน
จากนั้น ให้เขียนกฎการประสานงานลงในคำสั่งของ Crew:
CREW: carbon-plans-hydrogen-builds
Leader: planner (gemini-4-carbon)
1. Read the Task and recent comments. Explore read-only first.
2. Post a plan as a comment: one sub-task per independent change,
file scope, the check command, and the re-plan trigger.
3. If the Task touches more than 3 modules, wait for a person to
approve the plan before mentioning any worker.
4. Mention one worker per sub-task. Mention the verifier last.
Workers: worker-a, worker-b (gemini-4-hydrogen, high)
- Do one sub-task. Run its check. Report the diff and the result.
- If the check fails twice, stop. Report the log and the question
to the leader. Do not widen scope.
Verifier: verifier (gemini-4-hydrogen, high; xhigh for auth/payments)
- Re-run every check from the plan. Pass or fail each one, with output.
A person accepts the result. Nobody merges on an Agent's word.
มอบหมาย Task ให้กับ Crew ขั้นตอนการทำงานจะเริ่มต้นจากผู้นำก่อนเสมอ ตามที่ระบุใน เอกสาร Crews: โดยผู้นำจะอ่าน Task และคำสั่งของ Crew จากนั้นแท็กเรียกสมาชิกเพื่อขอรับผลงานในส่วนที่เจาะจง และผลลัพธ์ของแต่ละคนจะถูกส่งกลับเข้ามาใน Task เดียวกันนี้ แนะนำให้ใช้ไดเรกทอรีทำงานชั่วคราวเพื่อให้ worker แต่ละตัวมี worktree แยกเป็นของตัวเอง และเปิดใช้งานไดเรกทอรี Task ที่แชร์ร่วมกันของ Crew เฉพาะในกรณีที่ sub-tasks จำเป็นต้องต่อยอดจากการเปลี่ยนแปลงในเครื่องของงานก่อนหน้าตามลำดับเท่านั้น
งานที่ติดขัดจะยังคงมองเห็นได้เสมอ: การรันที่ล้มเหลวหรือติดขัดจะถูกส่งไปยัง Inbox และ Agent ที่กำลังรอการตอบกลับจากคนจะปรากฏขึ้นใน Task Chats ที่แถบด้านข้าง นั่นคือปลายทางของเส้นประเมื่อผู้วางแผนไม่สามารถแก้ไขแผนงานได้ด้วยตัวเอง
เทคนิคขั้นสูง
ใช้ฟังก์ชันสลับโมเดลของ API สำหรับ Task ขนาดยาว เอกสารของ Google ระบุว่าคุณสามารถกำหนดให้เทิร์นการวางแผนวิ่งไปยัง gemini-4-carbon และเทิร์นการลงมือทำให้วิ่งไปยัง gemini-4-hydrogen ได้ภายในการทำงานแบบหลายเทิร์นเดียวกันโดยใช้ previous_interaction_id ได้โดยไม่ต้องแก้ไข schema ซึ่งเป็นการนำเคล็ดลับของ Orchestrator มาใช้ในโค้ดของคุณเอง เหมาะอย่างยิ่งสำหรับการรัน Agent เพียงตัวเดียว
คำนึงถึงขนาดของแต่ละรอบการตอบกลับ Hydrogen สามารถส่งผลลัพธ์กลับมาได้สูงสุดถึง 65,536 โทเค็นต่อหนึ่ง non-streaming hop ในขณะที่ Carbon และ Argon ส่งได้ 32,768 โทเค็นต่อหนึ่ง non-streaming REST hop ดังนั้นควรมอบหมายงานที่ต้องสร้างข้อมูลขนาดยาว เช่น ชุดทดสอบหรือข้อกำหนดการย้ายข้อมูล ให้อยู่ในฝั่ง worker
ไม่ต้องใช้ Explicit Caching บน Hydrogen Hydrogen ไม่รองรับการแคชบริบทแบบชัดแจ้ง แต่จะมี Implicit Caching สำหรับพรอมต์ที่มีความยาวอย่างน้อย 4,096 โทเค็นขึ้นไป และมอบส่วนลดสำหรับ input ที่แคชไว้ถึง 95% ดังนั้นจึงควรใส่บริบทของ repository ที่ใช้ร่วมกันไว้ที่ส่วนต้นของพรอมต์สำหรับ worker แต่ละตัวเสมอ
ทางเลือกอื่นนอกจากการแบ่งบทบาท Planner/Worker
- ใช้ Hydrogen เพียงอย่างเดียว: เอกสารของ Google แนะนำให้ใช้สำหรับงานอัปเกรดแพ็กเกจ, ลบโค้ดที่ซ้ำซ้อน, งานโครงสร้างโปรเจกต์, การเขียน unit test สำหรับฟังก์ชันที่มีข้อกำหนดชัดเจน และการเขียนเอกสาร โดยไม่จำเป็นต้องมีผู้วางแผน
- ใช้ Carbon เพียงอย่างเดียว: เหมาะสำหรับการออกแบบระบบแบบกระจาย, การจัดการ race conditions หรือการย้ายข้อมูลข้ามหลาย repository ซึ่งทุกขั้นตอนต้องอาศัยการคิดวิเคราะห์เชิงลึก
- Orchestrator ใน Antigravity: ใช้งานแบบคนเดียว สนทนาในหน้าต่างเดียว พร้อมการส่งต่องานอัตโนมัติ สำหรับแพ็กเกจที่รองรับฟีเจอร์นี้
- เราเตอร์แบบคงที่: จำแนกประเภท Task ตั้งแต่เริ่มต้นแล้วส่งไปยังโมเดลใดโมเดลหนึ่ง ซึ่ง Google ชี้ว่าวิธีนี้มักใช้ไม่ได้ผลกับงานที่รันยาวๆ เนื่องจากระดับความยากอาจเปลี่ยนแปลงระหว่างทาง เราเคยกล่าวถึงเวอร์ชันจำแนกล่วงหน้านี้ไว้ในบทความ การกำหนดเส้นทาง Task ของ AI Agent ด้วย Gemini Decisions API
กรณีการใช้งานจริงในทางปฏิบัติ
การคัดกรองและจัดการ Issue ปริมาณมาก ตัวอย่าง SDK ของ Google Antigravity มีการจับคู่ Agent ที่รันบน Hydrogen เพื่อคัดกรองและเขียนโค้ด ควบคู่กับ Agent ที่รันบน Carbon สำหรับการรีแฟกเตอร์โค้ด, พัฒนาฟีเจอร์ใหม่ และตรวจสอบความปลอดภัย ในการทำงานบนบอร์ด นั่นหมายถึงการวาง Hydrogen Agent ไว้รับคิวงานขาเข้า และให้ Carbon ทำหน้าที่เป็นหัวหน้าสำหรับงานใดก็ตามที่ติดป้ายกำกับว่า refactor หรือ security
การแบ่งฟีเจอร์ออกเป็นงานย่อยแบบขนาน ผู้วางแผนจะแบ่งการเปลี่ยนแปลง API ออกเป็นการอัปเดต schema, handler และ client โดยให้ worker สามตัวรันงานแยกกันใน worktree ของแต่ละตัว และ verifier ทำหน้าที่รัน contract tests ตรวจสอบความถูกต้อง
บทสรุป
Carbon วางแผน Hydrogen ลงมือทำ และคนเป็นผู้ตรวจรับงาน โครงสร้างราคาทำให้การแบ่งงานรูปแบบนี้คุ้มค่ายิ่งขึ้นตั้งแต่วันที่ 1 ธันวาคม เงื่อนไขการตรวจจับปัญหาช่วยป้องกันไม่ให้ความผิดพลาดในโมเดลราคาถูกกลายเป็นการลองใหม่ที่สิ้นเปลืองบนโมเดลราคาแพง และบอร์ดจะบันทึกทุกขั้นตอนการส่งต่องานไว้ใน Task ให้ทุกคนในทีมมองเห็นได้อย่างชัดเจน สำหรับภาพรวมของรูปแบบนี้ สามารถอ่านเพิ่มเติมได้ที่ AI agent orchestration คืออะไร และ กฎการกำหนดเส้นทางโมเดลสำหรับ Crews ของเรา
ขั้นตอนถัดไปของคุณ: เชื่อมต่อ Computer หนึ่งเครื่องเข้ากับ Sharkly สร้าง Agent ฝั่งวางแผนบน Carbon และ worker หนึ่งตัวบน Hydrogen จัดพวกมันเข้า Crew พร้อมใส่คำสั่งตามตัวอย่างด้านบน แล้วมอบหมาย Task ที่ปกติคุณอาจต้องใช้เวลาของคนสักครึ่งวันในการทำ ทั้งนี้ Sharkly มีแผนใช้งานฟรี ค่าใช้จ่ายในการทดสอบจึงมีเพียงค่าโทเค็นของ Gemini เท่านั้น
คำถามที่พบบ่อย (FAQ)
Gemini 4 Carbon และ Hydrogen แตกต่างกันอย่างไร?
Carbon คือโมเดลระดับแนวหน้าที่ทรงพลังที่สุดของ Google สร้างขึ้นเพื่อการใช้เหตุผลในงานระยะยาว งานสถาปัตยกรรมระบบที่ซับซ้อน การดีบัก และงานความปลอดภัย ส่วน Hydrogen เป็นโมเดลในตระกูล Gemini 4 ที่รวดเร็วและเปี่ยมประสิทธิภาพ ออกแบบมาสำหรับการเขียนโค้ดในชีวิตประจำวันและการรัน Agent โดย Carbon มีระดับการคิดเริ่มต้นที่ medium และสูงสุดที่ high ส่วน Hydrogen มีค่าเริ่มต้นที่ high และมีระดับ xhigh เพิ่มเข้ามา
Gemini 4 Hydrogen มีราคาถูกกว่า Carbon หรือไม่?
ถูกกว่า โดย Hydrogen มีราคาอยู่ที่ $1.50 ต่อ 1 ล้านโทเค็นขาเข้า และ $7.50 ต่อ 1 ล้านโทเค็นขาออก ส่วน Carbon มีราคาอยู่ที่ $2 และ $10 จนถึงวันที่ 30 พฤศจิกายน 2026 จากนั้นจะปรับเป็น $4 และ $20 ตั้งแต่วันที่ 1 ธันวาคม นอกจากนี้ Hydrogen ยังมีแผนใช้งานฟรีแบบจำกัดอัตราการเรียกใช้บน Gemini API ขณะที่ Carbon ไม่มี
ควรให้ Verifier รันบน Carbon แทน Hydrogen หรือไม่?
ไม่จำเป็นโดยค่าเริ่มต้น เนื่องจาก Google วางตำแหน่งของ Hydrogen ไว้สำหรับ Agent ฝั่ง worker และ verifier ที่ทำงานแบบขนานอยู่แล้ว แนะนำให้ใช้ระดับ xhigh บน verifier สำหรับ diff ที่มีความเสี่ยงสูง และส่งต่อ Task กลับไปให้ผู้วางแผนบน Carbon เฉพาะเมื่อการตรวจสอบล้มเหลวซ้ำสองครั้ง
Sharkly จะเลือกโมเดลให้โดยอัตโนมัติในแต่ละ Task หรือไม่?
ไม่ Sharkly ไม่ได้เลือกให้ คุณเป็นผู้กำหนดโมเดลของแต่ละ Agent ผ่าน Runtime ของมันเอง และคำสั่งของ Crew จะเป็นตัวกำหนดว่า Agent ตัวใดจะได้รับมอบหมายส่วนใดของ Task โดยที่ Sharkly จะทำหน้าที่จัดการตัว Task, การรันงาน, การส่งต่องาน และขั้นตอนการตรวจสอบ
