Brad เจ้าของช่อง Brad | AI & Automation เคยชน usage limit ของ Claude Code แทบทุกวัน จนหลังจากรื้อ setup ใหม่ทั้งหมดก็ใช้ได้ตลอดวันโดยไม่เจอ limit อีกเลยหลายสัปดาห์ติด ในคลิป "I Stopped Hitting Claude Code Usage Limits (Here's How)" ที่มียอดวิวเกินแสนภายในไม่ถึงเดือน Brad อธิบายว่าปัญหาที่แท้จริงไม่ใช่โควต้าน้อย แต่เป็นเรื่อง context hygiene ของ setup ที่บวมขึ้นเงียบ ๆ จนทุก ๆ ข้อความที่พิมพ์เข้าไปต้องจ่ายภาษีโทเค็นจำนวนมหาศาลโดยไม่รู้ตัว บทความนี้สรุปสิ่งที่ Brad ปรับจริง โดยเรียบเรียงเป็นภาษาไทยฉบับเข้าใจง่ายเพื่อให้ทีม developer ไทยหยิบไปใช้ได้ทันที
ทำไม Claude Code ถึงเตือนเร็ว: เกมนี้คือเรื่อง context hygiene ไม่ใช่ limit
Brad ชี้ว่าทุกครั้งที่ส่งข้อความใหม่ไปหา Claude Code โมเดลจะอ่าน บทสนทนาทั้งหมดในรอบนั้นซ้ำตั้งแต่ข้อความแรก ไม่ใช่อ่านเฉพาะข้อความล่าสุด ผลที่ตามมาคือข้อความที่ 30 ในเซสชันมีต้นทุนสูงกว่าข้อความแรกถึง 31 เท่า เพราะต้องลากเอาประวัติ 30 ข้อความก่อนหน้ามาประมวลผลพร้อมกัน ขณะเดียวกัน ไฟล์ CLAUDE.md, MCP server ทุกตัว และ skill ทุกตัวที่ติดตั้งไว้ จะ preload เข้าสู่ context window ตั้งแต่วินาทีที่เปิดเซสชัน ก่อนแม้แต่จะพิมพ์ข้อความแรก
context window ที่ใหญ่ขึ้นมักให้ผลลัพธ์ดีขึ้น แต่ก็แลกมาด้วยต้นทุนโทเค็นที่สูงขึ้นและ usage limit ที่หมดเร็วขึ้น ยิ่งไปกว่านั้น Brad ระบุว่า context ที่บวมเกินจะทำให้คุณภาพ output แย่ลง เพราะ LLM มีแนวโน้มสนใจเฉพาะส่วนท้ายของ context และพลาดรายละเอียดในส่วนต้นไป สรุปคือ context ที่บวมทำให้จ่ายแพงขึ้นแต่ได้ผลลัพธ์น้อยลง
วิธีตรวจสอบขนาด context ฐานของ setup ตัวเอง ทำได้ด้วยการเปิดเซสชันใหม่แล้วพิมพ์คำสั่ง /context Claude Code จะแสดงจำนวนโทเค็นที่ preload ไว้แล้วก่อนส่งข้อความแรก ตอนที่ Brad ลองรันคำสั่งนี้ก่อนปรับแต่ง setup ตัวเลขที่เห็นคือมากกว่า 50,000 โทเค็น ซึ่งทุกข้อความหลังจากนั้นจะบวกทบเข้าไปอีก กลยุทธ์หลักของ Brad จึงเป็นการ "ตัด context ฐาน" ให้เหลือน้อยที่สุดก่อนจะเริ่มทำงานจริง
ค่าใช้จ่ายแฝงใน setup ที่กินโทเค็นทุกครั้ง
ปัญหาอันดับหนึ่งที่ Brad เจอคือ MCP server ที่เปิดทิ้งไว้ MCP server ทุกตัวที่เชื่อมไว้จะโหลด tool definition ทั้งหมดของตัวเองเข้าสู่ context ในทุก ๆ ข้อความ ไม่ใช่เฉพาะตอนเรียกใช้งาน server หนึ่งตัวอาจมี tool definition ขนาดราว 18,000 โทเค็น ถ้าเปิดไว้หลายตัวพร้อมกันก็รวมเป็น 70,000 โทเค็นที่กินทิ้งทุกเทิร์น วิธีแก้คือเปิดเซสชันใหม่แล้วรัน /mcp เพื่อดูรายชื่อ MCP server ที่ active อยู่ จากนั้นตัดการเชื่อมต่อตัวที่ไม่ได้ใช้ในรอบนั้นออกให้หมด
ขั้นต่อไปที่ Brad แนะนำคือ แทนที่ MCP server ด้วย CLI เมื่อทำได้ เหตุผลคือ CLI จะเสียโทเค็นเฉพาะตอนที่ Claude เรียกใช้คำสั่งจริง ๆ ขณะที่ MCP server เสียโทเค็นตั้งแต่ตอนที่ยังนั่งเฉย ๆ ในเซสชัน Brad ทำกับ Playwright MCP และ Apify โดยเปลี่ยนไปใช้ CLI แล้วประหยัดโทเค็นได้ราว 40%
ส่วนถัดมาคือ CLAUDE.md ซึ่งโหลดเข้าสู่ context ทุกครั้งที่เปิดเซสชัน Brad ให้เช็ก 3 จุด จุดแรกคือมองหากฎที่ขัดแย้งกันเอง เช่นบอกให้ "ตอบสั้น" ในส่วนหนึ่ง แล้วบอก "อธิบายเหตุผลทุกครั้งโดยละเอียด" ในอีกส่วนหนึ่ง Claude เลือกตามไม่ได้ทั้งสองข้อ จึงทำให้ output ไม่นิ่งและไฟล์ก็บวมเปล่า ๆ
จุดที่สองคือตัดกฎที่ไม่จำเป็นออกด้วย 5 ตัวกรอง ของ Brad โดยถามทุกข้อในไฟล์ว่า กฎข้อนี้เป็นสิ่งที่ Claude ทำเป็นค่าเริ่มต้นอยู่แล้วโดยไม่ต้องสั่งหรือไม่, ขัดกับกฎข้ออื่นหรือไม่, ซ้ำกับข้อที่มีอยู่แล้วหรือไม่, เป็น band-aid ที่เขียนเพื่อแก้ output ที่พลาดครั้งเดียวหรือไม่, และคลุมเครือจน Claude ตีความได้ต่างกันทุกครั้งหรือไม่ (เช่น "ตอบให้เป็นธรรมชาติ" หรือ "ใช้โทนที่ดี") ถ้ากฎข้อใดเข้าเงื่อนไขสักข้อ ให้ตัดทิ้ง โดย Brad ระบุว่าควรเข้มกับตัวเองให้มากเข้าไว้ ตัดทิ้งเกินไปดีกว่าเก็บไว้เกินจำเป็น
จุดที่สามและสำคัญที่สุดคือ progressive disclosure ของ CLAUDE.md ตัว CLAUDE.md หลักควรเก็บเฉพาะกฎที่ใช้กับทุกเซสชันใน repo นั้น เช่น style preferences หรือโครงสร้าง project ส่วนรายละเอียดเฉพาะทาง เช่น API conventions, development pattern, testing guideline ให้แยกออกไปเป็นไฟล์ reference ของตัวเอง แล้วใส่บรรทัดเดียวใน CLAUDE.md แบบ "สำหรับ API conventions อ่านไฟล์ API-standards.md" Claude จะดึงไฟล์เหล่านั้นมาอ่านเฉพาะตอนที่จำเป็นจริง ๆ เท่านั้น จากเดิมที่ CLAUDE.md ขนาด 5,000 โทเค็นนั่งอยู่ที่ root ของ repo ตลอดเวลา ก็จะกลายเป็นไฟล์หลักขนาด 500 บรรทัดที่ชี้ไปยัง reference อีกหลายไฟล์ตามต้องการ
หลักการเดียวกันใช้กับ skill ทุกตัว metadata ของทุก skill จะโหลดเข้า context เพื่อให้ Claude ตัดสินใจได้ว่าจะเรียกใช้ตัวไหน ถ้าติดตั้ง skill ไว้จำนวนมาก โดยเฉพาะ skill ที่โหลดจาก marketplace ฟรีและมีคำสั่งยาว 400-800 บรรทัด context จะถูกกินไปโดยที่ได้ผลตอบแทนน้อยมาก Brad ย้ำว่ายิ่งใส่คำสั่งเยอะ ไม่ได้แปลว่า output จะดีขึ้น เพราะเลยจุดหนึ่งไป Claude จะเริ่มเพิกเฉยต่อกฎเองเพราะมีหลายอย่างแย่งความสนใจกันมากเกินไป skill ที่ดีคือ skill ที่กระชับและสั้น และควรใช้ 5 ตัวกรองเดียวกับ CLAUDE.md กรอง skill ทุกตัวที่ติดตั้งไว้เช่นกัน
ตั้ง settings.json ให้ทันกับ context window ปัจจุบัน
Brad ระบุว่ามีหลายค่าใน settings.json ที่ยังคงตั้งไว้สำหรับ context window ขนาด 200,000 โทเค็นแบบเดิม ผู้ใช้ส่วนใหญ่ไม่เคยปรับเลย จึงพลาดประโยชน์ของการ tune ค่าเหล่านี้
ค่าตัวแรกคือ auto-compact โดยค่าเริ่มต้น Claude จะ auto-compact context เมื่อใช้ไปประมาณ 83% แต่คุณภาพของ output มักจะเริ่มแย่ลงก่อนที่ตัวเลขจะถึงระดับนั้น Brad แนะนำให้ตั้ง autoCompactPercentage ไว้ที่ราว 75% เพื่อให้ compaction ทำงานเร็วขึ้นก่อนคุณภาพจะตก
ค่าตัวที่สองคือ bash output length เมื่อ Claude รันคำสั่ง shell จะอ่าน output ได้จำกัด ค่าเริ่มต้นอยู่ในช่วง 30,000-50,000 ตัวอักษร ส่วนเกินจะถูกตัดทิ้งแบบเงียบ ๆ Claude จึงต้องรันคำสั่งซ้ำเพื่อขอข้อมูลเพิ่ม ซึ่งเสียโทเค็นไปกับการ retry มาก วิธีแก้คือตั้ง environment variable BASH_MAX_OUTPUT_LENGTH=150000 เพื่อให้รับ output ได้ยาวขึ้นในรอบเดียว
ค่าตัวสุดท้ายคือ file permissions โดยค่าเริ่มต้น Claude Code อ่านได้ทุกอย่างใน project ไม่ว่าจะเป็น node_modules, โฟลเดอร์ dist, ไฟล์ lock หรือ build artifacts วิธีจัดการคือเพิ่ม deny rule ใน settings.json ซึ่งทำงานเหมือน .gitignore แต่ใช้กับ Claude เมื่อบอกไว้ว่าโฟลเดอร์ไหนห้ามอ่าน Claude ก็จะหยุดเสียโทเค็นไปกับสิ่งที่ไม่ต้องรู้
วินัยรายวัน 4 ข้อที่ลดโทเค็นได้มากกว่าการ tune setup
หลังจากจัด setup เสร็จแล้ว Brad ระบุว่าวินัยการใช้งานในแต่ละวันต่างหากที่ส่งผลกับ usage มากที่สุด โดยรวบรวมมาเป็น 4 ข้อ
ข้อที่หนึ่งคือ เริ่มเซสชันใหม่ระหว่างงานคนละเรื่อง ค่าโทเค็นจะทบทุกข้อความตามที่อธิบายไปแล้ว ถ้าเพิ่งคุยเรื่อง content research มา 20 ข้อความ แล้วเปลี่ยนไปเขียน script ทุกข้อความใหม่จะยังจ่ายภาษีของบทสนทนา research อยู่ คำสั่ง /clear แก้ปัญหานี้โดยรีเซ็ตเซสชันให้สด Brad ยืนยันว่าวินัยข้อเดียวนี้น่าจะประหยัดโทเค็นได้มากที่สุดในทั้งหมด
ข้อที่สองคือ ใช้ plan mode ก่อนทำงานที่ไม่ใช่งานเล็ก ความผิดพลาดที่แพงที่สุดใน Claude Code คือการปล่อยให้ Claude เดินผิดทาง เช่นเขียนโค้ดไป 200 บรรทัดแล้วเพิ่งรู้ว่า Claude เข้าใจโจทย์ผิด ต้องทิ้งของเดิมเริ่มใหม่ โทเค็นที่จ่ายไปสูญเปล่าทั้งหมด plan mode บังคับให้ Claude ถามคำถามจนชัดก่อน แล้ววางแผนแนวทาง พอตกลงกันได้แล้วค่อยลงมือเขียนโค้ดจริง สำหรับงานใหญ่ที่ต้องการ planning loop ลึกขึ้น Brad ชี้ไปยัง framework อย่าง BMAD หรือ PRD
ข้อที่สามคือ แก้ข้อความก่อนหน้าแทนการตอบกลับด้วยคำแก้ เมื่อ Claude เข้าใจอะไรผิด อย่าส่งข้อความใหม่ไปแก้ เพราะ follow-up ทุกข้อความจะถูกบันทึกใน history อย่างถาวร สุดท้ายในเซสชันจะมีทั้งคำตอบที่ผิด คำแก้ของผู้ใช้ และคำตอบที่ถูก อยู่ปนกันใน context ตลอดทาง ทุกข้อความหลังจากนั้นต้องลากของพวกนี้มาประมวลผลซ้ำ ทางที่ดีกว่าคือกลับไปแก้ข้อความเดิม ส่งใหม่ ทำให้คำตอบที่ผิดและคำแก้หายไปทั้งคู่ และไม่มีอะไรไปรบกวนเซสชันที่เหลือ
ข้อที่สี่คือ เลือกโมเดลให้เหมาะกับงาน Sonnet จัดการงาน coding ทั่วไปได้ดีเป็นค่าเริ่มต้น Haiku เหมาะกับ sub-agent งาน formatting และ lookup ง่าย ๆ ส่วน Opus ใช้เมื่อต้องวางแผนสถาปัตยกรรมเชิงลึกที่ Sonnet จัดการไม่ไหว การกระจายงานตามขีดความสามารถของแต่ละโมเดลช่วยให้ไม่ต้องเผา quota ของโมเดลใหญ่ไปกับงานที่โมเดลเล็กทำได้
ตารางสรุปก่อนนำไปใช้จริง
ก่อนจะลงมือปรับ Claude Code ของตัวเอง สามารถใช้ตารางสั้นด้านล่างเป็น checklist เดินตามได้ทันที
| หมวด | สิ่งที่ทำ | คำสั่ง / ค่าที่ตั้ง |
|---|---|---|
| ตรวจ baseline | ดูขนาด context ฐานก่อนส่งข้อความแรก | /context |
| MCP | ตัด server ที่ไม่ใช้ในเซสชันนั้นออก | /mcp แล้ว disconnect |
| MCP | แทนด้วย CLI เมื่อทำได้ ประหยัดราว 40% | เปลี่ยน Playwright/Apify เป็น CLI |
| CLAUDE.md | กรองกฎด้วย 5 ตัวกรอง | ตัดที่ default, ขัดแย้ง, ซ้ำ, band-aid, คลุมเครือ |
| CLAUDE.md | progressive disclosure | แยก reference เป็นไฟล์ ใส่ pointer 1 บรรทัด |
| Skills | กรองด้วย 5 ตัวกรองเดียวกัน | ลบ skill 400-800 บรรทัดที่ไม่ค่อยได้ใช้ |
| settings.json | auto-compact เร็วขึ้น | autoCompactPercentage: 75 |
| settings.json | รับ bash output ยาวขึ้น | BASH_MAX_OUTPUT_LENGTH=150000 |
| settings.json | กัน Claude อ่าน junk | deny rule สำหรับ node_modules, dist, lock files |
| วินัย | งานคนละเรื่องเริ่มใหม่ | /clear |
| วินัย | ก่อนงานใหญ่ ให้วางแผนก่อน | plan mode |
| วินัย | Claude ผิด ให้แก้ข้อความเดิม | edit previous message ไม่ใช่ reply |
| วินัย | กระจายงานตามโมเดล | Haiku → Sonnet → Opus |
ข้อสรุปที่สำคัญที่สุดจากคลิปของ Brad คือ usage limit ของ Claude Code ไม่ใช่ปัญหาเรื่องโควต้า แต่เป็นปัญหา context hygiene ที่เกิดจาก setup ซึ่งเปลี่ยนแปลงเล็ก ๆ น้อย ๆ เรื่อย ๆ จนบวมไปโดยไม่รู้ตัว การ tune ครั้งเดียวจึงไม่พอ ต้องมีวินัยตรวจซ้ำเป็นระยะ
ดูคลิปต้นทางของ Brad | AI & Automation ฉบับเต็มได้ที่ I Stopped Hitting Claude Code Usage Limits (Here's How) ซึ่ง Brad แจกฟรี "context audit skill" สำหรับ Claude Code ที่รันการตรวจทุกข้อในบทความนี้แล้วให้คะแนน 0-100 ดาวน์โหลดได้จาก Google Drive link ในคำอธิบายใต้คลิป
ความคิดเห็น
ยังไม่มีความคิดเห็น เป็นคนแรกที่แสดงความเห็น!