ผลวัดจริง: orch ประหยัดโทเค่นตรงไหน

นี่คือผลการรัน claude และ codex ตัวจริงบนเครื่องเดียว เมื่อ 2026-10-17 เพื่อดูว่า ฟีเจอร์ไหนของ orch ลดต้นทุนได้จริง ลดเท่าไร และอันไหนไม่ได้ลด ข้อมูลดิบอยู่ที่ benchmarks/results-2026-10-17.json, -handoff-repeat.json, -context.json, -roles.json และ -roles2.json (ทั้งหมดอยู่ใน benchmarks/) สคริปต์วัดคือ scripts/benchmark.ts

อ่านข้อจำกัดก่อน

จำนวนรันน้อย เครื่องเดียว repo เล็กๆ หนึ่งอัน งานเล็ก 3 งาน ตัวเลขนี้บอกทิศทาง ไม่ใช่สถิติ งานเดียวกันรันซ้ำก็ได้ผลต่างกันมาก (ดู Noise) ผลต่างที่มีความหมายจึงต้องมากกว่าราว 40%

สรุป

ประหยัดจากอะไร	ผลที่วัดได้	ความมั่นใจ
Model routing: ส่งงานเล็กให้ haiku ที่ effort ต่ำ แทน claude-sonnet-5 ค่าเริ่มต้น	ต้นทุนลด 76% ใน 3 งาน (ลด 64–78% ต่องาน) แต่โทเค่นลดแค่ 27%	ดี: มากกว่า noise มาก และทั้ง 3 งานยังถูกต้อง
Handoff เบาลง: git diff --stat แทนการแนบ diff เต็ม (เฉพาะ diff ใหญ่)	input ลดราว 5,700–7,300 โทเค่นต่อการเรียก model ของเอเจนต์ที่รับช่วง (ลด 20–25% ต่อการเรียก) ที่ diff 60,000 ตัวอักษร	ปานกลาง: ชัดเมื่อดูต่อการเรียก แต่ยอดรวมทั้งรันถูก noise บัง
ข้ามการขอสรุป หลังติด limit หรือ login หมด	ประหยัด เวลา ไม่ใช่โทเค่น (การเรียกเอเจนต์ที่ติด limit ควรล้มทันที ยังไม่ได้วัด)	เหตุผลเชิงตรรกะเท่านั้น
ตัว orch เอง	ไม่พบ overhead ที่วัดได้ (+0.7% โทเค่น, +5.8% ต้นทุน อยู่ในช่วง noise) orch ไม่เรียก LLM เอง	ดี
Context preset (--context lean): ข้าม hooks, plugins และ skills ระดับผู้ใช้	ต้นทุนลด 48% ใน 3 งานเดิมด้วย model เริ่มต้น (ลด 41% เมื่อเทียบกับทุกรัน default ในการศึกษานี้) ถูกต้องครบ และ Codex input ลด 18% ต่อการเรียก	ปานกลาง: ทิศทางสอดคล้องกัน แต่แต่ละงานรันครั้งเดียวและมี noise ราว ±30%
Roles (--team standard: developer, tester, reviewer)	แพงขึ้นตามดีไซน์: โทเค่น 2.5 เท่า ต้นทุน 2.8 เท่า และเวลา 3.7 เท่าของการเรียกครั้งเดียวบนงานเล็ก ทั้งสาม role สำเร็จ	ปานกลาง: หนึ่งงาน หนึ่งรัน
role สร้างภาพ (--role designer บน Codex)	ได้ mockup SVG ที่ถูกต้องใน 23 วินาที ใช้ 21,200 billable tokens (input 19,989 + output 1,211 บวก input จาก cache อีก 110,592)	ปานกลาง: หนึ่งรัน
เลือกอัตโนมัติ (--auto)	เลือก developer และ tester กับงานเขียน test เล็ก: 2 การเรียก $0.5889 เทียบกับ $0.8078 ของทีม 3 role และ $0.2931 ของการเรียกครั้งเดียว	ปานกลาง: หนึ่งรัน
role อ่านอย่างเดียวรันขนาน (reviewer กับ security พร้อมกัน)	เวลาจริงเร็วขึ้นเฉลี่ยราว 1.7 เท่า (44 วินาที เทียบ 76 วินาที) ต้นทุนไม่ต่างอย่างชัดเจน (เฉลี่ย $0.47 เทียบ $0.42 รันละสองครั้ง แกว่ง) สอง role เริ่มพร้อมกันและรันใช้เวลาเท่ากับตัวที่ช้ากว่า	ปานกลาง: จำนวนรันน้อย ความแปรปรวนสูง
context คงที่ต่อการเรียก ถ้าไม่ทำอะไร	ไม่ลดโดยค่าเริ่มต้น: เป็น 44–86% ของต้นทุนงานเล็ก --safe-mode (preset minimal) ลดการเรียกคำเดียวได้ 68% แต่ตัดคำสั่งของโปรเจกต์ด้วย	ดี

ประเด็นหลัก: orch ประหยัดเงินด้วยการเลือก model ที่ถูกกว่าให้งานเล็ก ไม่ใช่ด้วยการส่งโทเค่นน้อยลง จำนวนโทเค่นแทบไม่เปลี่ยน (ลด 27%) แต่ต้นทุนลดสามในสี่เพราะโทเค่นของ haiku ถูกกว่า sonnet มาก

วิธีวัด

• orch จาก repo ที่ commit 826c5b5, Claude Code 2.1.231, Codex 0.162.1, Node 24, macOS
• git repo ตัวอย่างขนาดเล็ก (README และไฟล์ซอร์ส 3 ไฟล์) คัดลอกใหม่ทุกครั้งที่รัน
• Claude รันด้วย --permission-mode acceptEdits เพื่อให้แก้ไฟล์ได้ในโหมด headless ส่วน Codex ใช้ gpt-6-luna effort ต่ำ
• โทเค่นคือ billable tokens ตามที่ orch usage นับ: input ที่ไม่รวม cache read บวก output ต้นทุน (USD) เป็นตัวเทียบที่ดีกว่า เพราะคิดราคาตาม model และ cache ถูกต้อง (Claude รายงานให้ Codex ไม่รายงาน)
• ทุกรันบันทึกด้วยว่าผลถูกต้องหรือไม่ (แก้ไฟล์แล้ว สร้างไฟล์ test แล้ว ตอบถูก)

การทดลอง A: model routing

3 งาน baseline คือ claude -p ด้วย model เริ่มต้น ฝั่ง routed คือรันผ่าน orch ด้วย rule นี้

rules:
  - match: "spelling|explain|vitest"
    agent: claude
    model: haiku
    effort: low

งาน	model เริ่มต้น	ส่งให้ haiku (low)	ต้นทุนเปลี่ยน	โทเค่นเปลี่ยน	ถูกต้อง
แก้ typo	66,548 โทเค่น, $0.4242	43,827 โทเค่น, $0.0941	ลด 78%	ลด 34%	ใช่ / ใช่
เขียน test เล็ก	42,113 โทเค่น, $0.2906	26,065 โทเค่น, $0.0627	ลด 78%	ลด 38%	ใช่ / ใช่
อธิบายฟังก์ชัน	21,023 โทเค่น, $0.1504	24,369 โทเค่น, $0.0537	ลด 64%	เพิ่ม 16%	ใช่ / ใช่
ทั้งสามงาน	129,684 โทเค่น, $0.8652	94,261 โทเค่น, $0.2105	ลด 76%	ลด 27%	3/3 / 3/3

หมายเหตุ:

• ตัวตรวจอัตโนมัติรอบแรกให้คำตอบของงาน อธิบาย ฝั่ง model เริ่มต้นว่าผิด เพราะมันเขียน < แทนคำว่า "below" ซึ่งคำตอบถูกต้อง ผมอ่านยืนยันแล้วแก้ระเบียนให้ (ไฟล์ดิบมีบันทึกไว้)
• งาน typo ฝั่ง baseline วัดสองครั้ง: $0.4242 (ครั้งแรก) และ $0.2952 (ซ้ำ ดูการทดลอง B) เทียบกับครั้งที่ถูกกว่า ยังประหยัด 68%
• โทเค่นที่ประหยัดน้อย และมีหนึ่งงานที่ใช้มากขึ้น ส่วนที่ลดต้นทุนคือราคา model
• งานเขียน test ต้องให้ model เขียนไฟล์ และ haiku ทำได้ถูกในรอบนี้ แต่ไม่ได้แปลว่างานยากกว่านี้จะได้ ให้ใช้ rule ของ model กับงานเล็กที่ชัดเจน ส่วน refactor และงานออกแบบเก็บไว้กับ model ที่เก่งกว่า

การทดลอง B: orch เพิ่ม overhead ไหม

งาน typo เดิม model เดียวกัน รันตรงเทียบกับรันผ่าน orch (ไม่มี rule routing)

รัน	โทเค่น	ต้นทุน
claude -p ตรง	41,200	$0.2952
ผ่าน orch	41,492	$0.3122
ต่างกัน	+0.7%	+5.8%

ช่องว่างนี้อยู่ในช่วง noise ด้านล่าง orch แค่เลือกเอเจนต์และ parse output ไม่เรียก model เอง จึงไม่เพิ่มโทเค่นโดยดีไซน์

Noise: งานเดียวกันต่างกัน 38%

งานและค่าตั้งเดียวกัน รันตรงสองครั้ง: ครั้งแรก 66,548 โทเค่น ($0.4242) ครั้งที่สอง 41,200 โทเค่น ($0.2952) สาเหตุคือ prompt cache: cache เย็นต้องสร้าง context คงที่ก้อนใหญ่ใหม่ ส่วน cache อุ่นอ่านได้ถูกกว่ามาก และจำนวนรอบที่ model ทำงานก็ต่างกัน ผลต่างจากการรันครั้งเดียวที่น้อยกว่าราว 40% ของโทเค่น หรือ 30% ของต้นทุน จึงยังสรุปอะไรไม่ได้

การทดลอง C: handoff หลัง failover

เอเจนต์ที่รับช่วง (Codex) ทำงานต่อหลัง failover ใน repo ที่มี diff ที่ยังไม่ commit ขนาด 60,269 ตัวอักษร handoff แบบเก่า: แนบ diff สูงสุด 20,000 ตัวอักษร พร้อมสรุปจากเอเจนต์ตัวแรก แบบใหม่: git diff --stat และไม่ขอสรุป

	แบบเก่า	แบบใหม่
ขนาด prompt	20,781 ตัวอักษร	614 ตัวอักษร (ลด 97%)
input ต่อการเรียก model หนึ่งครั้ง	28,655	21,400–22,900 (ลด 5,700–7,300, หรือ 20–25%)
input รวมทั้งรัน 5 รัน (ค่าเฉลี่ย)	46,250	42,576 (ลด 8% ยังไม่มีนัยสำคัญ)
ถูกต้อง	5/5	5/5

ตัวเลขต่อการเรียกคือ input รวมของรัน หารด้วยจำนวนครั้งที่ Codex เรียก model (หนึ่งหรือสองครั้ง) prompt แบบเก่าได้ 28,655 ต่อการเรียกทุกครั้ง ส่วนแบบใหม่ได้ 21,397–22,943 ยอดรวมทั้งรันแกว่งเพราะ Codex เรียกบางรอบหนึ่งครั้ง บางรอบสองครั้ง ซึ่งส่งผลมากกว่าขนาด prompt สรุปอย่างตรงไปตรงมา: handoff แบบเบาลดราว 5,700–7,300 โทเค่นจาก ทุก การเรียก model ของเอเจนต์ที่รับช่วงหลัง failover ที่มี diff ใหญ่ ส่วน diff เล็กไม่เปลี่ยนเพราะยังแนบเต็ม (4,000 ตัวอักษรหรือน้อยกว่า)

การเรียกขอสรุป ที่ handoff แบบเก่าทำตอนล้มธรรมดา ใช้ 22,879 โทเค่น $0.1460 และ 7 วินาที (Claude resume session ก่อนหน้า) handoff ปัจจุบันยังขอสรุปหลังล้ม ธรรมดา แต่ข้ามหลังติด rate limit หรือ login หมด หลังติด limit การเรียกนี้ควรล้มทันทีและแทบไม่เสียโทเค่น สิ่งที่ประหยัดจึงเป็นเวลา ไม่ใช่โทเค่น (ยังไม่ได้วัด) ถ้าไม่ต้องการเสียราว 23,000 โทเค่นเพิ่มต่อ failover ที่เกิดจากการล้มธรรมดา ให้ลบ summaryArgs ออกจาก config ของเอเจนต์

การทดลอง D: ต้นทุนคงที่ของทุกการเรียก

คำตอบคำเดียว ("reply with the word pong") แสดงว่าแต่ละการเรียกมีต้นทุนเท่าไรก่อนมีงานจริง

รัน	โทเค่น	ต้นทุน
Claude, context เริ่มต้น	20,381	$0.1300
Claude --safe-mode (ไม่มี CLAUDE.md, skills, plugins, hooks, MCP)	5,611	$0.0412 (ลด 68%)
Claude --disable-slash-commands	36,161	$0.2170 (cache เย็น เทียบไม่ได้)
Claude --bare	ล้มเหลว	ต้องใช้ API key (ไม่ได้ login ผ่าน OAuth)
Codex, context เริ่มต้น	9,515 (+12,544 cached)	ไม่รายงาน

บนเครื่องนี้ คำตอบคำเดียวบน Claude ราคา $0.13 (ตอนวัดแบบ cache เย็นก่อนหน้านี้ได้ $0.27) นั่นคือ 44% ของต้นทุนงาน typo รอบซ้ำ และ 86% ของงานอธิบายฟังก์ชัน กล่าวคือในงานเล็ก ส่วนใหญ่ของค่าใช้จ่ายคือ context ที่โหลดทุกการเรียก ซึ่ง orch ยังไม่ลด --safe-mode แสดงขนาดของโอกาสนี้ แต่มันตัดคำสั่งโปรเจกต์และเครื่องมือของคุณออกด้วย พฤติกรรมจึงเปลี่ยน ไม่ใช่ชัยชนะฟรี

การทดลอง E: context preset

3 งานเดิมด้วย model เริ่มต้น รันผ่าน orch ด้วย context เริ่มต้น เทียบกับ --context lean (ดู Context presets) สลับลำดับระหว่างงาน และอุ่น cache ของแต่ละแบบก่อน

งาน	context เริ่มต้น	--context lean	ต้นทุนเปลี่ยน	input รวมเปลี่ยน	ถูกต้อง
แก้ typo	66,883 โทเค่น, $0.4418	41,700 โทเค่น, $0.2803	ลด 37%	ลด 28%	ใช่ / ใช่
เขียน test เล็ก	43,107 โทเค่น, $0.3154	17,552 โทเค่น, $0.1369	ลด 57%	ลด 46%	ใช่ / ใช่
อธิบายฟังก์ชัน	40,667 โทเค่น, $0.2621	16,246 โทเค่น, $0.1140	ลด 56%	ลด 28%	ใช่ / ใช่
ทั้งสามงาน	150,657 โทเค่น, $1.0193	75,498 โทเค่น, $0.5312	ลด 48%	ลด 35%	3/3 / 3/3

"input รวม" นับ cache read ด้วย (คือสิ่งที่ model ได้รับจริง)

อ่านผลอย่างตรงไปตรงมา ทิศทางเดียวกันทั้งสามงาน แต่แต่ละช่องคือการรันครั้งเดียว และต้นทุนของ context เริ่มต้นเองแกว่งราว ±30% ระหว่างรัน: งาน typo ราคา $0.4242, $0.2952 และ $0.4418 ในสามรัน default เมื่อเทียบกับทุกรัน default ของงานเหล่านี้ในการศึกษานี้ ประหยัด 41% และรายงานต่องานอยู่ในช่วง 5%–57% ขึ้นกับว่าเลือกรันไหนเป็น baseline การทดสอบคำตอบคำเดียวก็สอดคล้อง: --setting-sources project อย่างเดียวลดต้นทุน 47% และชุดแบบ lean ลด 58% จึงควรคาดว่าอยู่ราว 40–50% ไม่ใช่ตัวเลขที่แน่นอน

Codex (คำตอบคำเดียวผ่าน orch, gpt-6-luna, effort ต่ำ): input รวมต่อการเรียกลดจาก 22,066 และ 21,280 (default) เหลือ 17,862 และ 17,862 (lean) ประมาณ ลด 18% context พื้นฐานของ Codex เล็กกว่าและบีบได้น้อยกว่า Claude

สิ่งที่ lean ตัดทิ้ง: settings ระดับผู้ใช้ hooks plugins และคำสั่งส่วนตัว งานเหล่านี้ไม่ได้พึ่งสิ่งใดในนั้น ให้ตรวจกับงานของคุณเอง ถ้างานต้องใช้สิทธิ์หรือ hook ระดับผู้ใช้ ให้ใส่ไว้ใน args ของเอเจนต์หรือการตั้งค่าของโปรเจกต์

การทดลอง F: roles

งาน "เขียน test เล็ก" แบบเรียกครั้งเดียว เทียบกับ orch run --team standard (developer, tester, reviewer แต่ละตัวเป็นการเรียกแยก ใช้ prompt และ flag สิทธิ์ของ role ในตัว)

รัน	โทเค่น	ต้นทุน	เวลา	ถูกต้อง
เรียกครั้งเดียว	42,319	$0.2931	20 วิ	ใช่
--team standard	106,420	$0.8078	74 วิ	ใช่ (ทั้งสาม role สำเร็จ)
ทีม เทียบกับครั้งเดียว	2.5 เท่า	2.8 เท่า	3.7 เท่า

แยกตาม role: developer 42,744 โทเค่น ($0.2973), tester 41,688 ($0.2698), reviewer 21,988 ($0.2407) reviewer ใช้ context lean แต่เป็นการเรียกแรกที่ใช้ flag ชุดนั้นในรันนี้ cache จึงเย็น ต้นทุนจึงสูงกว่าการเรียก lean ที่ cache อุ่น

สิ่งที่การเรียกเพิ่มได้มา: reviewer ตรวจ test ที่สร้างเทียบกับโค้ดจริง รวมถึงเคสขอบเขตของ clamp (< และ > แบบเข้มงวด) ไม่พบบั๊ก และบอกว่าโปรเจกต์ไม่มี dependency vitest การรัน test ต้องดาวน์โหลดก่อน คำตอบเต็มของแต่ละ role ถูกบันทึกไว้ที่ .orch/runs/<run-id>/ (พร้อม .gitignore ที่เขียนว่า *)

อ่านผลอย่างตรงไปตรงมา กับงานเล็กขนาดนี้ สาม role ราคาประมาณสามเท่าของการเรียกครั้งเดียว และส่วนใหญ่แค่ยืนยันสิ่งที่การเรียกครั้งเดียวทำไปแล้ว role คุ้มกับงานที่ควรมีสายตาคู่ที่สอง: การแก้ใหญ่ บริเวณเสี่ยง โค้ดที่คุณจะไม่อ่านทีละบรรทัด งานแก้เล็กให้เรียกครั้งเดียว (และเลือก model กับ context preset จากการทดลองข้างบน) หนึ่งรันของหนึ่งงาน ให้ถือตัวคูณเป็นแนวทางคร่าวๆ

การทดลอง G: role สร้างภาพและการเลือกอัตโนมัติ

designer บน Codex orch run --role designer "Design a simple login screen mockup..." สร้าง login-screen-mockup.svg (1,995 ไบต์ เป็น SVG ที่ถูกต้อง มีชื่อเรื่อง ฟอร์มกึ่งกลาง ช่องอีเมลและรหัสผ่าน และปุ่ม Sign in) ไว้ใต้ .orch/runs/<run-id>/assets/ และ orch run แสดงรายการไว้ในส่วน assets: ใช้เวลา 23 วินาที และ 21,200 billable tokens (input 19,989, output 1,211) บวก input ที่อ่านจาก cache อีก 110,592 การทดสอบก่อนหน้าที่ขอโลโก้ PNG วาดด้วย Pillow และใช้ input รวมราว 121,000 โทเค่น จึงควรคาดว่าราว 100,000–130,000 โทเค่น input (ส่วนใหญ่เป็น cache) ต่อ role สร้างภาพบนเครื่องนี้ Codex เลือกรูปแบบไฟล์เอง (SVG ที่นี่ PNG ในการทดสอบ) ถ้ารูปแบบสำคัญให้ระบุใน prompt ของ role

การเลือกอัตโนมัติ orch run --auto กับงาน "เขียน test เล็ก" เลือก developer และ tester (จากคำว่า test) ใช้ 84,989 โทเค่น และ $0.5889 (developer $0.2927, tester $0.2962) ใน 40 วินาที และสร้างไฟล์ test แล้ว งานเดียวกันเรียกครั้งเดียวราคา $0.2931 และทีม standard (สาม role) $0.8078 auto ไม่ได้เพิ่ม reviewer เพราะ prompt ไม่มีคำที่ขอ เช่นเดียวกับทุกทีม role ที่เพิ่มมาทำให้ราคาเป็นประมาณสองเท่าของการเรียกครั้งเดียว

ข้อจำกัด: อย่างละหนึ่งรัน ผลภาพคือสิ่งที่ model วาด ไม่ใช่การวัดคุณภาพการออกแบบ

การทดลอง H: role อ่านอย่างเดียวรันขนาน

reviewer และ security ตรวจการเปลี่ยนแปลง login ที่ยังไม่ commit ชุดเดียวกัน (SQL ที่ต่อสตริง และรหัสผ่านที่เขียนลง log) รันขนาน (ค่าเริ่มต้น) เทียบกับ --sequential สลับลำดับระหว่างรอบ

รัน	เวลาจริง	โทเค่น	ต้นทุน
ขนาน รอบ 1	73 วิ	46,021	$0.5838
ทีละตัว รอบ 1	69 วิ	42,083	$0.4082
ทีละตัว รอบ 2	82 วิ	44,491	$0.4383
ขนาน รอบ 2	31 วิ	38,841	$0.3588
ขนาน ตรวจเวลาเพิ่ม 2 รัน	37 วิ และ 36 วิ

เวลาจริงเฉลี่ย: 44 วินาทีแบบขนาน (จากสี่รันที่ขนาน) เทียบ 76 วินาทีแบบทีละตัว (สองรัน) เร็วขึ้นราว 1.7 เท่า ในการตรวจเพิ่มสองรัน ledger แสดงว่าทั้งสอง role เริ่มพร้อมกัน (offset 0.0 วินาที) และจบที่ 24 กับ 37 วินาที และ 28 กับ 36 วินาที: รันใช้เวลาเท่ากับ role ที่ช้ากว่า ส่วนทีละตัวจะใช้ผลรวม (ราว 61 และ 64 วินาที) ทุกรันสำเร็จและทั้งสอง role รายงาน ok

อ่านผลอย่างตรงไปตรงมา การเร็วขึ้นเกิดขึ้นจริงในหลักการ (เห็นการซ้อนกันในไทม์ไลน์) แต่ตัวเลขแกว่ง: การรันขนานครั้งแรกใช้ 73 วินาที ไม่เร็วกว่าแบบทีละตัว น่าจะเป็น cache เย็นและความหน่วงของ API และต้นทุนต่อรันแกว่งระหว่าง $0.36 ถึง $0.58 สำหรับงานเดียวกัน ในหลักการ การรันขนานเปลี่ยนว่าการเรียกเกิดเมื่อไร ไม่ใช่จำนวนครั้ง ต้นทุนจึงควรใกล้เคียงเดิม ต้นทุนเฉลี่ยที่วัดได้คือ $0.47 แบบขนาน เทียบ $0.42 แบบทีละตัว (รันละสองครั้ง) ซึ่งต่างกันในช่วง noise การรันขนานครั้งแรกอ่าน input จาก cache มากกว่าแบบทีละตัวราวสองเท่า ซึ่งเข้ากับ prompt cache เย็นสองก้อนแทนที่จะเป็นก้อนอุ่นก้อนเดียว และประหยัดเวลาได้มากที่สุดเท่ากับเวลาของ role ที่สั้นกว่า

เอาข้อมูลนี้ไปทำอะไรต่อ

1. เพิ่ม rule เลือก model สำหรับงานเล็ก นี่คือการประหยัดที่วัดได้ชัด เริ่มจาก rule สำหรับ typo, rename, explain และ test เล็ก (ดู การตั้งค่า) ตรวจด้วย orch usage --by model และขยายเมื่อผลยังถูกต้อง
2. ใช้ค่าเริ่มต้นของ handoff ต่อไป ช่วยมากที่สุดเมื่อ failover ขณะมีการเปลี่ยนแปลงที่ยังไม่ commit ขนาดใหญ่
3. พิจารณาลบ summaryArgs ถ้า failover หลังล้มธรรมดาเกิดบ่อย และต้นทุนสำคัญกว่า context ที่เพิ่ม
4. ใช้ context preset กับงานเล็ก เพิ่ม context: lean ใน rule งานเล็กคู่กับ rule ของ model (การทดลอง E) hooks, plugins และ skills ระดับผู้ใช้ที่หนักถูกโหลดเข้าทุกการเรียกที่ orch ทำแทนคุณ lean ข้ามสิ่งเหล่านี้โดยยังคงคำสั่งของโปรเจกต์
5. ใช้ role กับการเปลี่ยนแปลงที่ควรมีสายตาคู่ที่สอง ไม่ใช่งานแก้เล็ก: ทีมสาม role แพงราว 2.8 เท่าของการเรียกครั้งเดียวในที่นี้ เริ่มด้วย --dry-run ดูจำนวนการเรียก และ orch usage --by role ดูว่าต้นทุนไปอยู่ที่ไหน
6. อย่าเชื่อการรันครั้งเดียว ใช้ orch usage สะสมหลายวัน ไม่ใช่เทียบครั้งเดียว

ข้อจำกัดของการศึกษานี้

• รันน้อยและเครื่องเดียว ผลขึ้นกับบัญชี แพ็กเกจ สถานะ cache และเวอร์ชัน CLI
• การประหยัดจาก model routing ขึ้นกับ model เริ่มต้นของคุณ ถ้าเริ่มต้นเป็น haiku อยู่แล้ว routing ไม่ประหยัดอะไร
• งานเล็ก 3 งาน ไม่ได้ทดสอบคุณภาพบนงานยากกว่านี้ และ model ที่ถูกกว่าแต่ต้องลองซ้ำจะแพงกว่า lean ก็เช่นกัน: งานที่ต้องใช้ hooks หรือ skills ระดับผู้ใช้ของคุณจะทำงานต่างไป
• Codex ไม่รายงานต้นทุนเป็นดอลลาร์ การทดลอง C จึงใช้โทเค่นอย่างเดียว
• ยังไม่ได้วัด: มูลค่าของการเลี่ยง rate limit กลางงาน ซึ่งต้องใช้การเลือกตามโควต้าที่วางแผนไว้ในขั้นต่อไป

รันซ้ำเอง

npm run build
npm run benchmark                                  # ทุกการทดลอง ใช้โทเค่นจริง หลักไม่กี่ดอลลาร์
npm run benchmark -- --only A,B                    # เฉพาะบางส่วน
npm run benchmark -- --only E                      # context preset
npm run benchmark -- --only F                      # roles: เรียกครั้งเดียวเทียบกับทีม
npm run benchmark -- --only G                      # role สร้างภาพและการเลือกอัตโนมัติ
npm run benchmark -- --only H                      # role อ่านอย่างเดียวขนานเทียบทีละตัว
npm run benchmark -- --only C --c-repeats 4 --skip-summary --out benchmarks/my-run.json

สคริปต์รันในสำเนาชั่วคราวของ repo ตัวอย่าง และเขียนระเบียน JSON หนึ่งรายการต่อรัน (โทเค่น ต้นทุน model ระยะเวลา และผลถูกต้องหรือไม่)