SSD Nodes Learn
คู่มือ Matt Connorโดย Matt Connor · อัปเดตเมื่อ 2026-07-24

วิธีแก้ Claude Code ทำงานช้าและเปลืองค่าใช้จ่าย

ลดค่าใช้จ่ายและเพิ่มความเร็วใน Claude Code ด้วยการจัดการ context โดยใช้คำสั่ง /context เพื่อตรวจสอบข้อมูล และใช้เทคนิคการลบหรือบีบอัดข้อมูลเพื่อลด token

วิธีป้องกันไม่ให้ Claude Code session ที่ใช้งานนานเกินไปทำงานช้าลงและสิ้นเปลืองค่าใช้จ่าย

Claude Code session ที่ใช้งานนานจะทำงานช้าลงและสิ้นเปลืองค่าใช้จ่ายมากขึ้น เนื่องจากทุกการตอบโต้จะมีการส่ง context ทั้งหมดกลับไปใหม่ และ context นั้นจะมีขนาดใหญ่ขึ้นเรื่อยๆ วิธีแก้ไขคือการจัดการข้อมูลตามลำดับขั้นตอน ให้รัน /context เพื่อตรวจสอบข้อมูลที่ค้างอยู่ในหน้าต่างสนทนา จากนั้นให้ลบรายการที่ต้องเสียค่าใช้จ่ายในการส่งซ้ำทุกครั้ง แล้วใช้ /clear เมื่อต้องการเปลี่ยนไปทำงานอื่นที่ไม่เกี่ยวข้องกัน และใช้ /compact พร้อมคำสั่งภายในงานเดียวที่ต่อเนื่องกัน ควรทำงานเป็นช่วงๆ อย่างต่อเนื่อง เพราะหาก prompt cache ถูกล้าง ข้อมูลที่เคยอ่านแบบประหยัดจะกลายเป็นการเขียนใหม่ทั้งหมดจากสิ่งที่คุณเคยพิมพ์ไว้

สาเหตุที่ต้องมีการนับจำนวน token คือ การทำงานของ token meter เบื้องหลัง agent session

อ่าน /context ก่อนทำการเปลี่ยนแปลงใดๆ

ห้ามคาดเดาข้อมูลที่อยู่ในหน้าต่างแสดงผล Claude Code จะแจ้งข้อมูลให้ทราบ

/context [all] แสดงการใช้งาน context ปัจจุบันในรูปแบบตารางสี พร้อมคำแนะนำในการปรับปรุงสำหรับเครื่องมือที่ใช้ context จำนวนมากและปัญหาหน่วยความจำบวม; all แสดงรายละเอียดแยกตามรายการในโหมด fullscreen ข้อมูลที่แสดงจะแบ่งออกเป็น 5 ส่วน

  • The system prompt. คำสั่งพื้นฐานของ Claude Code ซึ่งจะถูกกำหนดไว้คงที่ตลอดการใช้งานใน session นั้น
  • Tool definitions. โครงสร้างข้อมูล (schema) ของทุกเครื่องมือที่ agent สามารถเรียกใช้ได้ รวมถึงทุก MCP (Model Context Protocol) server ที่เชื่อมต่ออยู่
  • Memory files. CLAUDE.md และ auto memory ซึ่งจะถูกโหลดเมื่อเริ่ม session
  • Files and tool results. ไฟล์ทุกไฟล์ที่ถูกอ่าน และผลลัพธ์ทั้งหมดที่แสดงจากการรันคำสั่งของคุณ
  • Message history. ข้อความที่คุณส่งและข้อความตอบกลับจากระบบ

สามส่วนแรกคือค่าใช้จ่ายคงที่ (fixed tax) ที่ต้องจ่ายในทุกการร้องขอตลอดอายุการใช้งานใน session นั้น ส่วนสองส่วนสุดท้ายจะเพิ่มขึ้นตามการใช้งาน จงลดค่าใช้จ่ายคงที่เพียงครั้งเดียวเมื่อเริ่มใช้งาน และจัดการส่วนที่เพิ่มขึ้นอย่างต่อเนื่อง

ข้อความสองรูปแบบจะแจ้งให้ทราบเมื่อหน้าต่างแสดงผลเต็ม:

Context exceeds the 200k-token limit by 94k tokens — run /compact or /clear to continue.
Context is 94k tokens past the 200k-token compaction window — run /compact to reduce usage.

รูปแบบแรกคือขีดจำกัดสูงสุด (hard limit) ซึ่งจะทำให้การร้องขอถูกปฏิเสธ โดยจะปรากฏ error ของ API ที่สอดคล้องกันคือ Prompt is too long รูปแบบที่สองคือหน้าต่างการบีบอัดข้อมูล (compaction window) ซึ่งอาจมีขนาดเล็กกว่า context window จริงของโมเดล (เช่น ในโมเดลขนาด 1 million token) การร้องขอยังคงสำเร็จแม้จะเกินขีดจำกัดนี้ ดังนั้นรูปแบบที่สองจึงเป็นเพียงการแจ้งเตือนไม่ใช่การปฏิเสธการทำงาน

สำหรับแผนแบบชำระเงิน /usage จะแสดงข้อมูลอีกครึ่งหนึ่ง โดยจะระบุพฤติกรรมต่างๆ เช่น การใช้ context จำนวนมาก หรือ cache misses และระบุการใช้งานล่าสุดไปยังทักษะ (skills), subagents และ MCP servers แต่ละตัว

CLAUDE.md คือภาระที่ต้องจ่ายตลอดเวลา ดังนั้นควรทำให้มีขนาดเล็กที่สุด

CLAUDE.md จะถูกโหลดเข้าสู่ context เมื่อเริ่ม session และจะคงอยู่ตลอดไป หากไฟล์นี้มีขั้นตอนการ deploy ที่ละเอียดเกินไป จะทำให้สิ้นเปลือง token แม้ในขณะที่คุณเพียงแค่แก้ไขคำผิดใน test file Anthropic แนะนำให้ใส่เฉพาะข้อมูลที่จำเป็นและควรรักษาความยาวไฟล์ให้ไม่เกิน 200 lines

ควรย้ายขั้นตอนการทำงาน (procedures) ไปไว้ใน skills เนื่องจาก skill จะถูกโหลดเมื่อมีการเรียกใช้งานเท่านั้น ดังนั้น workflow ที่คุณใช้งานเพียง 2 ครั้งต่อสัปดาห์จึงไม่เสีย token ในวันอื่น Skills มี budget ของตัวเองหลังจากผ่านกระบวนการ compaction โดยจะมีการ re-inject เนื้อหาใหม่ แต่จำกัดไว้ที่ 5,000 tokens ต่อหนึ่ง skill และรวมทั้งหมดไม่เกิน 25,000 tokens โดยข้อมูลที่เก่าที่สุดจะถูกลบออกก่อน การตัดข้อมูล (truncation) จะรักษาเนื้อหาช่วงต้นไฟล์ไว้ ดังนั้นควรวางคำสั่งที่สำคัญที่สุดไว้ที่ส่วนบนของ SKILL.md

ข้อมูลที่ยังคงอยู่หลังการ compaction จะเป็นตัวกำหนดว่าคำสั่งควรอยู่ที่ใด

  • system prompt และ output style จะไม่มีการเปลี่ยนแปลง เนื่องจากไม่ได้เป็นส่วนหนึ่งของ message history
  • project-root CLAUDE.md, unscoped rules และ auto memory จะถูก re-inject จาก disk
  • rule ที่มี frontmatter แบบ paths: จะหายไปจนกว่าจะมีการอ่านไฟล์ที่ตรงกันอีกครั้ง
  • CLAUDE.md ที่ซ้อนอยู่ใน subdirectory จะหายไปจนกว่าจะมีการอ่านไฟล์ใน subdirectory นั้นอีกครั้ง
  • Hooks จะไม่ได้รับผลกระทบ เนื่องจาก hook ทำงานในรูปแบบ code และไม่ถูกนำเข้าสู่ context

ดังนั้น rule ที่คุณจำเป็นต้องใช้ควรอยู่ใน project-root CLAUDE.md เนื่องจาก Claude Code จะล้าง output ของ tool ที่เก่าที่สุดก่อนแล้วจึงทำการ summarize ทำให้คำสั่งในช่วงต้นของการสนทนาอาจสูญหายได้ สามารถแก้ไข memory ได้ด้วย /memory Claude Code จะเก็บสำเนาที่โหลดตอนเริ่ม session ไว้ ดังนั้นการตัดข้อมูลระหว่าง session จะยังคงรักษา prompt cache ไว้ และจะมีผลเมื่อมีการเรียก /clear, /compact หรือการ restart ครั้งถัดไปเท่านั้น

/clear ระหว่างงาน, /compact ภายในงานเดียว

คำสั่งทั้งสองนี้ดูเหมือนใช้งานแทนกันได้ แต่มีค่าใช้จ่ายต่างกันมาก

/clear [name] เริ่มการสนทนาใหม่ด้วย context ที่ว่างเปล่า คำสั่งนี้ไม่มีการส่ง request จึงไม่มีค่าใช้จ่าย คุณสามารถระบุชื่อเพื่อติดป้ายกำกับการสนทนาก่อนหน้าใน /resume picker โดย /reset และ /new คือคำสั่งที่ใช้แทนกันได้ ควรใช้คำสั่งนี้ทันทีเมื่อเปลี่ยนไปทำงานอื่นที่ไม่เกี่ยวข้อง มิฉะนั้นงานเดิมจะถูกส่งซ้ำและถูกคิดเงินใหม่ในทุกข้อความของการทำงานใหม่

/compact [instructions] ช่วยคืนพื้นที่ context ในขณะที่ยังคงการสนทนาเดิมไว้ โดยจะทำการสรุปประวัติการสนทนาที่ผ่านมาและแทนที่ข้อมูลเดิม ใช้คำสั่งนี้ภายในงานเดียวที่มีความยาวมากและยังต้องการความต่อเนื่อง

ต้องระบุคำสั่ง (instruction) ให้กับ /compact เสมอ การใช้ /compact เพียงอย่างเดียวจะใช้ prompt เริ่มต้นซึ่งไม่ทราบว่าคุณต้องการเน้นส่วนใดของงานต่อ แต่การระบุคำสั่งจะช่วยรักษาเนื้อหาที่สำคัญไว้:

/compact focus on the auth bug fix
/compact keep only the plan and the diff

หากคุณต้องการ compact ด้วยเหตุผลเดิมทุกครั้ง ให้ใส่คำสั่งถาวรไว้ใน CLAUDE.md ของโปรเจกต์ ภายใต้หัวข้อ # Compact instructions ใน session ใหม่ /compact จะแสดงผล Not enough messages to compact. ซึ่งหมายความว่ายังไม่มีประวัติการสนทนา

ค่าใช้จ่ายสองส่วนนี้มักถูกเข้าใจผิด การส่ง request เพื่อสรุปเนื้อหาจะใช้ prefix ร่วมกับคุณ ดังนั้นระบบจะอ่านจาก cache ที่มีอยู่แทนการประมวลผลประวัติใหม่ และเวลาส่วนใหญ่จะใช้ไปกับการสร้างสรุป การ compact context ขนาดใหญ่ยังคงเป็นการ request ขนาดใหญ่ เนื่องจากประวัติการสนทนาที่ถูกสรุปคือ input อย่างไรก็ตาม ขั้นตอนหลังจาก compact จะไม่ช้า เพราะระบบจะสร้าง cache ใหม่สำหรับ prompt ที่สั้นลงมาก

มีคำสั่งที่ราคาถูกกว่าสองคำสั่ง คือ /rewind [description] จะย้อนกลับ code และการสนทนาไปยังจุด checkpoint สำหรับเส้นทางที่คุณต้องการยกเลิกโดยสิ้นเชิง คำสั่งนี้ดีกว่าการ compact เพราะจะตัดข้อมูลกลับไปยัง prefix ที่อยู่ใน cache แล้ว ส่วน /recap จะเพิ่มสรุปต่อท้ายเป็น output ของคำสั่งแทนการแทนที่ประวัติเดิม ทำให้ prefix ใน cache ยังคงอยู่ครบถ้วน

หากมีการสั่ง compact อัตโนมัติซ้ำๆ จะแสดงผลดังนี้:

Autocompact is thrashing: the context refilled to the limit...

Compaction สำเร็จ แต่มีไฟล์หรือ output จาก tool ที่มีขนาดใหญ่เกินไปเติมเข้ามาในหน้าต่างหลายครั้งติดต่อกัน Claude Code จึงหยุดพยายามใหม่ วิธีแก้ไขคือให้อ่านไฟล์ที่มีขนาดใหญ่เกินไปโดยแบ่งเป็นช่วงบรรทัด (line ranges), รัน /compact โดยระบุ focus เพื่อตัด output ขนาดใหญ่ออก, ส่งงานนั้นไปให้ subagent หรือใช้ /clear หากการสนทนาก่อนหน้าเสร็จสิ้นแล้ว

MCP servers มีค่าใช้จ่ายคงที่ (fixed overhead)

MCP server ทุกตัวที่เชื่อมต่อจะเพิ่มภาระให้กับทุก request ตลอดทั้ง session คุณต้องเสียทรัพยากรไม่ว่าจะเรียกใช้งานหรือไม่ก็ตาม

Claude Code ช่วยลดปัญหานี้ โดยค่าเริ่มต้นจะมีการหน่วงการส่ง MCP tool definitions ไว้ ทำให้มีเพียงชื่อ tool เท่านั้นที่ถูกส่งเข้าไปใน context จนกว่า Claude จะเรียกใช้ tool นั้นๆ จริงๆ ใช้คำสั่ง /context เพื่อตรวจสอบทรัพยากรที่ server ของคุณใช้จริง และใช้ /mcp disable <name> เพื่อยกเลิกการเชื่อมต่อ server ที่คุณไม่ได้ใช้งานในวันนี้ หากคุณรัน your own MCP servers on a VPS ข้อจำกัดทางคณิตศาสตร์แบบเดียวกันนี้จะใช้เพื่อกำหนดจำนวน tool ที่ server หนึ่งตัวควรเปิดให้ใช้งาน

ควรดำเนินการนี้เมื่อเริ่มต้น session แม้ว่าการหน่วงการส่ง definition จะช่วยลดภาระ แต่การเชื่อมต่อหรือยกเลิกการเชื่อมต่อ server จะเป็นการเพิ่มข้อมูลลงใน conversation และ cache จะยังคงอยู่ ในกรณีที่ definition ถูกโหลดเข้าไปใน prefix (เนื่องจากปิดการค้นหา tool หรือ server ได้รับการยกเว้นจากการหน่วงการส่ง) การเปลี่ยนแปลงดังกล่าวจะทำให้ request ถัดไปต้องอ่านข้อมูลทั้งหมดใหม่ทั้งหมด

กรองผลลัพธ์ของ tool ที่มีรายละเอียดมากก่อนส่งเข้า context

ผลลัพธ์ของ tool จะถูกใช้เป็น input และ input จะถูกส่งซ้ำในทุก turn ถัดไป การรัน test ที่แสดงผลลัพธ์ออกมา 20,000 tokens ไม่ใช่ค่าใช้จ่ายที่เกิดขึ้นเพียงครั้งเดียว แต่คุณต้องจ่ายเพิ่มในทุก turn จนกว่าข้อมูลนั้นจะหลุดออกจาก window

ควรทำการกรองข้อมูลตั้งแต่ต้นทาง การใช้ hook เพื่อลดผลลัพธ์จากการรัน test ให้เหลือเพียงรายการที่ผิดพลาดก่อนส่งให้ Claude จะช่วยเปลี่ยนข้อมูลจำนวนมหาศาลให้เหลือเพียงไม่กี่ร้อย tokens ทั้งใน turn นี้และในทุกครั้งที่มีการส่งข้อมูลซ้ำ:

npm test 2>&1 | grep -E "FAIL|Error:" | head -40

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

กำหนดขอบเขตการอ่านข้อมูลของ agent และมอบหมายงานที่ใช้ทรัพยากรสูง

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

จงมอบหมายงานที่ใช้ข้อมูลจำนวนมากให้แก่ subagent การรันการทดสอบ (test runs) และการประมวลผล log ต่างใช้ context จำนวนมาก การใช้ subagent จะช่วยเก็บ output เหล่านั้นไว้ใน window ของตนเอง และส่งกลับมาเพียงบทสรุปเท่านั้น ข้อเสียคือ subagent จะต้องสร้าง cache ของตนเองซึ่งจะไม่มีการใช้งาน cache ในการเรียกใช้งานครั้งแรก และจะใช้ระยะเวลา cache lifetime 5 นาที แม้จะเป็นการใช้งานแบบ subscription ก็ตาม การมอบหมายงานช่วยป้องกัน context หลักของคุณได้อย่างมีประสิทธิภาพ แต่ไม่ได้ช่วยลดจำนวน total tokens เสมอไป

The cache clock: work in stints

Prompt caching ช่วยให้การส่งข้อมูลซ้ำมีราคาถูกลง โดยมีอัตราค่าอ่าน prefix อยู่ที่ 0.1x ของอัตรา input พื้นฐาน เทียบกับอัตราค่าเขียนที่ 1.25x หรือ 2x สำหรับ lifetime ระยะเวลาหนึ่งชั่วโมง การใช้งานแต่ละครั้งจะช่วยต่ออายุรายการโดยไม่มีค่าใช้จ่ายเพิ่มเติม ดังนั้นเวลาจะเริ่มนับใหม่จากการใช้งานครั้งล่าสุด

ระยะเวลา lifetime ที่คุณได้รับขึ้นอยู่กับวิธีการยืนยันตัวตน การสรุปว่า "cache จะหมดอายุหลังจากห้านาที" จึงไม่ถูกต้องเสมอไป

  • สำหรับผู้สมัครสมาชิก Claude, Claude Code จะขอ lifetime ระยะเวลาหนึ่งชั่วโมงโดยอัตโนมัติ
  • เมื่อใช้งานเกินขีดจำกัดของแพ็กเกจและเริ่มใช้ usage credits คุณจะถูกเรียกเก็บเงินตามการใช้งานจริง ดังนั้นระยะเวลาจะลดลงเหลือห้านาที
  • สำหรับ API key หรือ cloud provider ระยะเวลาจะคงอยู่ที่ห้านาที ENABLE_PROMPT_CACHING_1H=1 จะเลือกใช้ lifetime ระยะเวลาหนึ่งชั่วโมง และ FORCE_PROMPT_CACHING_5M=1 จะบังคับให้กลับไปใช้ระยะเวลาห้านาที

คำแนะนำด้านจังหวะการทำงานเหมือนกันไม่ว่าจะใช้รูปแบบใด: ควรทำงานอย่างต่อเนื่อง เพราะหากปล่อยให้ว่างเว้นจนเกินระยะเวลา lifetime การทำงานครั้งถัดไปจะต้องเขียน prefix ที่สะสมไว้ทั้งหมดใหม่ Claude Code session ใน tmux ที่แยกจากกัน จะไม่มีค่าใช้จ่ายในขณะที่ไม่ได้ใช้งาน และ cache ที่พร้อมใช้งานคือสิ่งที่ต้องเสียไปหากปล่อยให้ว่างเว้นนานเกินไป

การกระทำบางอย่างจะทำให้ cache ถูกลบออกในขณะที่คุณยังทำงานอยู่ ได้แก่ การเปลี่ยน model, การเปลี่ยนระดับ effort level, การเปิด fast mode, การเชื่อมต่อหรือตัดการเชื่อมต่อ MCP server, การเปิดหรือปิด plugin, การปฏิเสธเครื่องมือ (tool) ทั้งหมด, การทำ compacting และการอัปเกรด Claude Code /model เป็นสาเหตุที่พบบ่อย เนื่องจากแต่ละ model มี cache เป็นของตัวเอง ดังนั้นการเรียกใช้งานครั้งถัดไปจะอ่านประวัติทั้งหมดใหม่โดยไม่มี cache hits แม้ว่าเนื้อหาจะเหมือนเดิมก็ตาม

การแก้ไขไฟล์, การแก้ไข CLAUDE.md, การเรียกใช้ skills และ commands, การรัน /recap, การ rewind และการสร้าง subagent จะยังคงรักษา cache ไว้ Cache จะถูกจำกัดขอบเขตไว้ภายในเครื่องเดียวและหนึ่ง directory ดังนั้นการใช้งานสอง session ใน directory ที่ต่างกันจะไม่สามารถใช้ cache ร่วมกันได้

หากต้องการตรวจสอบว่า caching ทำงานหรือไม่ ให้ดูที่ current_usage โดย cache_creation_input_tokens ถูกเขียนด้วยอัตราการเขียน cache และ cache_read_input_tokens ถูกส่งด้วยอัตราประมาณหนึ่งในสิบของอัตรา input มาตรฐาน อัตราส่วนการอ่านต่อการสร้าง (read-to-creation ratio) ที่สูงแสดงถึงสถานะการทำงานที่ดี หากอัตราการสร้างยังคงสูงอย่างต่อเนื่อง แสดงว่ามีบางอย่างใน prefix ของคุณมีการเปลี่ยนแปลงอยู่ตลอดเวลา

การเพิ่มขนาด context window จะช่วยแก้ปัญหานี้ได้หรือไม่?

ช่วยได้เพียงบางส่วน เนื่องจากโมเดลปัจจุบันหลายรุ่นรองรับ context window ขนาด 1 million token และการทำ compaction ยังคงทำงานในลักษณะเดิมเมื่อใช้ขีดจำกัดที่สูงขึ้น ต้นทุนยังคงเท่าเดิม เนื่องจาก prompt ทั้งหมดจะถูกส่งซ้ำและถูกคิดค่าบริการในทุก turn การมี window ที่ใหญ่ขึ้นเป็นเพียงการกำหนดว่าคุณจะถูกบังคับให้ดำเนินการเมื่อใด แต่การจัดการข้อมูล (hygiene) เป็นตัวกำหนดค่าใช้จ่าย หากปัญหาคือค่าใช้จ่ายไม่ใช่ขีดจำกัดของระบบ เลือกแผน Claude ที่เหมาะสมกับรูปแบบการทำงานของคุณ จะเป็นตัวตัดสินว่าคุณต้องจ่ายเป็นเงินดอลลาร์หรือใช้โควตาของแผนที่สมัครไว้

การแก้ไข Context และการทำ Compaction ใน API เป็นคนละส่วนกัน

หากคุณกำลัง สร้าง agent ของคุณเองด้วย Messages API จะไม่มี slash commands ให้ใช้งาน และคุณต้องเป็นผู้ดำเนินการส่วนนี้ด้วยตนเอง ฟีเจอร์ฝั่ง server สองอย่างจะทำหน้าที่นี้ ซึ่งทั้งสองอย่างไม่ใช่ฟีเจอร์เดียวกัน

Context editing จะลบเนื้อหาบางส่วนออกจากประวัติการสนทนาอย่างเจาะจงเมื่อประวัติมีขนาดใหญ่ขึ้น โดยจะแทนที่เนื้อหาที่ถูกลบด้วย placeholder text เพื่อให้ Claude ทราบว่ามีข้อมูลบางส่วนถูกลบออกไป ฟีเจอร์นี้ยังเป็นเวอร์ชัน beta: ให้ส่ง anthropic-beta: context-management-2025-06-27 และกำหนดค่า strategies ภายใต้ context_management.edits โดย clear_tool_uses_20250919 จะลบผลลัพธ์จาก tool และ clear_thinking_20251015 จะจัดการ thinking blocks สำหรับค่า trigger จะกำหนดค่าเริ่มต้นไว้ที่ 100,000 input tokens, keep กำหนดไว้ที่การใช้งาน tool 3 ครั้งล่าสุด และ clear_tool_inputs กำหนดไว้ที่ false เพื่อให้ข้อมูล input ยังคงอยู่และลบเฉพาะผลลัพธ์ออกเท่านั้น

Compaction จะสร้างบทสรุปและแทนที่ประวัติการสนทนาทั้งหมดด้วยบทสรุปนั้น ฟีเจอร์นี้เป็นเวอร์ชัน beta เช่นกัน: ให้ส่ง anthropic-beta: compact-2026-01-12 และใช้ edit type แบบ compact_20260112 โดยค่า trigger เริ่มต้นคือ {"type": "input_tokens", "value": 150000} และค่าที่ใช้ต้องไม่ต่ำกว่า 50,000

Compaction มีกฎการส่งต่อข้อมูล (handoff rule) หนึ่งข้อที่อาจทำให้ agent ทำงานผิดพลาด การตอบกลับจะเริ่มต้นด้วย content block ประเภท compaction ซึ่งเก็บบทสรุปไว้ ตามด้วย text block ปกติ คุณต้องส่ง block ดังกล่าวกลับไปในการร้องขอครั้งถัดไป และ API จะลบ content block ทุกตัวที่อยู่ก่อนหน้า block นั้นทิ้ง ในทางปฏิบัติ: ให้แนบเนื้อหาทั้งหมดของ response.content ไม่ใช่เพียงแค่ข้อความเท่านั้น

เอกสารของ Anthropic ระบุว่าการทำ compaction ฝั่ง server เป็นกลยุทธ์หลักในการจัดการ context สำหรับการสนทนาที่ยาวต่อเนื่อง และ context editing เป็นตัวเลือกสำหรับการควบคุมสิ่งที่ต้องการลบอย่างละเอียด โปรดตรวจสอบการรองรับของ model ก่อน โดย model Opus, Sonnet และ Fable ในปัจจุบันรองรับ compaction แต่ claude-haiku-4-5 ไม่รองรับ และสามารถตรวจสอบรายการล่าสุดได้ที่หน้า compaction ทั้งนี้ ฟีเจอร์ beta ทั้งสองไม่ได้ใช้ควบคุม /compact ของ Claude Code ซึ่งเอกสารระบุว่าเป็นคำขอสรุปข้อมูลแบบครั้งเดียว (one-off summarization request) ที่ client เป็นผู้ส่ง

FAQ

ทำไม Claude Code session ถึงทำงานช้าลงและมีค่าใช้จ่ายสูงขึ้นเมื่อใช้งานนานขึ้น?

เนื่องจากข้อมูลการสนทนาทั้งหมดจะถูกส่งไปใหม่ในทุกรอบการทำงาน ดังนั้นคำถามเพียงบรรทัดเดียวใน session ที่เปิดทิ้งไว้ทั้งวัน จะต้องส่งข้อมูลทั้งหมดของทั้งวันไปด้วย Prompt caching ช่วยลดค่าใช้จ่ายได้ในขณะที่ cache ยังทำงานอยู่ โดยมีราคาเพียง 0.1x ของอัตรา input พื้นฐานสำหรับการอ่าน หากรอบการทำงานใดไม่พบข้อมูลใน cache ข้อมูล prefix เดิมจะถูกส่งซ้ำในราคา 1.25x ให้รัน /context เพื่อดูว่าข้อมูลใดกำลังใช้พื้นที่ใน window และอ่าน กลไกการคิดค่าบริการของ Claude Code เพื่อทำความเข้าใจระบบ

/clear และ /compact ใน Claude Code ต่างกันอย่างไร?

/clear จะเริ่มการสนทนาใหม่ด้วย context ที่ว่างเปล่า คำสั่งนี้ไม่มีการส่ง request จึงไม่มีค่าใช้จ่าย และเป็นตัวเลือกที่เหมาะสมสำหรับงานที่ไม่เกี่ยวข้องกัน ส่วน /compact จะรักษาการสนทนาเดิมไว้แต่แทนที่ประวัติการสนทนาด้วยบทสรุป จึงเป็นตัวเลือกที่เหมาะสมสำหรับงานเดียวที่ต่อเนื่องยาวนาน ควรระบุเป้าหมายให้ชัดเจน เช่นในกรณีของ /compact keep only the plan and the diff เนื่องจากคำสั่งจะเป็นตัวกำหนดว่าข้อมูลใดจะถูกเก็บไว้

ฉันจะดูได้อย่างไรว่าอะไรกำลังใช้พื้นที่ใน Claude Code context window?

รัน /context หรือรัน /context all เพื่อดูรายละเอียดแยกตามรายการทั้งหมด ระบบจะแสดง system prompt, tool definitions, MCP servers, memory files และประวัติการสนทนาในรูปแบบตารางสี พร้อมคำแนะนำสำหรับเครื่องมือที่ใช้ context จำนวนมากหรือไฟล์ memory ที่มีขนาดใหญ่เกินไป สำหรับแผนแบบชำระเงิน /usage จะระบุการใช้งานล่าสุดแยกตาม individual skills, subagents และ MCP servers ด้วย

ฉันควรใช้ context window ขนาด 1 million token แทนการใช้ compaction หรือไม่?

การใช้ window ที่ใหญ่ขึ้นเป็นเพียงการประวิงเวลาปัญหา ไม่ใช่การแก้ไขปัญหา โมเดลปัจจุบันหลายรุ่น เช่น Opus 4.8 และ Sonnet 5 รองรับ context window ขนาด 1 million token และการทำงานของ compaction ก็เป็นแบบเดียวกัน ทุกรอบการทำงานยังคงต้องส่ง prompt ฉบับเต็มและมีการคิดค่าใช้จ่าย ดังนั้นการสนทนาขนาด 400,000-token จึงมีค่าใช้จ่ายสูงไม่ว่าข้อมูลจะพอดีกับ window หรือไม่ก็ตาม

Context editing และ compaction ใน Claude API ต่างกันอย่างไร?

Context editing จะลบเนื้อหาเก่าออกบางส่วน โดยเน้นที่ผลลัพธ์จาก tool และจะทิ้งข้อความ placeholder ไว้ในตำแหน่งเดิมเพื่อให้ Claude ทราบว่าข้อมูลถูกลบออกไปแล้ว ส่วน compaction จะสร้างบทสรุปและแทนที่ประวัติการสนทนาทั้งหมดด้วยบทสรุปนั้น เอกสารของ Anthropic ระบุว่า compaction เป็นกลยุทธ์หลักสำหรับการสนทนาที่ยาวนาน และกำหนดให้ context editing เป็นตัวเลือกสำหรับการจัดการแบบละเอียด ทั้งสองฟีเจอร์ยังอยู่ในสถานะ beta และแยกส่วนการทำงานจาก /compact ของ Claude Code