วิธีลดค่าใช้จ่ายโทเค็นเอเจนต์จาก CLI (คู่มือปี 2026)

เอเจนต์เขียนโค้ด CLI รู้สึกอิสระจนกระทั่งบิลมาถึง คุณชี้ Claude Code หรือ Codex ไปที่ repo ขอให้มันปรับโครงสร้างโมดูลใหม่ และสิบนาทีต่อมามันก็อ่านไฟล์ไปสี่สิบไฟล์ รันชุดทดสอบสามครั้ง และใช้โทเค็นจำนวนมากไปกับบริบทที่คุณไม่เคยต้องการให้มันเห็น คูณสิ่งนั้นด้วยทีมวิศวกรแปดคนที่รันเอเจนต์ตลอดทั้งวัน แล้วบิลก็จะไม่ใช่แค่ค่าผิดพลาดเล็กน้อยอีกต่อไป การใช้โทเค็นบนเอเจนต์เขียนโค้ดส่วนใหญ่เป็นความสิ้นเปลือง และความสิ้นเปลืองส่วนใหญ่นั้นสามารถแก้ไขได้จากบรรทัดคำสั่งโดยไม่ต้องเปลี่ยนโมเดลหรือยอมรับผลลัพธ์ที่แย่ลง

สรุปสั้นๆ (TL;DR)

ลดค่าใช้จ่ายโทเค็นของเอเจนต์โดยการตัดแต่งบริบทก่อนที่จะส่งไปยังโมเดล: จำกัดขอบเขตการทำงาน, เก็บไฟล์หน่วยความจำให้สั้น, และบีบอัดเซสชันที่ยาวนาน เปิดใช้การแคชพรอมต์สำหรับส่วนนำที่เสถียร (ลดค่าใช้จ่ายประมาณ 90% สำหรับการอ่านซ้ำ) ส่งงานย่อยราคาถูกไปยังโมเดลขนาดเล็ก จำกัดเอาต์พุตของเครื่องมือ วัดต้นทุนต่อการรันเพื่อให้คุณทราบว่ามีการเปลี่ยนแปลงอะไรไปบ้าง

บทนำ

ปัญหานี้ปรากฏขึ้นสองทาง ไม่ว่าคุณจะชนกำแพงกลางงานเพราะใช้เกินขีดจำกัดรายสัปดาห์หรือเซสชัน หรือบิล API รายเดือนมาถึงแล้วมีคนถามว่าทำไม "ผู้ช่วย AI" ถึงมีค่าใช้จ่ายมากกว่าผู้รับเหมา junior ทั้งสองกรณีมาจากสาเหตุเดียวกัน: เอเจนต์ CLI เป็นพวกหิวโทเค็นโดยค่าเริ่มต้น พวกมันอ่านทั้งไฟล์เมื่อต้องการเพียงสิบบรรทัด เล่นซ้ำการสนทนาทั้งหมดในทุกเทิร์น ทิ้งเอาต์พุตคำสั่งดิบกลับไปในบริบท และส่งพรอมต์ระบบและแผนผัง repo เดิมซ้ำแล้วซ้ำเล่าวันละหลายพันครั้ง

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

คู่มือนี้จะอธิบายว่าโทเค็นไปอยู่ที่ใดในการรันเอเจนต์ CLI จากนั้นจะให้กลยุทธ์ที่เป็นรูปธรรมเพื่อลดแต่ละส่วน: การดูแลบริบทและไฟล์หน่วยความจำ, การแคชพรอมต์, การกำหนดเส้นทางโมเดล, การตัดแต่งเอาต์พุตและการเรียกใช้เครื่องมือ, และการวัดต้นทุนต่อการรัน เพื่อให้การประหยัดเป็นจริงไม่ใช่แค่การคาดเดา ตัวอย่างนี้ใช้ Claude Code และ Codex เป็นหลัก แต่กลไกเหล่านี้สามารถใช้ได้กับเอเจนต์ใดๆ ที่สื่อสารกับ API ที่คิดค่าบริการตามโทเค็น

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

โทเค็นไปอยู่ที่ใดในการรันเอเจนต์ CLI จริงๆ

ก่อนที่คุณจะปรับให้เหมาะสม คุณต้องมีภาพในหัวเกี่ยวกับบิลค่าใช้จ่าย "เทิร์น" เดียวของเอเจนต์จะส่งเพย์โหลดอินพุตไปยังโมเดลและรับเพย์โหลดเอาต์พุตกลับมา คุณจ่ายสำหรับทั้งสองอย่าง และผู้ให้บริการส่วนใหญ่คิดค่าเอาต์พุตแพงกว่าอินพุตสามถึงหกเท่าต่อโทเค็น สำหรับโมเดลระดับแนวหน้าตระกูลหนึ่งในช่วงกลางปี 2026 อินพุตอยู่ที่ประมาณ $3 ต่อล้านโทเค็น และเอาต์พุตอยู่ที่ประมาณ $15; โมเดลที่ถูกกว่าในตระกูลเดียวกันอยู่ที่ประมาณ $1 อินพุต และ $5 เอาต์พุต ถือว่าสิ่งเหล่านี้เป็นตัวอย่าง ไม่ใช่ราคาที่อ้างอิงได้ โปรดตรวจสอบหน้าเว็บราคาปัจจุบัน เนื่องจากผู้ให้บริการอาจมีการแก้ไข ประเด็นโครงสร้างยังคงอยู่ไม่ว่าตัวเลขจะแน่นอนแค่ไหน: เอาต์พุตมีราคาแพง และปริมาณอินพุตคือสิ่งที่ทำให้ค่าใช้จ่ายสูงขึ้น

นี่คือสิ่งที่เติมเต็มเพย์โหลดอินพุตในการรันทั่วไป:

• พรอมต์ระบบและคำจำกัดความเครื่องมือ คำแนะนำของเอเจนต์และ JSON schema ของเครื่องมือทุกชิ้น คงที่ในแต่ละเทิร์น บ่อยครั้งอยู่ที่ 5,000 ถึง 15,000 โทเค็น ถูกส่งซ้ำในทุกๆ เทิร์น
• ไฟล์หน่วยความจำและโปรเจกต์ สิ่งต่างๆ เช่น CLAUDE.md, ข้อตกลงของ repo, และคำแนะนำถาวร ถูกโหลดทุกเทิร์นไม่ว่าจะเกี่ยวข้องหรือไม่ก็ตาม
• ประวัติการสนทนา ข้อความผู้ใช้ก่อนหน้าทุกข้อความ, การตอบสนองของโมเดล, การเรียกใช้เครื่องมือ, และผลลัพธ์ของเครื่องมือ ถูกเล่นซ้ำทั้งหมดในทุกเทิร์น สิ่งนี้จะเพิ่มขึ้นเรื่อยๆ โดยไม่มีขีดจำกัด และมักเป็นรายการค่าใช้จ่ายที่ใหญ่ที่สุดในเซสชันที่ยาวนาน
• เนื้อหาไฟล์ที่ดึงมา ไฟล์ที่เอเจนต์อ่าน การ Read ไฟล์ขนาด 1,200 บรรทัดเพียงครั้งเดียว มีค่าประมาณ 12,000 ถึง 18,000 โทเค็น และเอเจนต์ชอบที่จะอ่านทั้งไฟล์
• เอาต์พุตของเครื่องมือ บันทึกของ test runner, เสียงรบกวนจาก npm install, git diff ของ lockfile ที่สร้างขึ้น, stack traces เป็นค่าดิบและละเอียดโดยค่าเริ่มต้น

เพย์โหลดเอาต์พุตคือเหตุผลของโมเดล, การแก้ไขโค้ด, และคำอธิบาย มีขนาดเล็กกว่าอินพุตในการรันส่วนใหญ่ แต่มีราคาสูงที่สุดต่อโทเค็น ดังนั้นพฤติกรรมการอธิบายอย่างละเอียด "ให้ฉันอธิบายแผนของฉันในหกย่อหน้า" จึงมีค่าใช้จ่ายสูง

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

หากคุณต้องการเจาะลึกว่าการนับเซสชันและขีดจำกัดทำงานอย่างไรในทางปฏิบัติ รายละเอียดใน วิธีการรีเซ็ตหน้าต่างโทเค็นของ Claude Code เป็นข้อมูลเสริมที่เป็นประโยชน์สำหรับส่วนนี้ มันอธิบายว่าทำไมเซสชันที่ "รู้สึกสั้น" จึงยังคงใช้ทรัพยากรจนหมดได้

การดูแลบริบทและไฟล์หน่วยความจำ

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

กำหนดขอบเขตการทำงานก่อนเริ่ม อย่าเปิดเอเจนต์ที่ root ของ repo แล้วพูดว่า "ปรับโครงสร้างตรรกะการเรียกเก็บเงิน" มันจะทำงานช้า ให้ระบุไฟล์ที่เกี่ยวข้องอย่างชัดเจนแทน:

# แทนที่จะเป็นพรอมต์ที่คลุมเครือซึ่งกระตุ้นการสำรวจที่กว้างขวาง:
claude "refactor the retry logic so it uses exponential backoff,
only in src/payments/retry.ts and its test file"

การระบุชื่อไฟล์จะช่วยป้องกันไม่ให้เอเจนต์อ่านไฟล์ถึงยี่สิบไฟล์เพื่อหาไฟล์สองไฟล์ที่เกี่ยวข้อง หากคุณต้องปล่อยให้มันสำรวจ ให้ชี้ไปที่ไดเรกทอรี ไม่ใช่ root

เก็บไฟล์หน่วยความจำให้สั้นและเสถียร ไฟล์ CLAUDE.md (หรือไฟล์หน่วยความจำโปรเจกต์ที่เทียบเท่า) จะถูกโหลดเข้าสู่บริบทในทุกเทิร์น ทีมงานปฏิบัติต่อมันเหมือนวิกิและปล่อยให้มันเติบโตจนมีเนื้อหาสำหรับการเริ่มต้นใช้งานถึง 4,000 โทเค็น สมมติว่ามีการทำงาน 50 เทิร์นต่อวันสำหรับวิศวกร 8 คน ไฟล์หน่วยความจำที่ใหญ่เกินไปจะถูกส่งซ้ำหลายร้อยครั้งต่อวันโดยไม่มีประโยชน์เพิ่มเติม ตรวจสอบมัน:

# การตรวจสอบโทเค็นโดยประมาณในไฟล์หน่วยความจำของคุณ (อักขระ / 4 เป็นค่าประมาณที่ดี):
wc -c CLAUDE.md | awk '{print "≈", int($1/4), "tokens per turn"}'

ตั้งเป้าที่จะให้ไฟล์กระชับ: คำสั่ง build/test, ข้อกำหนดที่เข้มงวด, และตัวชี้ไปยังตำแหน่งเอกสารเชิงลึก ไม่ใช่ตัวเอกสารเอง หากส่วนใดส่วนหนึ่งเกี่ยวข้องกับงานเพียงงานเดียวต่อเดือน ไม่ควรอยู่ในไฟล์ที่ถูกโหลดตลอดเวลา ย้ายไปไว้ในเอกสารที่เอเจนต์อ่านเมื่อจำเป็น

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

# ใน Claude Code เมื่อการสนทนายาวนาน:
/compact     # สรุปประวัติลงในบทสรุปสั้นๆ และทิ้งประวัติแบบดิบ
# หรือ สำหรับการเริ่มต้นใหม่ในงานใหม่:
/clear       # เริ่มต้นใหม่ บริบทเก่าจะไม่ถูกส่งซ้ำอีกต่อไป

โดยทั่วไป /compact จะแทนที่ประวัติแบบดิบหลายหมื่นโทเค็นด้วยบทสรุปที่มีขนาดเหลือเพียงหนึ่งในสิบ และส่วนนำหน้าที่เล็กลงนั้นคือสิ่งที่ทุกเทิร์นที่ตามมาจะพกพาไป หลักปฏิบัติง่ายๆ: หนึ่งงานตรรกะต่อหนึ่งเซสชัน บีบอัดหรือล้างข้อมูลระหว่างงาน รูปแบบเวิร์กโฟลว์ใน เวิร์กโฟลว์ของ Claude Code พึ่งพานิสัยการกำหนดขอบเขตนี้อย่างมาก และควรนำมาใช้ทั้งหมด

ใช้ไฟล์ ignore ของโปรเจกต์ เก็บไฟล์ที่สร้างขึ้น, lockfiles, เอาต์พุตการ build, และ dependency ที่รวมมาออกจากขอบเขตการทำงานของเอเจนต์ หากเอเจนต์ไม่เคยเห็น dist/ หรือ node_modules/ มันก็จะไม่เสียโทเค็นในการอ่านหรือเปรียบเทียบไฟล์เหล่านั้น เอเจนต์ส่วนใหญ่จะเคารพไฟล์ ignore; กำหนดค่าเพียงครั้งเดียวและการประหยัดก็จะคงอยู่ถาวร

การแคชพรอมต์: หยุดจ่ายราคาเต็มสำหรับส่วนนำหน้าเดิมๆ

นี่คือปัจจัยที่สำคัญที่สุดสำหรับการรันซ้ำๆ และมันเป็นกลไกมากกว่าพฤติกรรม การแคชพรอมต์ช่วยให้ผู้ให้บริการจัดเก็บส่วนนำหน้าของคำขอของคุณ (เครื่องมือ, พรอมต์ระบบ, บริบทที่เสถียร) เพื่อให้คำขอถัดไปที่ใช้ส่วนนำหน้านั้นสามารถอ่านกลับมาได้ในราคาที่ลดลงอย่างมาก แทนที่จะต้องประมวลผลใหม่

เศรษฐศาสตร์ ตามเอกสารการแคชพรอมต์ของ Anthropic: การเขียนแคชมีค่าใช้จ่ายสูงกว่าโทเค็นอินพุตปกติ (ประมาณ 1.25 เท่าของอินพุตพื้นฐานสำหรับแคช 5 นาทีเริ่มต้น, ประมาณ 2 เท่าสำหรับแคช 1 ชั่วโมง) แต่การอ่านแคชมีค่าใช้จ่ายประมาณ 0.1 เท่าของอินพุตพื้นฐาน นั่นคือส่วนลดประมาณ 90% สำหรับส่วนที่แคช เนื่องจากการเขียนเพิ่มเติมมีค่าน้อยและส่วนลดการอ่านมีมาก การแคชจึงคุ้มทุนหลังจากแคชฮิตเพียงครั้งเดียวบนแคชที่มีอายุสั้น และหลังจากประมาณสองครั้งบนแคชที่มีอายุยาวนาน อายุการใช้งานแคชเริ่มต้นสั้น (ประมาณ 5 นาที, รีเฟรชทุกครั้งที่มีการเรียกใช้) โดยมีตัวเลือก 1 ชั่วโมงให้เลือก มีขนาดแคชขั้นต่ำ โมเดลขนาดเล็กและโมเดลที่ใหญ่ที่สุดต้องใช้โทเค็นหลายพันโทเค็นก่อนที่ส่วนนำหน้าจะมีสิทธิ์แคช ดังนั้นการแคชจึงช่วยได้มากที่สุดในจุดที่สำคัญที่สุด: ส่วนนำหน้าที่มีขนาดใหญ่และเสถียร

กฎโครงสร้างคือการวางเนื้อหาที่เสถียรไว้ก่อนและเนื้อหาที่เปลี่ยนแปลงบ่อยไว้ทีหลัง จากนั้นแคชที่ขอบเขต ลำดับคือ เครื่องมือ → ระบบ → ข้อความ และการเปลี่ยนแปลงใดๆ จะทำให้ระดับนั้นและทุกสิ่งที่อยู่หลังจากนั้นไม่ถูกต้อง ดังนั้น คุณต้องการให้ timestamp, ข้อความเข้าของผู้ใช้, และเนื้อหาไฟล์ที่ดึงมาใหม่ อยู่หลังจุดพักแคชของคุณ ไม่ใช่ก่อนหน้านั้น

หากคุณขับเคลื่อนโมเดลโดยตรงจาก CLI wrapper ของคุณเอง คุณจะตั้งค่านี้อย่างชัดเจน:

# แคชส่วนนำหน้าที่มีความเสถียร (ระบบ + คำจำกัดความเครื่องมือ + ข้อตกลงของ repo)
# เทิร์นของผู้ใช้ที่เปลี่ยนแปลงบ่อยจะตามมาและไม่ได้เป็นส่วนหนึ่งของส่วนนำหน้าที่แคชไว้
response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=2048,
    system=[
        {
            "type": "text",
            "text": SYSTEM_PROMPT + REPO_CONVENTIONS,   # เสถียรตลอดการรัน
            "cache_control": {"type": "ephemeral"},       # จุดพักแคชที่นี่
        }
    ],
    messages=[{"role": "user", "content": user_task}],     # เปลี่ยนแปลงทุกครั้งที่รัน
)

# ตรวจสอบสิ่งที่ถูกแคชจริง:
u = response.usage
print("cache write:", u.cache_creation_input_tokens)
print("cache read :", u.cache_read_input_tokens)   # โทเค็นเหล่านี้ถูกเรียกเก็บเงิน ~10%
print("fresh input:", u.input_tokens)

เอเจนต์ปรับโครงสร้างรายวันที่รันพรอมต์ระบบและบล็อกข้อตกลงของ repo ขนาด 8,000 โทเค็นแบบเดียวกันถึง 60 ครั้งต่อวัน ถือเป็นกรณีตัวอย่างที่ชัดเจน หากไม่มีการแคช คุณจะต้องจ่ายค่าอินพุตเต็มราคาสำหรับบล็อก 8,000 โทเค็นนั้น 60 ครั้ง ด้วยการแคช คุณจะจ่ายค่าเขียนเพิ่มเติมเพียงครั้งเดียว (หรือหนึ่งครั้งต่อการหมดอายุแคช) และราคาอ่านประมาณ 10% ในครั้งอื่นๆ สำหรับบล็อกข้อตกลงเพียงอย่างเดียว นั่นคือการลดลงเกือบ 90% และสามารถใช้ร่วมกับกลยุทธ์อื่นๆ ในที่นี้ได้

ข้อสังเกตในการปฏิบัติงานสองประการ ประการแรก รักษา prefix ของคุณให้ byte-stable; การเปลี่ยนแปลงอักขระเพียงตัวเดียวก่อนจุดพักจะทำให้แคชเสียและคุณจะต้องจ่ายค่าเขียนอีกครั้ง ตรึงพรอมต์ระบบและข้อตกลงของคุณไว้; อย่าใส่ timestamp ลงไปในนั้น ประการที่สอง แคชมีอายุสั้นโดยค่าเริ่มต้น ดังนั้นการจัดกลุ่มการรันที่เกี่ยวข้องเข้าด้วยกัน (แทนที่จะกระจายไปตลอดทั้งวัน) จะช่วยให้คุณเข้าถึงแคชที่ "อุ่น" อยู่เสมอ API ของ OpenAI ใช้ส่วนลดที่คล้ายกันสำหรับอินพุตที่แคชโดยอัตโนมัติบนโมเดลที่รองรับ หลักการเหมือนกันแม้ว่ารายละเอียดจะแตกต่างกัน เทคนิค free-tier และการกำหนดเส้นทางใน การรัน GPT-5.5 ฟรีผ่าน Codex เป็นส่วนเสริมที่มีประโยชน์เมื่อการแคชอย่างเดียวไม่เพียงพอ

การกำหนดเส้นทางโมเดล: โมเดลราคาถูกสำหรับงานราคาถูก

ไม่ใช่ทุกการกระทำของเอเจนต์ที่ต้องใช้โมเดลระดับแนวหน้า การเปลี่ยนชื่อตัวแปรในสามไฟล์, การเขียน commit message, การสรุป diff, หรือการสร้าง boilerplate test ไม่จำเป็นต้องใช้โมเดลเดียวกับที่ออกแบบสถาปัตยกรรม แต่พฤติกรรมเริ่มต้นของเอเจนต์ CLI ส่วนใหญ่คือการรันทุกอย่างผ่านโมเดลราคาแพงเพียงตัวเดียวตลอดทั้งเซสชัน

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

วิธีปฏิบัติในการกำหนดเส้นทางจาก CLI:

# 1. เลือกโมเดลต่อการเรียกใช้ตามงาน
claude --model haiku   "write a conventional-commit message for the staged diff"
claude --model sonnet  "redesign the caching layer for the payments service"

# 2. ใช้โมเดลราคาถูกสำหรับงานที่มีความถี่สูงและมีความเสี่ยงต่ำ
#    (commit message, รายการ changelog, คำอธิบาย lint ด่วน)
#    และโมเดลที่แข็งแกร่งเฉพาะเมื่อคุณเรียกใช้งานที่ยากอย่างชัดเจน

ตั้งค่าเริ่มต้นเป็นโมเดลที่ถูกกว่าและเพิ่มระดับอย่างมีสติ แทนที่จะตั้งค่าเริ่มต้นเป็นโมเดลราคาแพงและไม่เคยลดระดับลง ทีมส่วนใหญ่มีแนวคิดที่กลับกัน: พวกเขาใช้โมเดลหลักสำหรับทุกสิ่ง "เพื่อความปลอดภัย" และจ่ายแพงกว่าถึงห้าเท่าสำหรับ commit messages

แกนการกำหนดเส้นทางที่สองคือ sub-agents (เอเจนต์ย่อย) หากเฟรมเวิร์กเอเจนต์ของคุณรองรับการมอบหมายงานย่อยที่แคบให้กับ child agent (เอเจนต์ลูก) ให้ child agent นั้นใช้โมเดลราคาถูกและบริบทขนาดเล็ก child agent จะทำงานหนัก (ค้นหา, สรุป, ร่าง) ด้วยค่าใช้จ่ายเพียงเล็กน้อยและรายงานผลลัพธ์สั้นๆ กลับไปยัง parent agent (เอเจนต์แม่) ที่มีราคาแพง แทนที่จะให้ parent agent ที่มีราคาแพงทำงานหนักด้วยตัวเองในราคาเต็มพร้อมบริบทเต็ม รูปแบบ autonomous-loop ใน คำสั่ง goal ใน Codex และ Claude Code แสดงให้เห็นถึงวิธีการจัดโครงสร้างการมอบหมายดังกล่าว เพื่อให้โมเดลราคาแพงเห็นเฉพาะผลลัพธ์ที่กลั่นกรองแล้วเท่านั้น

ข้อสังเกตเกี่ยวกับขีดจำกัด ไม่ใช่แค่เรื่องเงินดอลลาร์ หากคุณใช้แผนที่มีการจำกัดการใช้งาน แทนที่จะเป็นแบบจ่ายตามการใช้งานจริง การกำหนดเส้นทางจะช่วยยืดระยะเวลาการใช้งานของคุณได้อีกด้วย การใช้จ่ายงบประมาณโมเดลพรีเมียมไปกับ commit messages คือสาเหตุที่ทำให้ทีมงานชนกำแพงได้ภายในวันพฤหัสบดี การ เพิ่มขีดจำกัดรายสัปดาห์ของ Claude Code ล่าสุดช่วยได้ แต่การกำหนดเส้นทางก็ยังคงเป็นสิ่งที่ทำให้การใช้งานยาวนานขึ้น

การตัดแต่งเอาต์พุตเครื่องมือและการดึงข้อมูล

เอาต์พุตของเครื่องมือคือตัวฆ่างบประมาณที่เงียบเชียบ เพราะมันมองไม่เห็นจนกว่าคุณจะมองหา ทุกคำสั่งที่เอเจนต์รันจะส่งคืนข้อความ และข้อความนั้นจะถูกส่งกลับไปยังบริบทโดยตรง ซึ่งจากนั้นจะถูกเล่นซ้ำในทุกเทิร์นถัดไป การเรียกใช้ npm install เพียงครั้งเดียวสามารถส่งคืนได้หลายพันบรรทัด การทดสอบที่เปิดการบันทึกแบบละเอียดสามารถส่งคืนได้หลายหมื่นโทเค็น git diff ที่รวม lockfile ที่สร้างขึ้นใหม่สามารถมีขนาดใหญ่มาก เอเจนต์ไม่ค่อยต้องการทั้งหมดนั้น มันต้องการแค่ผลลัพธ์ผ่าน/ไม่ผ่านและความล้มเหลวที่เกี่ยวข้อง

กลยุทธ์ที่ช่วยลดสิ่งนี้ได้อย่างมีประสิทธิภาพ:

ทำให้คำสั่งเงียบที่ต้นทาง เอเจนต์จ่ายสำหรับทุกสิ่งที่คำสั่งพิมพ์ออกมา กำหนดค่าเครื่องมือให้สั้นกระชับ:

# ดัง (เอเจนต์จ่ายสำหรับทุกบรรทัด):
npm test

# เงียบ (เฉพาะความล้มเหลวและสรุปกลับมา):
npm test --silent -- --reporter=dot

# ดัง:
npm install

# เงียบ:
npm install --silent --no-audit --no-fund

กรองก่อนที่เอเจนต์จะเห็น เมื่อคุณควบคุมคำสั่งที่เอเจนต์รัน ให้ส่งเสียงรบกวนออกไป เพื่อให้เหลือเพียงสัญญาณที่ต้องการกลับมา:

# เฉพาะบรรทัดที่สำคัญเท่านั้นที่จะกลับมาอยู่ในบริบท:
pytest -q 2>&1 | tail -n 30

# สถิติ Diff แทนที่จะเป็น full diff 4,000 บรรทัด:
git diff --stat

# Grep หาความล้มเหลวแทนที่จะ dump บันทึกทั้งหมด:
npm test 2>&1 | grep -E "(FAIL|✗|Error)" | head -n 20

เลือกการอ่านแบบเจาะจงมากกว่าการอ่านทั้งไฟล์ การอ่านไฟล์ 1,500 บรรทัดเพื่อเปลี่ยนฟังก์ชันเดียวเป็นความสิ้นเปลืองโดยเปล่าประโยชน์ กระตุ้นให้เอเจนต์ grep หาสัญลักษณ์และอ่านเฉพาะส่วนรอบๆ ไม่ใช่ทั้งไฟล์ เอเจนต์หลายตัวทำเช่นนี้เมื่อพรอมต์กระตุ้น ("ค้นหาและอ่านเฉพาะฟังก์ชันที่จัดการการลองใหม่ ไม่ใช่ทั้งไฟล์") สำหรับไฟล์ขนาดใหญ่ นั่นคือความแตกต่างระหว่าง ~18,000 โทเค็นและ ~800 โทเค็น

จำกัดขอบเขตการดึงข้อมูล หากเอเจนต์ของคุณทำการค้นหาโค้ดเบสหรือ RAG บนเอกสาร ให้จำกัดจำนวนส่วนที่ดึงกลับมาและขนาดของส่วนเหล่านั้น ข้อความสั้นๆ 200 โทเค็นจำนวนสิบชิ้นที่ตอบคำถามได้ดีกว่าข้อความสั้นๆ 800 โทเค็นจำนวนห้าสิบชิ้นที่ทำให้สับสน คุณจ่ายสำหรับโทเค็นที่ดึงมาทั้งหมด ไม่ว่าโมเดลจะใช้หรือไม่ก็ตาม

การเปลี่ยนแปลงเหล่านี้ส่วนใหญ่เป็นการกำหนดค่าเพียงครั้งเดียว (test reporters, install flags, ไฟล์ ignore) และจะให้ผลตอบแทนในการรันทุกครั้งตลอดไป ซึ่งทำให้สิ่งเหล่านี้เป็นหนึ่งในการลงทุนที่ให้ผลตอบแทนสูงสุดในรายการทั้งหมดนี้

การวัดและจัดสรรต้นทุนต่อการรัน

คุณไม่สามารถบริหารจัดการสิ่งที่คุณไม่ได้วัดผลได้ และ "บิลลดลง" ไม่ใช่การวัดผล เพื่อให้รู้ว่ากลยุทธ์ได้ผลหรือไม่ คุณต้องมีต้นทุนที่จัดสรรให้กับการรัน โดยเฉพาะอย่างยิ่งกับงาน

เริ่มต้นด้วยข้อมูลที่ API ให้คุณอยู่แล้ว ทุกการตอบสนองมีอ็อบเจกต์การใช้งาน เก็บข้อมูลนั้น:

u = response.usage
# ต้นทุนโดยประมาณเป็นดอลลาร์; แทนที่ด้วยอัตราปัจจุบันสำหรับโมเดลของคุณ
INPUT_RATE  = 3.00 / 1_000_000     # อินพุตพื้นฐาน $/โทเค็น (ตัวอย่าง)
OUTPUT_RATE = 15.00 / 1_000_000    # เอาต์พุต $/โทเค็น (ตัวอย่าง)
CACHE_READ  = 0.30 / 1_000_000     # ~10% ของอินพุตพื้นฐาน
CACHE_WRITE = 3.75 / 1_000_000     # ~1.25 เท่าของอินพุตพื้นฐาน (แคช 5 นาที)

cost = (
    u.input_tokens          * INPUT_RATE  +
    u.output_tokens         * OUTPUT_RATE +
    u.cache_read_input_tokens  * CACHE_READ +
    u.cache_creation_input_tokens * CACHE_WRITE
)
print(f"run cost ≈ ${cost:.4f}  "
      f"(in={u.input_tokens} out={u.output_tokens} "
      f"cr={u.cache_read_input_tokens})")

หากคุณใช้ Agent CLI แทน wrapper ของคุณเอง มีสามวิธีที่ใช้ได้:

# 1. CLI ของเอเจนต์ส่วนใหญ่จะมีคำสั่ง usage/cost สำหรับเซสชัน
#    ตรวจสอบหลังจากงานที่เป็นตัวแทนแล้วจดตัวเลขไว้
claude /cost

# 2. คอนโซลของผู้ให้บริการรายงานค่าใช้จ่ายต่อคีย์ API ออกคีย์ API เฉพาะ
#    สำหรับแต่ละเอเจนต์หรือแต่ละโปรเจกต์ เพื่อให้สามารถระบุที่มาของค่าใช้จ่ายได้
#    แทนที่จะรวมกันเป็นยอดรวมที่ไม่สามารถติดตามได้

# 3. ติดแท็กรัน ห่อการเรียกใช้เอเจนต์ในสคริปต์ที่บันทึก
#    timestamp, task label, และจำนวนโทเค็นที่รายงานลงในไฟล์ CSV
#    CSV หนึ่งสัปดาห์จะบอกคุณว่างานใดมีค่าใช้จ่ายสูง

ประเมินก่อนที่คุณจะรันงานขนาดใหญ่ วางพรอมต์และไฟล์ที่คุณตั้งใจจะรวมลงใน tokenizer (tokenizer สาธารณะของ OpenAI เป็นวิธีที่รวดเร็วในการตรวจสอบขนาด) และดูจำนวน หาก "รวมทั้งโมดูล" คือ 90,000 โทเค็น และเวอร์ชันที่กำหนดเป้าหมายคือ 6,000 โทเค็น คุณก็เห็นการตัดสินใจแล้วก่อนที่จะจ่ายเงินสำหรับมัน

ติดตามตัวเลขหนึ่งตัวต่องานที่เป็นตัวแทนตลอดเวลา: ต้นทุนต่อ "การรันปรับโครงสร้างรายวัน", ต้นทุนต่อ "การรันรีวิว PR" เมื่อคุณเปิดการแคชหรือเปลี่ยนงานย่อยไปใช้โมเดลราคาถูก ตัวเลขนั้นควรจะเปลี่ยนไป หากไม่เป็นเช่นนั้น กลยุทธ์ที่ใช้อาจไม่ได้ผลอย่างที่คุณคิด และคุณก็ได้เรียนรู้เรื่องนั้นในราคาของการรันเพียงครั้งเดียว แทนที่จะเป็นค่าใช้จ่ายหนึ่งเดือน

การเปรียบเทียบกลยุทธ์

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

บทสรุป

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

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