Claude Code ส่ง 33,000 โทเคนก่อนอ่านพรอมป์ต์ ขณะที่ OpenCode ส่ง 7,000 โทเคน

 (systima.ai)
3 คะแนน โดย GN⁺ 5 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • จากการวัดที่ขอบเขต API ภายใต้โมเดล เครื่อง และงานเดียวกัน พบว่าโอเวอร์เฮดคงที่ของคำขอแรกบน Sonnet 4.5 อยู่ที่ Claude Code ราว 32,800 โทเคน และ OpenCode ราว 6,900 โทเคน ต่างกัน 4.7 เท่า และบน Fable 5 ช่องว่างนี้ลดลงเหลือราว 3.3 เท่า
  • ช่องว่างส่วนใหญ่มาจาก สคีมาของเครื่องมือ โดย Claude Code ใช้ราว 24,000 โทเคนกับคำจำกัดความเครื่องมือ 27 รายการ ขณะที่ OpenCode ใช้ราว 4,800 โทเคนกับเครื่องมือ 10 รายการ และแม้ปิดเครื่องมือทั้งหมดแล้ว system prompt ก็ยังมีขนาดราว 6,500 โทเคนและ 2,000 โทเคนตามลำดับ
  • ในการตั้งค่าจริง ไฟล์คำสั่งขนาด 72KB เพิ่มราว 20,000 โทเคนในทุกคำขอ และ MCP server ขนาดเล็ก 1 ตัวเพิ่มอีกราว 1,000–1,400 โทเคน ทำให้คำขอแรกอาจพุ่งถึง 75,000–90,817 โทเคน
  • ในงานสรุปไฟล์เดียวกัน Claude Code สร้าง cache write มากกว่า 5.9–54 เท่า เมื่อเทียบกับ OpenCode และเมื่อกระจายงานไปยัง sub-agent สองตัว ปริมาณการใช้เพิ่มจาก 121,000 โทเคนเป็น 513,000 โทเคน หรือ 4.2 เท่า
  • อย่างไรก็ดี ไม่ควรตัดสินต้นทุนทั้งหมดจากโอเวอร์เฮดคงที่เพียงอย่างเดียว ในงานหลายขั้นตอน Claude Code จัดคำสั่งเรียกเครื่องมือแบบขนานและใช้ราว 121,000 โทเคนใน 3 คำขอ ขณะที่ OpenCode ใช้การเรียกแบบอนุกรม 9 ครั้ง รวมราว 132,000 โทเคน

วิธีการวัดที่ขอบเขต API

  • วาง logging proxy ไว้ระหว่าง Claude Code และ OpenCode เพื่อบันทึก JSON request ที่ harness ส่งจริงและ usage block ที่ API ส่งกลับ
    • ใน request body มี system block, tool schema และข้อความ
    • usage มี input token, cache write/read และ output token
    • request body ที่จับได้ใช้เป็นข้อมูลการส่งจริง ส่วน usage block จาก API ใช้เป็นเกณฑ์ของการคิดค่าบริการจริง
  • สำหรับการเปรียบเทียบพื้นฐาน ใช้ Claude Code 2.1.207 และ OpenCode 1.17.18 โดยทั้งคู่ตรึงไว้ที่ claude-sonnet-4-5 ตามข้อมูล ณ เดือนกรกฎาคม 2026
    • การทดสอบโอเวอร์เฮดคงที่ งาน cache และงานหลายขั้นตอนบางส่วนถูกรันซ้ำบน claude-fable-5
    • แยกค่าพื้นฐานด้วยไดเรกทอรีตั้งค่าใหม่, ไม่มี MCP server/การตั้งค่าผู้ใช้/หน่วยความจำ และเวิร์กสเปซว่างที่ไม่มีไฟล์คำสั่ง
  • ใช้งาน 3 แบบเพื่อวัดโครงสร้างต้นทุนที่ต่างกัน
    • T1 ใช้ Reply with exactly: OK เพื่อแยกโอเวอร์เฮดคงที่ และรัน 3 ครั้งต่อ harness
    • T2 ให้อ่านไฟล์ที่เตรียมไว้ล่วงหน้าแล้วสรุป
    • T3 ให้ทำขั้นตอนเขียน/รัน/ทดสอบ/แก้ไขกับ FizzBuzz และสคริปต์ตรวจสอบ
  • เพื่อเปรียบเทียบ system prompt โดยไม่นับ tool schema ใช้ --tools "" กับ Claude Code และ "tools": {"*": false} กับ OpenCode
  • local LLM gateway เพิ่ม ซองคงที่ราว 6,200 โทเคน ในทุกคำขอ จึงปรับแก้ออกก่อนและไม่รวมไว้ในค่าที่รายงาน
    • ตัวเลขรายองค์ประกอบคำนวณจาก request body ที่จับได้ซึ่ง gateway ไม่สามารถเปลี่ยนแปลงได้
    • การแปลงอักขระเป็นโทเคนใช้สัดส่วน 1 โทเคนต่อ 4.1–4.4 อักขระตามการวัดในสภาวะ cold cache

tool schema ที่ทำให้โอเวอร์เฮดพื้นฐานสูงขึ้น

  • ในคำขอแรกของ T1 ที่ใช้พรอมป์ต์ยาว 22 อักขระ Claude Code ส่งราว 32,800 โทเคน ขณะที่ OpenCode ส่งราว 6,900 โทเคน
    • system prompt ของ Claude Code มี 3 block ยาว 27,344 อักขระ ส่วน OpenCode มี 1 block ยาว 9,324 อักขระ
    • tool schema 27 รายการของ Claude Code ยาว 99,778 อักขระ ส่วน 10 รายการของ OpenCode ยาว 20,856 อักขระ
    • Claude Code แทรก block <system-reminder> ยาว 7,997 อักขระก่อนพรอมป์ต์จริง โดยบรรจุประเภทเอเจนต์, skill ที่ใช้ได้ และบริบทของผู้ใช้
    • OpenCode ส่ง system block, coding tool 10 รายการ และ user prompt โดยไม่มี scaffolding ข้อความแรกแยกต่างหาก
  • ทั้งสองฝั่งมี tool definition เป็นสัดส่วนใหญ่ที่สุด
    • จากราว 33,000 โทเคนของ Claude Code มีราว 24,000 โทเคนเป็น tool definition
    • จากราว 6,900 โทเคนของ OpenCode มีราว 4,800 โทเคนเป็น tool definition
    • เครื่องมือของ Claude Code มีทั้งความสามารถด้านการเขียนโค้ดและฟังก์ชันอย่าง CronCreate, Monitor, กลุ่ม Task, การจัดการ task tree และ push notification สำหรับ background agent/orchestration
  • เมื่อลบเครื่องมือทั้งหมด system prompt ของ Claude Code ยาว 26,891 อักขระ หรือราว 6,500 โทเคน ส่วน OpenCode ยาว 8,811 อักขระ หรือราว 2,000 โทเคน
    • พรอมป์ต์ของทั้งสอง harness ลดลงเล็กน้อยเมื่อปิดเครื่องมือ
    • ความต่างที่เหลือมาจาก คำสั่งด้านพฤติกรรม เช่น โทนภาษา, แนวทางความปลอดภัย, กฎการจัดการงาน และข้อมูลสภาพแวดล้อม
  • บน Fable 5 Claude Code ย่อพรอมป์ต์ลงตามโมเดล ทำให้ช่องว่างหดเหลือราว 3.3 เท่า
    • system instruction ลดจาก 27,787 อักขระบน Sonnet เหลือ 10,526 อักขระบน Fable
    • แม้ยังคงใช้เครื่องมือ 27 รายการเดิม แต่ schema ก็ลดจาก 99,778 อักขระเหลือ 82,283 อักขระ
    • request ของ OpenCode เหมือนเดิมทุกไบต์ในทั้งสองโมเดล

การใช้ทั้งหมดที่เปลี่ยนตามลักษณะของงาน

  • ใน T2 ที่ให้อ่านและสรุปไฟล์เดียว ทั้งสอง harness ให้ผลลัพธ์ถูกต้อง แต่โครงสร้าง request ต่างกัน
    • Claude Code ใช้ HTTP request 6 ครั้ง และ input สะสมราว 199,000 โทเคน
    • OpenCode ใช้ 4 request และราว 41,000 โทเคน พร้อมเพิ่มการเรียก Haiku 1 ครั้งเพื่อสร้างชื่อเซสชัน
    • ปริมาณการใช้ส่วนใหญ่มาจาก cache read ซึ่งคิดค่าบริการเพียงหนึ่งในสิบของ input price
  • แม้มีส่วนลดจาก cache แต่ cache write ของคำขอแรก, cache read ของแต่ละเทิร์น และการกินพื้นที่ context window ก็ยังเพิ่มตามขนาด payload
    • เส้นฐาน 33,000 โทเคนกินพื้นที่เกือบหนึ่งในหกของหน้าต่าง 200,000 โทเคนตั้งแต่ก่อนใส่โค้ดใด ๆ
  • ใน T3 ซึ่งเป็นงานเขียน/รัน/ทดสอบ/แก้ไข วิธีเรียกใช้เครื่องมือ ช่วยหักล้างความต่างของโอเวอร์เฮดพื้นฐาน
    • Claude Code จัดการเขียนไฟล์ 2 ครั้งและรันสคริปต์ 2 ครั้งไว้ในรอบ tool แบบขนานครั้งเดียว ทำให้มี model request 3 ครั้ง ใช้ input สะสมราว 121,000 โทเคน
    • OpenCode เรียกเครื่องมือได้ครั้งละตัวต่อเทิร์น จึงมี 9 request บวก 1 title call ใช้ input สะสมราว 132,000 โทเคน
    • input รวมโดยคร่าว ๆ ถูกกำหนดจากเส้นฐานต่อ request คูณจำนวน request แล้วบวกการเติบโตของบทสนทนา
  • เมื่อบทสนทนาดำเนินต่อ Claude Code เพิ่ม <system-reminder> จาก 3 block ในเทิร์นแรกเป็น 4 block เมื่อถึงรอบ tool แรก
  • payload เพิ่มต่อเทิร์นของ OpenCode อยู่ราว 400–2,200 อักขระ และโตจากเนื้อหาบทสนทนาเท่านั้น

โทเคนที่เพิ่มขึ้นจากการตั้งค่าจริง

  • เมื่อเพิ่ม AGENTS.md ขนาด 72KB จากรีโป production ทั้งสอง harness มีปริมาณเพิ่มขึ้น มากกว่า 20,000 โทเคน ในทุกคำขอ
    • ค่าที่วัดของ OpenCode เพิ่มจาก 13,152 โทเคนเป็น 33,336 โทเคน
    • Claude Code เพิ่มจาก 39,005 โทเคนเป็น 59,243 โทเคน
    • Claude Code 2.1.207 ไม่อ่าน AGENTS.md และต้องเปลี่ยนชื่อเป็น CLAUDE.md จึงจะแทรกเข้าในข้อความผู้ใช้แรก
    • OpenCode อ่านได้ทั้งสองชื่อไฟล์และแทรกเข้า system prompt
    • หากไม่ตรวจสอบชื่อไฟล์ที่ harness รับรู้จริง ไฟล์คำสั่งอาจถูกเมินอย่างเงียบ ๆ
  • MCP server สาธารณะขนาดเล็กเพิ่มราว 1,000–1,400 โทเคนต่อ server ต่อคำขอ
    • server 5 ตัวเพิ่ม 4,900 โทเคนให้ payload ของ Claude Code และเพิ่ม 6,967 โทเคนให้ค่าที่วัดของ OpenCode
    • จำนวนเครื่องมือเพิ่มจาก 27 เป็น 69 สำหรับ Claude Code และจาก 10 เป็น 52 สำหรับ OpenCode
    • production server ที่มี API มากอาจส่ง schema ที่ใหญ่กว่านี้
    • โหมด print ของ Claude Code จะเมิน .mcp.json ในขอบเขตโปรเจกต์อย่างเงียบ ๆ หากไม่มี --mcp-config แบบชัดเจน จึงควรยืนยันการเชื่อมต่อที่ขอบเขต API
  • เฟรมเวิร์กเวิร์กโฟลว์แบบ story-driven อย่าง BMAD จะขยาย slash command เป็นเทมเพลตขนาดใหญ่ที่มี persona, protocol และ checklist
    • เทมเพลตยาว 8,405 อักขระในการทดลองนี้มีขนาดเพียงราว 2,100 โทเคน แต่เมื่อเข้าไปอยู่ในประวัติการสนทนาแล้ว จะถูกส่งซ้ำในทุกคำขอถัดไป
    • ในเซสชันที่มี 9 request เทมเพลตเดียวกันจะถูกบรรทุกไป 9 ครั้ง ทำให้ต้นทุนเพิ่มตาม ขนาดเทมเพลต × จำนวน request
  • คำขอแรกในการตั้งค่าจริงมีขนาดใหญ่กว่าค่าโอเวอร์เฮดพื้นฐานมาก
    • OpenCode ใช้ MCP server 11 ตัวสำหรับอีเมล/ปฏิทิน, การจัดการงาน, การจัดการบรรณานุกรม, การวิเคราะห์ผลิตภัณฑ์ ฯลฯ ร่วมกับไฟล์คำสั่ง 72KB จนมี 179 เครื่องมือและ schema 277KB พร้อม cold cache write 90,817 โทเคน
    • Claude Code ใช้ MCP server 4 ตัว, ปลั๊กอินที่ติดตั้งไว้ และไฟล์คำสั่งเดียวกัน จนมี 118 เครื่องมือและ payload 311KB ใช้ราว 75,000 โทเคน
    • ค่าพื้นฐานของการตั้งค่า OpenCode สูงกว่าค่าเริ่มต้นราว 12 เท่า เมื่อไม่นับซองของ gateway ที่ราว 7,000 โทเคน

ต้นทุนของ sub-agent และ extended thinking

  • เมื่อ Claude Code กระจายงานแบบขนานไปยัง sub-agent สองตัว การใช้เพิ่มจาก 121,000 โทเคนของการรันตรงเป็น 513,000 โทเคน หรือ 4.2 เท่า
    • เกิด model request ทั้งหมด 9 ครั้งจากคำขอ 3 ประเภท ได้แก่ main session และการเรียก sub-agent
    • การเรียก sub-agent 5 ครั้ง แต่ละครั้งบูตตัวเองด้วย system prompt 3,554 อักขระและเครื่องมือ 24 รายการจากชุดพื้นฐาน 27 รายการ
    • แต่ละ sub-agent รับภาระต้นทุนเริ่มต้นเอง และ parent ยังต้องกลับมาอ่าน execution log ของมันอีกครั้ง
  • sub-agent ของ OpenCode ส่งโปรไฟล์ที่ย่อแล้ว โดยมี system prompt 1,379 อักขระและใช้เครื่องมือเพียง 5 รายการ
    • เนื่องจากการรันผ่าน gateway ไม่จบสมบูรณ์ จึงไม่ได้ให้ตัวเลขการใช้ sub-agent ของ OpenCode แบบเต็ม
    • เปรียบเทียบเฉพาะความต่างด้านการออกแบบที่ยืนยันได้จาก payload ที่จับมา
  • ผลลัพธ์ extended thinking ถูกคิดราคาในอัตรา output ซึ่งสูงกว่า input 5 เท่า และเมื่อ reasoning block เข้าไปอยู่ในประวัติการสนทนา ก็จะถูกส่งซ้ำในคำขอถัดไป
    • เนื่องจากนโยบายการคิดของ gateway เองทำให้ยืนยันไม่ได้ว่าการตั้งค่าของทั้งสอง harness ถูกนำไปใช้จริงหรือไม่ จึงไม่เปิดเผยตัวเลขการวัด
    • สิ่งที่ยืนยันได้คือโครงสร้างต้นทุนที่เกิดเมื่อ reasoning block ถูกผนวกเข้ากับ history

ความคุ้มค่าและเสถียรภาพของ prompt cache

  • ทั้งสอง harness ตั้งค่า cache breakpoint ได้ถูกต้อง โดย payload จะถูกเขียนหนึ่งครั้งที่ราคา 1.25 เท่า ของ input ปกติภายใต้ TTL 5 นาที และหลังจากนั้นจะถูกอ่านในราคาหนึ่งในสิบ
  • มีต้นทุน 3 แบบที่ cache ไม่ช่วยลด
    • หากหยุดเกิน 5 นาที ต้องเขียน stack ทั้งหมดใหม่อีกครั้ง ดังนั้นหลังพักประชุมหรือไปกินข้าวก็จะเกิดค่า write ใหม่
    • cache read ยังเกิดซ้ำตามจำนวน request ทำให้ลูปเครื่องมือแบบอนุกรมและการกระจายไปยัง sub-agent เพิ่มต้นทุน
    • การกินพื้นที่ context window ไม่ได้รับส่วนลดจาก cache ดังนั้น bootstrap 85,000 โทเคนจะกินมากกว่า 40% ของหน้าต่าง 200,000 โทเคน และเมื่อเริ่มมีการบีบอัดก็จะมีต้นทุนสรุปเพิ่มอีก
  • OpenCode รักษา prefix ที่เหมือนกันทุกไบต์ ในทุก request และทุกการรันที่จับมา
    • ใน 3 เซสชันของ T1 ไบต์ของเครื่องมือ, system และข้อความเหมือนกันทั้งหมด และ cache write ของการรันซ้ำเป็น 0
    • เซสชัน T3 ที่มี 9 request ก็ยังคง prefix เดียวที่เสถียร
  • Claude Code สร้าง request type และ cache item ที่ต่างกันไปในแต่ละเซสชัน เช่น warm-up exploration, main conversation และการเรียก sub-agent
    • แม้อยู่ในเวิร์กสเปซเดียวกัน system byte และ scaffolding ของข้อความแรกก็ยังแตกต่างกันในแต่ละการรัน
    • ในงานสรุปไฟล์เดียวกัน มี cache token ถูกเขียน 53,839 โทเคนตลอด 5 request และมีการเขียน prefix เต็มราว 43,000 โทเคนซ้ำอีกครั้งกลางงาน
    • งานเดียวกันบน OpenCode มี cache write เพียง 1,003 โทเคน
  • การเขียน cache ซ้ำขนาดใหญ่ของ Claude Code ปรากฏซ้ำในการทดลองหลายครั้ง
    • ในสองรันแรกมีการเขียนซ้ำ 43,342 โทเคนและ 36,899 โทเคนตามลำดับ ส่วนรันที่สามซึ่งใช้ cache ที่เพิ่งวอร์มใหม่แทบไม่ต้องเขียน
    • บน Fable 5 ก็ยังมีการเขียนซ้ำ 50,053 โทเคนโดยไม่มี cache read ทำให้เกิดช่องว่างราว 52 เท่า ใกล้เคียงกับ 54 เท่าบน Sonnet
    • ขึ้นอยู่กับอุณหภูมิของ cache ปริมาณ cache write ของ Claude Code อยู่ที่ 5.9–54 เท่า ของ OpenCode
    • ราคา cache write คือ 1.25 เท่าของราคาปกติในชั้น 5 นาที และ 2 เท่าในชั้น 1 ชั่วโมง
  • cache miss เพียงครั้งเดียวอาจเกิดจากการ eviction ของ gateway แต่กรณีนี้เกิดซ้ำได้หลายรอบ และยังพบความไม่เสถียรของ prefix จากไบต์ที่จับได้ก่อนส่ง request
    • เมื่อ prefix มีขนาดใหญ่ มีหลายชนิด ถูกเขียนซ้ำบ่อย และยังมี sub-agent เพิ่มเข้ามา มิเตอร์การใช้ของ Claude Code อาจไต่ขึ้นเร็วกว่า

คุณภาพของผลลัพธ์และ audit log

  • ทั้งสอง harness ทำงานที่ใช้ประเมินได้ถูกต้องทั้งหมด
    • ผลการสรุปไฟล์ถูกต้องทั้งคู่
    • งานหลายขั้นตอนผ่านสคริปต์ตรวจสอบที่แต่ละ harness เขียนขึ้นและจบได้ตามปกติ
    • ในขอบเขตนี้จึงสามารถเปรียบเทียบความต่างของต้นทุนโทเคนเพื่อให้ได้ผลลัพธ์เท่ากันได้
  • งานวิศวกรรมจริงที่ยากกว่านี้ยังไม่ได้วัดว่า background agent, skill และ orchestration ของ Claude Code ให้คุณภาพคุ้มกับต้นทุนที่เพิ่มหรือไม่
    • การตัดสินเช่นนั้นต้องมีชุดทดสอบที่เหมาะสม การรันซ้ำจำนวนมาก และการประเมินอัตราผ่านแยกต่างหาก
  • ยังพบความสิ้นเปลืองที่ไม่เกี่ยวกับคุณภาพ
    • การเขียน cache prefix ที่มีไบต์เหมือนเดิมซ้ำกลางเซสชัน เท่ากับซื้อเนื้อหาเดิมซ้ำในราคาพรีเมียม
    • หาก harness เมินไฟล์คำสั่งอย่างเงียบ ๆ ก็จะไม่ได้ประโยชน์ใดจากไฟล์นั้นเลย
  • บันทึก request/response ที่จับมา 185 รายการ ถูกเก็บลงในโซ่แฮช SHA-256 ด้วยไลบรารีโอเพนซอร์ส @systima/aiact-audit-log
    • โซ่ถูกตรวจสอบจนจบโดยไม่มีการขาดตอน และผลความสมบูรณ์คือ VALID
    • ด้วยโครงสร้างเดียวกันนี้ สามารถสร้างการรับส่งและการตอบกลับขึ้นใหม่ รวมถึงให้หลักฐานความสมบูรณ์แก่บุคคลที่สามได้
    • แนวทางนี้เป็นรูปแบบบันทึกแบบมีโครงสร้างเดียวกับที่ใช้สำหรับการล็อกตาม EU AI Act Article 12

ข้อจำกัดของการวัดและวิธีทำซ้ำ

  • ผลลัพธ์นี้เป็น snapshot เดือนกรกฎาคม 2026 จากเครื่องเดียว เวอร์ชัน harness สองตัว และตัวอย่างขนาดเล็ก
    • T1 และ T2 รันอย่างละ 3 ครั้ง ส่วนเงื่อนไขการคูณจากการตั้งค่าแต่ละแบบรันเพียง 1 ครั้ง
    • ค่าเริ่มต้นและเงื่อนไข cache ใช้ทั้ง Sonnet 4.5 และ Fable 5 ส่วนเงื่อนไขการคูณจากการตั้งค่าใช้เพียงโมเดลเดียว
    • พรอมป์ต์ของ harness เปลี่ยนบ่อย วิธีวัดที่ขอบเขต API จึงมีอายุการใช้งานยาวนานกว่าตัวเลขเฉพาะชุด
  • มี local gateway อยู่ในเส้นทางการวัด
    • ค่ารายองค์ประกอบอิงจาก request body ที่ gateway เปลี่ยนไม่ได้
    • ค่าที่วัดได้ถูกปรับแก้ซองคงที่ด้วย baseline ของ cold cache และตัดค่าของ warm run ที่แยกสาเหตุไม่ได้ออก
    • เคยมีกรณีที่ gateway สลับไปใช้ snapshot ใหม่กว่ารุ่นที่ตรึงไว้อย่างเงียบ ๆ จึงควรตรวจสอบโมเดลที่ตอบจริงที่ขอบเขตด้วย
    • ในเส้นทาง Fable มีการ resume server session เก่าและมีการรันเครื่องมือฝั่งโฮสต์ จึงตัดผลหลายขั้นตอนของ Claude Code บน Fable ออก
  • การที่ต้นทุนของ T3 มาบรรจบกันเป็นเพียงการสังเกตครั้งเดียวในงานลักษณะหนึ่ง
    • หากเป็นงานที่ต้องรันตามลำดับอย่างหลีกเลี่ยงไม่ได้ จำนวน request และการใช้ทั้งหมดของ Claude Code อาจเพิ่มขึ้นอีก
    • เงื่อนไขปิดเครื่องมือและ sub-agent ของ OpenCode ส่งคืนสตรีมผิดพลาดจาก gateway จึงใช้เพียงขนาด payload ที่จับได้
    • ตัวเลขจากการตั้งค่าจริงมาจากคอนฟิกของผู้ใช้หนึ่งราย และอาจต่างออกไปในสภาพแวดล้อมอื่น
  • อุปกรณ์ที่ใช้ทำซ้ำคือ HTTP proxy ที่เขียนด้วย Node ราว 200 บรรทัด
    • มันส่งต่อ request ไปยัง model endpoint พร้อมบันทึก request body และ usage block ของ response ลงดิสก์และ audit chain
    • ตั้ง ANTHROPIC_BASE_URL ให้ชี้ไปยัง proxy แล้ววัดค่าพื้นฐานในไดเรกทอรีตั้งค่าใหม่และเวิร์กสเปซว่าง ก่อนค่อย ๆ เพิ่มไฟล์คำสั่ง, MCP server และ workflow ทีละอย่าง
    • หากใช้ gateway ควรวัดซองของตัวมันเองด้วย request ขั้นต่ำก่อน และยืนยันว่าโมเดลใดเป็นผู้ตอบจริง
    • หากมีการทำ API boundary logging ที่สามารถสร้างสิ่งที่ production agent ส่งให้โมเดล ณ ช่วงเวลาหนึ่งได้อย่างแม่นยำ ก็จะได้ระบบบัญชีโทเคนไปพร้อมกัน

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 5 시간 전
ความคิดเห็นจาก Hacker News

  • ตัวที่เผาโทเคนหนักจริง ๆ คือ sub-agent นี่แหละ พอมอบงานใหญ่ให้ Claude Code มันก็เปิด sub-agent 7 ตัวทันที และงบก็หมดก่อนที่สักตัวจะทำเสร็จ ลองใหม่อีกทีหลัง 5 ชั่วโมงก็ยังเหมือนเดิม
    แต่พอให้เอเจนต์หลักทำงานเดียวกันแบบตามลำดับกลับไม่มีปัญหาเลย ไม่แน่ใจว่านี่ไม่มีประสิทธิภาพเพราะต้นทุนการสื่อสารและการประสานงาน หรือเพราะผู้ใช้ sub-agent มักเป็นบัญชีองค์กรที่จ่ายตามโทเคน ทำให้ Anthropic อยากเพิ่มรายได้

    • ในทางกลับกัน ช่วงสำรวจและวางแผนของโปรเจ็กต์ซับซ้อน พฤติกรรมแบบ ช่างสงสัย ของ Fable อาจเป็นสิ่งที่ต้องการพอดี ถ้าอยากให้เอเจนต์ประสานงานไม่ใช่แค่แยกพรอมป์ต์ออกเป็นหลายมุมมองในการสำรวจ แต่ให้แต่ละ sub-agent ไปตรวจโค้ดเบสตามมุมนั้นและขยายเบาะแสใหม่แบบ recursive ด้วย การใช้ Fable ทุกขั้นตอนก็สมเหตุสมผล
      แต่ถ้าเป็นงานที่วางแผนมาดีแล้วและแค่อยากเอาไปใช้แบบขนานกับหลายเป้าหมาย ก็ควรระบุให้ sub-agent ลดระดับขั้น ไปใช้โมเดลที่ช่างสงสัยน้อยกว่า ความสม่ำเสมอของผลลัพธ์อาจดีขึ้นด้วย
    • sub-agent แต่ละตัวต้องกลับไปอ่านบางส่วนของโค้ดเบสใหม่เพื่อเอาบริบทที่จำเป็นต่อการทำงาน ถ้างานยาวขึ้น บริบทของเอเจนต์ประสานงานก็จะหลุดจากแคช ทำให้หลัง sub-agent ทำเสร็จต้องจ่ายต้นทุนเต็มอีกรอบ
      ถ้ารันแบบตามลำดับ ก็จะอ่านไฟล์แต่ละไฟล์ประมาณครั้งเดียว และทุกคำขอใช้ prefix cache เดียวกันได้
    • ถ้าลูกค้าหันไปเลือกแพ็กเกจที่แพงกว่าเพื่อเลี่ยงปัญหา บริษัทก็จะมี แรงจูงใจเชิงลบ ที่จะไม่รีบแก้ปัญหานั้น ต่อให้มีวิศวกรบางคนที่มีทางแก้ ก็อาจเจอทั้งความไม่สนใจของคนส่วนใหญ่ การขัดขวางจากบางคน และบางครั้งอาจถึงขั้นการต่อต้านอย่างจริงจังจากชั้นผู้บริหารบางจุด
      ในสภาพแวดล้อมแบบนี้ กลยุทธ์ที่ดีที่สุดอาจเป็นการใส่ฟีเจอร์ใหม่ในแพ็กเกจบนสุดก่อน เก็บต้นทุนคืน แล้วค่อยปล่อยลงแพ็กเกจล่าง หรือ ชักบันไดหนี เพื่อให้คู่แข่งตามได้ยาก
    • sub-agent แต่ละตัวส่ง system prompt ขนาดประมาณ 30,000 โทเคน ชุดเดิมซ้ำ ๆ พอใช้ Fable/Opus แค่ 7 ตัวก็สามารถกินโควตาใช้งาน 5 ชั่วโมงไป 30% ได้ง่าย ๆ ก่อนที่งานจะเริ่มจริงด้วยซ้ำ
    • หลังจับทางนี้ได้ก็เริ่มสั่งห้ามใช้ Fable sub-agent แบบชัดเจน เมื่อวานหลังรีแฟกเตอร์ครั้งใหญ่ อยากตรวจโค้ดซับซ้อนเลยขอแผนการรีวิวก่อน มันเสนอ Fable agent 8 ตัวกับอีก 1 ตัวไว้ตรวจผลในขั้นแรกและฉันก็กดอนุมัติ
      แต่พอถึงขั้นตรวจสอบ มันกลับพยายามเปิด Fable verification agent 41 ตัว มันหาทางอ้อมจนได้

  • คิดที่ Claude Code ใช้โทเคนเยอะเพราะ Anthropic อยากทำเงินเพิ่มและผลักผู้ใช้ไปสู่แพ็กเกจสมัครสมาชิก นโยบายที่ไม่ให้เอาสิทธิ์สมาชิกไปใช้กับ coding agent อื่นก็ยิ่งสนับสนุนมุมมองนี้ ฉันใช้ pi

    • พอมอง Anthropic ว่าเป็น คนขายโทเคน การตัดสินใจหลายอย่างก็เริ่มเข้าใจได้ ตราบใดที่ผู้ใช้ยังไม่ต่อต้านหรือไม่เรียกร้องมาตรการป้องกัน ก็มีเหตุผลให้บริษัทหาทางทำให้คนใช้โทเคนผ่านเส้นทางของตัวเองมากขึ้นเรื่อย ๆ
    • ตามเอกสารที่เกี่ยวกับการเข้าตลาดหุ้น เคยเห็นว่ารายได้จากสมาชิกมีเพียงราว 5% ซึ่งน้อยมาก แต่ 5% นั้นน่าจะเป็นสมาชิก Claude สำหรับบุคคลทั่วไป ส่วนสมาชิก Claude Code ส่วนใหญ่อาจถูกนับอยู่ในฝั่งองค์กร
      API และ enterprise คิดเป็น 75–85% ของรายได้ทั้งหมด, สมาชิกองค์กรราว 10–15%, และสมาชิกบุคคลทั่วไปราว 5%
    • จริง ๆ แล้วตรรกะควรตรงกันข้าม สมาชิกจ่ายรายเดือนแบบคงที่ ดังนั้น Anthropic จึงควรมี แรงจูงใจให้ Claude Code ใช้โทเคนน้อยลง
    • แต่พฤติกรรมแบบนี้ก็ทำให้การใช้โทเคนของผู้ใช้สมาชิกทั่วไปที่อยู่ในแพ็กเกจเหมาจ่ายเพิ่มขึ้นด้วย ดูแล้ว คล้ายความไร้ความสามารถมากกว่าความจงใจ

  • ตามอุปมาอุปไมยที่สมเหตุสมผลของ PUSH_AX นี่เหมือนผู้รับเหมาราย A เรียก 33,000 ดอลลาร์ ขณะที่ราย B เรียก 7,000 ดอลลาร์ ดังนั้นเราต้องเช็กก่อนว่ากำลังวัดสิ่งที่ถูกต้องอยู่หรือเปล่า
    เพราะแบบนี้จึงตั้งใจจะเพิ่ม งานที่ลงลึกกว่าเดิม, การเปรียบเทียบผลลัพธ์เชิงคุณภาพ และข้อมูลสำหรับทำซ้ำอินพุต/เอาต์พุตให้เร็วที่สุดเท่าที่จะทำได้ลงในโพสต์

    • สงสัยว่าใน 33,000 โทเคนนั้นมี ข้อมูลบริบท อย่างบทสนทนาล่าสุดรวมอยู่มากแค่ไหน

  • ไม่ใช่แค่ปัญหา system prompt ใหญ่เท่านั้น สภาพแวดล้อมการทำงานของ coding agent ก็ใช้เครื่องมืออย่างดุเดือดมากขึ้นแม้กับคำขอเล็กน้อย ในการทดสอบ พรอมป์ต์อย่าง “Hey” หรือ “commit” บางครั้งทำให้เกิด การเรียกใช้เครื่องมือเกิน 30 ครั้ง
    https://quesma.com/blog/the-true-cost-of-saying-hi-to-an-ai-...
    เห็นได้จริงว่ามี เงินเฟ้อของโทเคน ที่ทำให้งานง่าย ๆ ใช้โทเคนมากขึ้นเรื่อย ๆ

    • น่าหงุดหงิดเวลา Opus แก้แค่คำสะกดผิดในคอมเมนต์จุดเดียว แล้วกลับไปรันทุกอย่างที่รันได้ทั้งเทสต์ ลินต์ ฯลฯ บางครั้งถึงกับ stash การเปลี่ยนแปลงปัจจุบันไว้ก่อนเพื่อเช็กเชิงรุกว่าเทสต์ทั้งหมดผ่านอยู่แล้วหรือไม่
      ก็เป็นความรับผิดชอบของฉันเหมือนกันที่เขียนกฎไว้ว่าต้องตรวจทุกการเปลี่ยนแปลงด้วยเทสต์ แต่ถ้าจะเน้น I ใน AI มากขนาดนั้น ก็ย่อมคาดหวังวิจารณญาณระดับที่พอจะรู้ว่าไม่ควรใส่มะเขือเทศลงในฟรุตสลัด
    • ถ้าได้รับพรอมป์ต์กำกวมอย่าง “Hey” หรือ “commit” มันก็จะเรียกใช้เครื่องมือมากขึ้นเพื่อคาดเดาว่าคุณต้องการอะไร โดยไปคุ้ยอดีตบทสนทนาและบริบทอื่น ๆ พรอมป์ต์ที่ชัดเจนกว่า ย่อมดีกว่า
    • แค่ commit เองนี่ไม่ใช่ว่าสามารถทำเองได้โดยไม่ต้องให้ LLM จัดการเหรอ?

  • ใช้ Claude มา 6 เดือนแล้วเพิ่งย้ายไป Codex เมื่อไม่นานนี้ Codex เปิดกว้างกว่า ติดตามกระบวนการทำงานของโมเดลได้ง่ายกว่า และประสบการณ์ใช้งานของขั้นตอนอนุมัติก็ดีกว่า โดยรวมแล้ว โปร่งใสกว่า และแทบไม่มีต้นทุนในการย้ายเลย
    ไม่ค่อยชอบที่ Claude ดูทึบขึ้นตั้งแต่ราวเดือนกุมภาพันธ์ รวมถึงเรื่อง system prompt ด้วย และ 33,000 โทเคน ก็ดูมากเกินไป

    • ตอนนี้ใช้ทั้งคู่ แต่จริง ๆ ก็แทบสลับกันใช้แทนกันได้ Codex เป็นโอเพนซอร์ส และชอบที่ OpenAI ระบุชัดว่าสิทธิ์สมาชิกสามารถนำไปใช้กับ agent อื่นได้ด้วย
      ช่วงหลัง OpenAI ดู เป็นมิตรกับผู้บริโภค มากขึ้นเยอะ
    • อยากรู้ว่าหลังจากมันโปร่งใสน้อยลงแล้ว ได้ลองตั้งค่าอะไรไปบ้าง เพราะตอนนี้ตัวเลือกการตั้งค่ามีเยอะขึ้นมาก

  • เอเจนต์ pi มี system prompt ที่เล็กกว่า และดูเนื้อหาทั้งหมดได้ที่นี่
    https://github.com/earendil-works/pi/blob/main/packages%2Fco...

    • อาจเกี่ยวข้องกับแนวคิดแบบ minimalism นี้ แต่ Pi ก็ขาดเครื่องมือส่วนใหญ่ที่จำเป็นให้ LLM ทำงานได้อย่างมีประสิทธิภาพและได้ผลดี เข้าใจแนวคิดที่ให้เพิ่มสิ่งที่ต้องการเองบนฐานที่ว่างเปล่าได้ แต่สำหรับผมมันโล่งเกินไป
    • สงสัยว่าเวลาส่ง system prompt ทุกครั้ง การตั้งค่าวันที่และ cmd จะทำให้ cache ใช้ไม่ได้ หรือไม่
      ถ้าจะใช้ไม่ได้เฉพาะตอนที่วันที่หรือ root directory เปลี่ยน ก็ถือว่าเกิดไม่บ่อยพอใช้ในทางปฏิบัติ
    • ถ้าต้องการเอเจนต์ขนาดเล็กที่สุดเพื่อปรับแต่งหนัก ๆ ก็ควรทำเองมากกว่าจะดึง transitive dependencies มากกว่า 130 ตัว มากับแพ็กเกจ pi-coder ที่ "เล็กที่สุด" ทำไม่ยากและได้เรียนรู้อีกเยอะ และช่วงเริ่มต้นก็ขอให้ LLM ตัวอื่นช่วยได้

  • ท้ายที่สุด สิ่งสำคัญไม่ใช่ขนาดของ prompt ดิบ ถ้าเป็นแบบนั้น Pi และตัวแปรของมันก็ควรมีต้นทุนต่ำที่สุด ประเด็นสำคัญคือ ประสิทธิภาพของ prompt และความเป็นมินิมอลของ prompt ก็มักถูกสับสนกับประสิทธิภาพอยู่บ่อย ๆ ถึงอย่างนั้น Claude Code ก็ดูเทอะทะเกินไปเมื่อเทียบกับงานที่มันทำ
    ที่สำคัญกว่านั้นคือคุณภาพของเครื่องมือ เครื่องมือที่แย่หรือมีบั๊กจะเพิ่มจำนวนรอบการเรียกไป-กลับอย่างมาก จนลบข้อได้เปรียบที่พยายามประหยัดไว้ตั้งแต่แรกไปหมด
    เมื่อไม่กี่เดือนก่อนมีการ benchmark เอเจนต์ 7 ตัวแบบเต็ม ๆ บนงาน 8 งาน และมีข้อมูลกับ trace อยู่ที่ https://github.com/dirac-run/dirac ผมเกี่ยวข้องโดยตรงกับหนึ่งในนั้นเลยอ้างความเป็นกลางไม่ได้ แต่เป็นข้อมูลที่ทำซ้ำได้ งานส่วนใหญ่เกี่ยวกับการรีแฟกเตอร์ ทำให้ Dirac ซึ่งเด่นเรื่อง hash anchoring และการวิเคราะห์ abstract syntax tree ชนะขาด

    • มีคู่แข่งจำนวนมากและการแข่งขันก็รุนแรงมาก ดังนั้นถ้ามีช่องให้ปรับปรุง เดี๋ยวก็จะมีใครสักคนทำสำเร็จ และหลังจากนั้นก็น่าจะ แพร่ไปยังผลิตภัณฑ์อื่นอย่างรวดเร็ว

  • ที่ทำงานบังคับให้ใช้ Claude Code แต่ใช้ --system-prompt "" ก็แก้ได้ง่าย ๆ อยากให้ยอมให้ใช้ runtime อื่นด้วย

    • ถ้าล้างด้วย --system-prompt "" แบบนี้ จะไม่ทำให้แม้แต่ system prompt พื้นฐาน ที่ช่วยให้โมเดลเข้าใจเครื่องมือที่ใช้ได้หายไปด้วยหรือ?
    • ผมใช้แบบนี้มานานแล้ว ไม่รู้เหมือนกันว่าทำไมทุกคนไม่ใช้
    • ไม่เคยรู้ว่ามีตัวเลือกนี้ อยากเห็นข้อมูลวิเคราะห์ประสิทธิภาพจริงก่อนและหลังใช้ รวมถึง กราฟประสิทธิภาพในสภาพแวดล้อมการใช้งานจริง
    • สงสัยว่าตัวเลือกนี้ใช้ตอนเริ่ม Claude หรือส่งไปพร้อมกันทุกครั้งเวลาส่ง prompt

  • ตอนแรกที่ทดลองโมเดลบนเครื่อง ผมต่อมันเข้ากับ Claude Code แล้วมันทำงานได้ดีมาก แต่ช้า
    ผมให้ Claude ช่วยตั้งค่า mitmproxy แล้วจับ system prompt แรกสุดทั้งหมดของ Claude Code ไว้ พอตรวจซ้ำพบว่าเป็น JSON ขนาด 162KB จากตรงนั้นเลยเริ่มลอง Pi, OpenCode และ Hermes

    • ตอนนี้ถ้ารัน /context ในเซสชันใหม่ของ Claude Code จะแสดงว่าใช้ไปเพียง 23,000 โทเค็นจากบริบท 1 ล้านโทเค็นของ Opus 4.8 โดยแยกเป็น system prompt 3.9k, system tools 13.9k, custom agents 235, memory files 28, skills 4.9k, messages 8 และ compressed buffer 3k โทเค็น
      system prompt 4,000 โทเค็น คิดเป็นประมาณ 15~20KB อยากขอให้เอาสิ่งที่จับได้ไปลง Gist แต่ก็อาจมีข้อมูลอ่อนไหว และ 162KB ที่เห็นก็อาจไม่ใช่ system prompt ล้วน ๆ

  • ของที่ผมทำส่งน้อยกว่านี้: https://maki.sh

    • เขาบอกว่าถ้าบริบทยาวเกินไป maki จะลบรูปภาพกับบล็อกการให้เหตุผล แล้วสรุปบทสนทนาก่อนหน้าเพื่อบีบอัดประวัติให้อัตโนมัติ
      แต่การสรุปบทสนทนาก่อนหน้านี้จริง ๆ แล้วก็เท่ากับ ทำให้ context cache ใช้ไม่ได้ ไม่ใช่หรือ ถึงจะใช้โทเค็นน้อยลง แต่ก็ไปใช้โทเค็นที่แพงกว่าหรือเปล่า?