คุณเริ่มต้นด้วย coding agent ตัวเดียว ตอนนี้ Claude Code รันอยู่ในเทอร์มินัลหนึ่ง Codex อยู่ในอีกอัน และ Gemini CLI ในอันที่สาม แต่ละตัวคิดค่าใช้จ่ายตามเงื่อนไขของตัวเอง มีทั้งแบบสมัครสมาชิก แบบใช้ API key คิดตามการใช้งานจริง และแบบ free tier ที่แอบเปลี่ยนเป็นแบบเสียเงินไปตั้งแต่สัปดาห์ที่แล้ว พอสิ้นเดือนคุณได้ใบแจ้งหนี้สามใบ แต่กลับตอบคำถามง่ายๆ ข้อเดียวไม่ได้ว่า ฟีเจอร์ที่ทำเมื่อสัปดาห์ที่แล้วมีต้นทุนจริงเท่าไหร่
Coding agent cost management คือแนวปฏิบัติในการระบุว่าเงินที่ใช้ไปกับ agent นั้นมาจากงานชิ้นไหน แล้วทำให้ค่าใช้จ่ายนั้นมองเห็นได้และตรวจสอบได้ตลอดทุกเครื่องมือที่ทีมของคุณใช้ ส่วนที่ยากไม่ใช่ราคาต่อ token ของ agent ตัวใดตัวหนึ่ง ราคาเปลี่ยนได้ และผู้ให้บริการแต่ละรายก็ประกาศราคาไว้อยู่แล้ว ส่วนที่ยากคือค่าใช้จ่ายแตกกระจายไปตามระบบ billing ที่แยกกันทันทีที่คุณใช้ agent มากกว่าหนึ่งตัว ทำให้ไม่มีใครโยงตัวเลขเงินเข้ากับงานหนึ่งชิ้น repo หนึ่งแห่ง หรือคนหนึ่งคนได้
บทความนี้จะพาคุณไปดูว่าต้นทุนของแต่ละเครื่องมือมาจากไหนจริงๆ มีคันโยกอะไรที่คุณควบคุมได้ และ management layer อย่าง Sharkly ทำให้ค่าใช้จ่ายต่อ task มองเห็นได้อย่างไรโดยไม่ต้องให้คุณเลิกใช้เครื่องมือที่มีอยู่แล้ว Sharkly วางตัวอยู่เหนือ agent คุณยังคงใช้ subscription ของ Claude Code, Codex และ Gemini ตามเดิม และบันทึกการรันแต่ละครั้งจะกลับไปอยู่ใน Task ที่มันเป็นส่วนหนึ่ง
Cost management หมายถึงอะไรเมื่อคุณใช้ agent สามตัว
ถ้าใช้ agent ตัวเดียว ต้นทุนก็เป็นแค่ตัวเลขที่อ่านได้จาก dashboard เดียว แต่พอใช้สามตัว ต้นทุนกลายเป็นปัญหาเรื่องการประสานงาน ค่าใช้จ่ายนั้นมีอยู่จริง แต่มันอยู่ในสามที่ที่ไม่เคยกระทบกันเลย ได้แก่ Claude Code usage ของ Anthropic, หน้า billing ของ OpenAI สำหรับ Codex และโปรเจกต์ Google Cloud สำหรับ Gemini
มีเส้นแบ่งที่ควรพูดให้ชัดตรงนี้ว่า Cost management ไม่เหมือนกับ cost reduction การลดค่าใช้จ่ายคือการใช้ token ให้น้อยลง ส่วนการบริหารค่าใช้จ่ายคือการรู้ว่า token ไปไหน แล้วตัดสินใจว่าคุ้มหรือไม่ คุณจะใช้จ่ายแพงในเดือนหนึ่งโดยตั้งใจก็ได้ เช่นการปล่อยสามฟีเจอร์พร้อมกัน แล้วยังคุมสถานการณ์ได้ ตราบใดที่คุณระบุได้ว่าเงินไปกับอะไร และมีคนอนุมัติมัน
การระบุที่มานั้นคือ layer ที่ขาดหายไป ทีมส่วนใหญ่ที่ใช้ agent หลายตัวบอกได้แค่ยอดบิล AI รวมทั้งหมด แต่บอกอะไรที่ละเอียดกว่านั้นไม่ได้เลย พวกเขาบอกไม่ได้ว่า repo ไหน วิศวกรคนไหน หรือ task ไหนที่เป็นตัวขับค่าใช้จ่าย พอค่าใช้จ่ายมองไม่เห็นในระดับ task การคุยเรื่องต้นทุนก็กลายเป็นการเดาสุ่ม และปฏิกิริยาที่ตามมามักจะเป็นการจำกัดเครื่องมือที่เห็นได้ง่ายที่สุด ไม่ใช่ตัวที่เผางบประมาณจริงๆ
ต้นทุนของเครื่องมือทั้งสามมาจากไหนจริงๆ
agent แต่ละตัวคิดเงินจากสิ่งที่คล้ายกัน คือ token ขาเข้าและ token ขาออก แต่รูปแบบ billing ต่างกันมากพอที่จะเปลี่ยนวิธีที่คุณตั้งงบประมาณ ถ้าเทียบกันตอนทำงานได้เต็มที่ ไม่มีตัวไหนถูกกว่าตัวอื่นแบบง่ายๆ ตรงๆ แต่ละตัวจะถูกกว่าสำหรับงานคนละรูปแบบ
| เครื่องมือ | รูปแบบ billing ที่พบบ่อย | อะไรทำให้บิลพุ่ง |
|---|---|---|
| Claude Code | แผน subscription หรือ Anthropic API key | เซสชัน agentic ที่ยาวนาน, context window ขนาดใหญ่, การอ่านไฟล์ซ้ำๆ |
| Codex | แผน subscription หรือ OpenAI API key | งานที่ใช้ reasoning หนัก, concurrency สูง, ลูปการเรียก tool |
| Gemini CLI | Free tier แล้วต่อด้วย Google Cloud API key | งานที่ใช้ context ขนาดใหญ่เมื่อพ้นโควตา free, การเรียกแบบ image และ multimodal |
โมเดลแบบ subscription ซ่อน marginal cost ไว้ แผนรายเดือนแบบเหมาจ่ายให้ความรู้สึกว่าฟรีที่ขอบ margin วิศวกรจึงเรียกใช้มันตลอดเวลา และคำถามจริงก็เปลี่ยนจาก "อันนี้ราคาเท่าไหร่" เป็น "เราใกล้ชนลิมิตของแผนหรือยัง" ส่วนโมเดลแบบ API key คิดตามการใช้งานทำตรงกันข้าม ทุกการรันมีราคาที่มองเห็นได้ ซึ่งทำให้ตั้งงบประมาณง่ายขึ้น แต่ก็ล่อใจให้ทีมใช้ agent ที่มีความสามารถน้อยเกินไปเพื่อประหยัดไม่กี่สตางค์
ใช้แผน subscription เมื่อมีคนหนึ่งหรือสองคนใช้ agent อย่างสม่ำเสมอทั้งวัน และ billing ที่คาดเดาได้สำคัญกว่ารายละเอียดต่อ task ใช้ API key แบบคิดตามการใช้งานเมื่อคุณต้องระบุค่าใช้จ่ายอย่างแม่นยำ รันในระบบ automation หรือกระจายงานให้ทีมที่ต้องมีคนรับผิดชอบยอดรวม หลายทีมลงเอยด้วยการใช้ทั้งสองแบบ ซึ่งนั่นแหละคือเหตุผลที่มุมมองที่กระทบยอดเป็นหนึ่งเดียวจึงสำคัญ ถ้าคุณกำลังเลือกว่า agent ตัวไหนควรทำงานไหน การจับคู่โมเดลกับงาน ช่วยลดบิลได้มากกว่าการเปลี่ยนผู้ให้บริการเสียอีก
สามคันโยกที่คุณควบคุมได้จริง
ราคาของผู้ให้บริการไม่ใช่คันโยก คุณต่อรองราคาจากในเทอร์มินัลไม่ได้ มีสามอย่างที่อยู่ในมือคุณจริงๆ และมันสำคัญกว่าราคาที่ติดป้าย
วินัยเรื่อง context ค่าใช้จ่ายที่หลีกเลี่ยงได้มากที่สุดคือการส่ง context ซ้ำที่ agent มีอยู่แล้ว agent ที่อ่าน codebase ทั้งหมดใหม่ทุกเทิร์นก็ต้องจ่ายค่า codebase นั้นทุกเทิร์น การเก็บ context ไว้ระหว่างการรัน เพื่อให้ agent เริ่มจากสถานะปัจจุบันแทนที่จะสร้างมันขึ้นมาใหม่ มักเป็นวิธีประหยัดที่ได้ผลมากที่สุดเพียงวิธีเดียว นี่คือกลไกเดียวกับที่อยู่เบื้องหลัง codebase memory และต้นทุน token ของมัน สิ่งที่คุณเก็บไว้ ก็ไม่ต้องซื้อซ้ำ
การจับคู่โมเดลกับงาน การส่งงานเปลี่ยนชื่อบรรทัดเดียวไปให้โมเดล reasoning หนักๆ คือการเปลืองเงิน และการส่งงาน refactor สถาปัตยกรรมไปให้โมเดลเล็กที่เร็วคือการเปลืองเวลาทั้งบ่าย การประหยัดมาจากการจับคู่โมเดลกับงาน แทนที่จะโยนทุกงานให้ agent ที่เก่งที่สุดของคุณเป็นค่าเริ่มต้น
ขอบเขตของ parallelism การรัน agent แบบขนานคือจุดที่ได้ผลลัพธ์เพิ่มขึ้นจริง และก็เป็นจุดที่ค่าใช้จ่ายทบต้นเร็วที่สุดด้วย agent ห้าตัวที่ทำงานพร้อมกันมีค่าใช้จ่ายประมาณห้าเท่าต่อหน่วยเวลานาฬิกา ซึ่งก็โอเคถ้ามีงานห้าชิ้นพร้อมและคุ้มค่า และแพงถ้าในนั้นสามชิ้นเป็นแค่การคาดเดา คันโยกไม่ใช่ "รัน agent ให้น้อยลง" แต่คือการตัดสินใจก่อนเริ่มว่าจริงๆ แล้วงานชิ้นไหนควรได้สล็อตแบบขนาน การมอนิเตอร์ agent ที่รันแบบขนาน คือสิ่งที่เปลี่ยนการตัดสินใจนั้นจากการเดาให้กลายเป็นข้อสรุปที่คุณปกป้องได้
ตารางการตัดสินใจตามขนาดทีม
สมการต้นทุนเปลี่ยนไปตามจำนวนคนและ agent ที่คุณประสานงาน สิ่งที่โอเคสำหรับนักพัฒนาคนเดียวอาจกลายเป็นภาระสำหรับทีม platform
| รูปแบบทีม | ค่าใช้จ่ายอยู่ที่ไหน | ควรปรับให้เหมาะกับอะไร |
|---|---|---|
| นักพัฒนาคนเดียว ใช้ agent หนึ่งหรือสองตัว | dashboard หนึ่งหรือสองอันที่อ่านได้โดยตรง | Billing ที่คาดเดาได้ แผน subscription มักเพียงพอ |
| ทีมเล็ก ใช้ agent หลายตัว | แตกกระจายไปตาม subscription และ key ของแต่ละคน | การระบุที่มา รู้ว่างานชิ้นไหนขับค่าใช้จ่าย |
| ทีม platform หรือทีมวิศวกรรม | หลาย repo หลาย agent งบประมาณที่ใช้ร่วมกัน | การมองเห็น การตรวจสอบ และต้นทุนต่อ task ที่ม้วนรวมถึงเจ้าของงาน |
ถ้าคุณทำงานคนเดียวและสบายใจกับเทอร์มินัลเดียวที่มี agent ตัวเดียว คุณไม่จำเป็นต้องมี management layer เพื่อควบคุมต้นทุน dashboard ของคุณก็บอกสิ่งที่ต้องรู้อยู่แล้ว สมการจะเปลี่ยนเมื่อค่าใช้จ่ายเติบโตเกินกว่าจะดูจากมุมมองเดียวได้ ไม่ว่าจะเป็น agent หลายตัว repo หลายแห่ง และงบประมาณที่ต้องมีคนอื่นนอกจากคุณรับผิดชอบ ถึงจุดนั้นคำถามก็ไม่ใช่ "agent ตัวไหนถูกที่สุด" อีกต่อไป แต่กลายเป็น "ใครเห็นภาพรวมทั้งหมดและตัดสินใจได้"
ทำให้ค่าใช้จ่ายต่อ task มองเห็นได้
นี่คือ layer ที่ Sharkly ถูกสร้างขึ้นมาเพื่อรองรับ และควรพูดให้ชัดว่ามันทำอะไรและไม่ทำอะไร Sharkly ไม่ใช่เครื่องมือ billing และไม่ได้แทนที่ Claude Code, Codex หรือ Gemini การใช้งานโมเดลยังคงเกิดขึ้นผ่าน subscription หรือ API key ที่ตั้งค่าไว้ในเครื่องมือเหล่านั้น คุณนำ subscription ของตัวเองมาใช้ สิ่งที่ Sharkly เพิ่มเข้ามาคือบันทึกร่วมรอบๆ เครื่องมือเหล่านั้น ทุกการรันของ agent เกิดขึ้นภายใน Task และการทำงาน ความคืบหน้า อุปสรรค และผลลัพธ์จะกลับไปอยู่ใน Task นั้นที่ทีมมองเห็นได้
บันทึกร่วมนั้นคือสิ่งที่ทำให้ต้นทุนอ่านออก เมื่อการรันแต่ละครั้งผูกกับ Task ที่มีเจ้าของและ repo ค่าใช้จ่ายก็ไม่ใช่ยอดรายเดือนนิรนามก้อนเดียวอีกต่อไป แต่กลายเป็นชุดการตัดสินใจที่คุณชี้ได้ คุณเห็นได้ว่างานไหนกำลังรัน อยู่บน Computer ของใคร และใช้งบประมาณไหน ตั้งแต่คำขอจนถึงการปล่อย coding agent dashboard ที่แสดงให้เห็นว่าอะไรกำลังรันอยู่ คือความต่างระหว่างการบริหารค่าใช้จ่ายกับการเพิ่งมารู้ทีหลังตอนใบแจ้งหนี้มา
สัญญาระหว่างมนุษย์กับ agent ก็ใช้ตรงนี้ด้วย agent ค้นคว้า ลงมือทำ ทดสอบ และรายงาน คนกำหนดทิศทาง ให้อำนาจ และตัดสินใจว่าค่าใช้จ่ายนั้นคุ้มกับผลลัพธ์หรือไม่ automation หยุดตรงจุดที่ต้องใช้ดุลยพินิจของทีม ซึ่งสำหรับเรื่องต้นทุนหมายความว่าคน ไม่ใช่สคริปต์ ที่ตัดสินใจว่ารัน agent ห้าตัวพร้อมกันนั้นสมเหตุสมผลก่อนที่จะเริ่ม
ถ้าคุณอยากใช้ coding agent หลายตัวต่อไป แทนที่จะผูกกับ ecosystem เดียวเพื่อให้ billing ง่ายขึ้น นั่นคือปัญหาที่ Sharkly ถูกออกแบบมาเพื่อแก้ รัน coding agent ที่คุณมีอยู่ผ่าน Sharkly แล้วให้ค่าใช้จ่ายของการรันแต่ละครั้งกลับไปหางานที่ทำให้เกิดมัน
