Spotify ปล่อยปลั๊กอิน shunt — ใช้ hook ของ Claude Code บล็อกการอ่านไฟล์ใหญ่แล้วโยนไปให้โมเดลถูกกว่าทำแทน ลดโทเคนได้ 82-94%
เมื่อ 3 กันยายน 2026 Spotify Engineering เผยแพร่บทความของ Dimitri Mazmanov (Principal Product Manager) ชื่อ “Portal by Spotify cut my Claude Code token usage by 90%” ซึ่งวางปัญหาไว้ตรงและคุ้นสำหรับใครที่จ่ายค่าโทเคนเอง: งานส่วนใหญ่ที่ coding agent ทำให้เราไม่ใช่การคิด แต่คือ I/O — อ่านไฟล์ห้าไฟล์เพื่อตอบคำถามเกี่ยวกับเมธอดเดียว, สร้างไฟล์เทสต์ที่หน้าตาเหมือนอีกยี่สิบไฟล์ข้าง ๆ, อัปเดตเอกสารหลังประชุม ทั้งหมดนี้กินโทเคนหลักพันโดยแทบไม่ต้องใช้การให้เหตุผลเลย และเรากำลังป้อนมันให้โมเดลระดับ frontier ที่คุณสมบัติเกินความจำเป็นไปมาก
ทางแก้ที่เขานำเสนอไม่ใช่ทฤษฎี แต่เป็นปลั๊กอิน Claude Code ชื่อ shunt ที่โค้ดอยู่บน GitHub จริงใต้ Apache-2.0 — และเมื่ออ่านรีโปคู่กับบทความ จะเห็นตัวเลขและข้อจำกัดที่บทความไม่ได้เขียนไว้
กลไก: hook เป็นด่านบังคับ ไม่ใช่คำแนะนำใน CLAUDE.md
ผู้เขียนเล่าว่าเวอร์ชันแรกเป็นชุดกฎ routing ใน CLAUDE.md ซึ่ง “พอใช้ได้” แต่มีปัญหาสองข้อ: กฎเป็นแค่คำแนะนำ Claude เลือกไม่ทำตามได้ และทุกโปรเจกต์ต้องคัดลอกกฎไปเอง เวอร์ชันปัจจุบันจึงย้ายไปเป็นปลั๊กอินที่ทำงานสามชั้น
ชั้นที่ 1 — Hooks ปลั๊กอินลงทะเบียน PreToolUse สองตัวไว้ใน hooks.json
check-file-sizeยิงทุกครั้งที่มีการเรียกReadถ้าไฟล์ยาวเกินเกณฑ์ (ดีฟอลต์ 350 บรรทัด ปรับได้ด้วย envSHUNT_MIN_LINES) hook จะ block แล้วส่งข้อความบอกให้ไปใช้ skill/bulk-readerแทนcheck-bash-readดักคำสั่งcat,head,tail,less,moreบนไฟล์ใหญ่
จุดที่ออกแบบมาดีคือข้อยกเว้น: การอ่านแบบเจาะจง (มี offset หรือ limit) ผ่านได้ทันที เพราะ Claude รู้อยู่แล้วว่าต้องการส่วนไหน เช่นเดียวกับคำสั่งที่มี pipe (cat file | grep) หรือ redirect (cat file > out) ซึ่งไม่ได้ดึงเนื้อหาเข้า context
ชั้นที่ 2 — Scripts สคริปต์ bulk-read ห่อไฟล์แต่ละไฟล์ด้วยแท็ก XML (<file path="...">) แล้วส่งไปพร้อมคำถาม ส่วน code-write ส่ง spec + ไฟล์อ้างอิง แล้วตัด markdown fence ออกก่อนเขียนลงดิสก์โดยตรง — Claude ไม่เคยเห็นโค้ดที่ถูกสร้าง --reference เป็นพารามิเตอร์บังคับ เพราะถ้าไม่มีไฟล์ให้เทียบแพตเทิร์น โมเดลผู้ช่วยจะสร้างโค้ดที่ไม่เข้ากับอะไรในโปรเจกต์เลย
ชั้นที่ 3 — Skills ไฟล์ SKILL.md สองตัวบอก Claude ว่าเมื่อไรและอย่างไรควรเรียกสคริปต์ ผลคือระบบ “เสื่อมสภาพอย่างนุ่มนวล” — ต่อให้ Claude ไม่อ่านคำอธิบาย skill hook ก็ยังบล็อกการอ่านที่แพงอยู่ดี
ปลายทางคือ AiKA mode บน Portal — เอเจนต์เชิงประกาศที่รันบน runtime ชั่วคราว (ผู้เขียนเปรียบว่าเหมือน AWS Lambda สำหรับเอเจนต์) กำหนดคำสั่ง เลือกโมเดล ตั้ง temperature แล้วแนบทูล MCP ได้ ตัวอย่างในบทความใช้ Gemini 2.5 Flash เป็น worker แต่ช่อง model รับโมเดลใดก็ได้ที่ตั้งค่าไว้ในอินสแตนซ์
ตัวเลขจริงอยู่ในรีโป ไม่ได้อยู่ในบทความ
บทความบอกแค่ว่า “ทดสอบกับ Java monorepo สี่สถานการณ์ ค่าเฉลี่ยของ bulk-read อยู่ราว 90%” แต่ README.md ของปลั๊กอินมีตารางเต็ม โดยระบุว่าวัดกับ Java monorepo ขนาด 162,000 บรรทัด
| สถานการณ์ | บรรทัด | ไม่ใช้ shunt | ใช้ shunt | ประหยัด |
|---|---|---|---|---|
| ไฟล์ใหญ่ไฟล์เดียว | 4,014 | 33,684 โทเคน | 5,737 โทเคน | 82% |
| source + test คู่กัน | 7,408 | 75,990 โทเคน | 4,148 โทเคน | 94% |
| อ่านข้ามหลายไฟล์ | 1,281 | 16,221 โทเคน | 821 โทเคน | 94% |
| code-write | 3,667 | 40,614 โทเคน + การสร้าง | เขียนลงดิสก์ 833 บรรทัด | — |
อ่านตารางนี้แล้วจะเห็นสามอย่างที่พาดหัวไม่ได้บอก
หนึ่ง เลข 90% คือ ค่าเฉลี่ยของสามแถวแรกเท่านั้น (82, 94, 94) แถว code-write ซึ่งเป็นครึ่งหนึ่งของคุณค่าที่ปลั๊กอินโฆษณา ไม่มีตัวเลขประหยัด เพราะผู้เขียนยอมรับเองว่าวัดเป็นโทเคนได้ยาก — ถ้าไม่ใช้ shunt Claude ต้องทั้งอ่านไฟล์อ้างอิงและสร้างเอาต์พุตเป็น output token ที่แพงกว่า
สอง ตัวเลขนี้ ทำซ้ำไม่ได้จากรีโป ไฟล์ evals/benchmarks.json นิยามสถานการณ์ทั้งสี่ไว้จริง แต่ fixture ที่ผูกอยู่คือ TypeScript สามไฟล์ (websocket-handler.ts 602 บรรทัด, user-service.ts, order-service.test.ts) ไม่ใช่ Java monorepo 162K บรรทัดที่ตารางอ้าง และไฟล์นั้นระบุวิธีนับไว้ว่า chars / 4 คือการประมาณ ไม่ใช่การนับโทเคนจริง
สาม README มีหัวข้อ “Known limitations” ที่บทความข้ามไป และข้อแรกสำคัญมาก: “No enforcement for code-writer” — มีแต่ bulk-reader เท่านั้นที่ถูกบังคับด้วย hook ส่วน code-writer อาศัยให้ Claude อ่านคำอธิบาย skill แล้วเลือกใช้เอง ซึ่งก็คือปัญหา “กฎเป็นแค่คำแนะนำ” ที่ผู้เขียนบอกว่าย้ายมาใช้ปลั๊กอินเพื่อแก้ตั้งแต่แรก
ยังมีข้อจำกัดเชิงวิศวกรรมอีกสองข้อที่กระทบการใช้จริง: อินพุตของ aika:invoke-chat ถูกส่งผ่าน argv จึงติดเพดาน ARG_MAX — ดีฟอลต์ SHUNT_MAX_PAYLOAD_BYTES อยู่ที่ 400,000 ไบต์ และ 120,000 ไบต์บน Linux ต้องแตกเป็นก้อนย่อยเอง ส่วนเรื่องเวลา บทความเขียนว่าการหน่วงต่อครั้งอยู่ที่ 10-30 วินาที และ “Portal จำกัดการเรียกครั้งเดียวไว้ที่ 30 วินาที” ขณะที่ README ตั้ง SHUNT_TIMEOUT_SECONDS ดีฟอลต์ไว้ที่ 180 วินาที — สองตัวเลขนี้ไม่ตรงกัน ผู้ใช้จริงควรทดสอบเองก่อนตั้งความคาดหวัง
สิ่งที่ผู้เขียนบอกเองว่ามอบหมายไม่ได้
ส่วนที่ซื่อสัตย์ที่สุดของบทความคือหัวข้อ “What doesn’t work”
- มอบหมายการแก้ไขไม่ได้ สรุปจากโมเดลผู้ช่วยไม่มีเลขบรรทัดที่เชื่อถือได้ ถ้า Claude ต้องแก้โค้ดตามผลวิเคราะห์ ก็ยังต้องอ่านส่วนนั้นเองอยู่ดี (นี่คือเหตุผลที่ hook ปล่อยการอ่านแบบ offset/limit ผ่าน)
- มอบหมายการให้เหตุผลไม่ได้ ในการทดสอบของผู้เขียน โมเดลผู้ช่วยเจอแต่แพตเทิร์นระดับผิว และ พลาดบั๊ก thread-safety ที่ละเอียดอ่อน ซึ่ง Claude จับได้ในไม่กี่วินาทีเมื่อได้บริบทที่ถูกต้อง การ routing จึงตัดงาน debug, การตัดสินใจเชิงสถาปัตยกรรม และโค้ดที่เกี่ยวกับความปลอดภัยออกไปชัดเจน
- ไฟล์เล็กไม่คุ้ม ต่ำกว่าเกณฑ์บรรทัด ค่าโสหุ้ยของการมอบหมายแพงกว่าที่ประหยัดได้
เรื่องเวลาและเรื่องที่ต้องจ่าย
รายละเอียดสองข้อที่ควรรู้ก่อนตื่นเต้น
ข้อแรก นี่ไม่ใช่การเปิดตัว ปลั๊กอิน shunt ถูกเพิ่มเข้ารีโปสาธารณะ spotify/portal-ai-plugins ตั้งแต่ 14 สิงหาคม 2026 (คอมมิต “Add shunt: route I/O-heavy Claude Code work to AiKA modes”) พร้อมตารางตัวเลขในวันเดียวกัน และรีโปไม่ได้ถูกพุชอีกเลยตั้งแต่ 17 สิงหาคม — บทความวันที่ 3 กันยายนจึงเป็นการแนะนำของที่มีอยู่แล้วราวสามสัปดาห์ (และลิงก์คำว่า “shunt” ในบทความยังชี้ไปที่ ฟอร์กส่วนตัวบนสาขาที่ยังไม่ถูกเมิร์จ ไม่ใช่รีโปหลักของ Spotify)
ข้อที่สอง และสำคัญกว่า: ตัวปลั๊กอินเปิดจริงใต้ Apache-2.0 แต่ชิ้นที่รับน้ำหนักไม่ได้เปิด ผู้เขียนพูดเองตรง ๆ ว่า “โมดูลที่รับน้ำหนักคือ modes” และ modes อยู่บน Portal by Spotify ซึ่งเป็นผลิตภัณฑ์เชิงพาณิชย์ (Backstage เวอร์ชันที่ Spotify ขาย) ที่ต้องเปิดปลั๊กอิน AiKA ถ้าองค์กรของคุณไม่ได้ซื้อ Portal ปลั๊กอินนี้ไม่มีปลายทางให้ยิง — bulk-read และ code-write ทั้งคู่วิ่งผ่าน portal-cli actions aika:invoke-chat
บทความยังอ้างการคาดการณ์ของ Gartner (ข่าวประชาสัมพันธ์ 24 มิ.ย. 2026) ว่าภายในปี 2028 ต้นทุน AI coding จะแซงเงินเดือนเฉลี่ยของนักพัฒนา และระบุว่าหนึ่งในสี่ของผู้บริหารสายวิศวกรรมจ่ายค่าโทเคน $200-500 ต่อคนต่อเดือน บางรายเกิน $2,000 — ตัวเลขชุดหลังนี้ไม่ได้ระบุแหล่งที่มาแยกในบทความ
มุมมอง AI Curator
ต่อให้คุณไม่มีวันได้ใช้ Portal ปลั๊กอินนี้ก็ยังคุ้มค่าที่จะอ่านโค้ด เพราะสิ่งที่มันสาธิตคือ แพตเทิร์นที่ย้ายไปใช้กับอะไรก็ได้ — ไฟล์ที่รับน้ำหนักจริงคือ hooks/check-file-size ซึ่งเป็นสคริปต์ bash ยาวไม่ถึง 40 บรรทัดที่อ่าน JSON จาก stdin ด้วย jq แล้วคืน {"decision": "block", "reason": "..."} ปลายทางจะเป็น AiKA, Ollama บนเครื่องตัวเอง, vLLM ในออฟฟิศ หรือแค่ llama-server ก็ได้ทั้งนั้น ส่วนที่ Spotify ขายคือปลายทาง ส่วนที่เป็นความคิดคือด่านบังคับ และด่านบังคับนั้นแจกฟรี
นี่คือประเด็นที่ตรงกับทีมไทยมากที่สุด ทีมที่จ่ายค่า API เป็นเงินบาทแต่ราคาคิดเป็นดอลลาร์ รู้สึกถึงบิลนี้แรงกว่าทีมในสหรัฐฯ หลายเท่า และคำแนะนำที่ได้ยินบ่อยคือ “เขียนกฎใน CLAUDE.md ให้ agent ประหยัดหน่อย” — บทความนี้บอกจากประสบการณ์ตรงว่าวิธีนั้นไม่ทำงาน เพราะกฎในไฟล์ instruction คือคำขอ ไม่ใช่ข้อบังคับ ถ้าต้องการผลที่วัดได้ ต้องอยู่ในชั้น hook ที่โมเดลปฏิเสธไม่ได้ และข่าวดีคือ hook ของ Claude Code เป็นของฟรีที่ทุกคนมีอยู่แล้ว
แต่อย่าเพิ่งคาดหวัง 90% กับโค้ดเบสของตัวเอง ตัวเลขในตารางมาจาก Java monorepo ที่ไฟล์ยาว 4,000 บรรทัด ซึ่งเป็นสภาพแวดล้อมที่เข้าทางกลยุทธ์นี้ที่สุด โปรเจกต์ TypeScript หรือ Go ที่แตกไฟล์ละ 150-300 บรรทัดจะไม่ผ่านเกณฑ์ 350 บรรทัดเลยสักไฟล์ ประโยชน์ที่ได้แปรผันตรงกับความยาวไฟล์เฉลี่ยของคุณ ก่อนติดตั้งอะไร ลองรัน find . -name '*.ts' | xargs wc -l | sort -rn | head -30 ดูก่อนว่ามีไฟล์เกิน 350 บรรทัดกี่ไฟล์จริง ๆ
ข้อควรระวังสุดท้ายที่อยากฝากไว้ ปลั๊กอินนี้ ตัดเนื้อหาที่ถูกสรุปแล้วออกจาก context ของโมเดลหลักถาวร สิ่งที่ Claude ได้กลับมาคือ bullet ที่โมเดลถูกกว่าเขียนขึ้น ไม่ใช่โค้ดจริง ผู้เขียนพบเองว่าโมเดลผู้ช่วยพลาดบั๊ก thread-safety — และในทางปฏิบัติ คุณจะไม่มีทางรู้ว่ามันพลาดอะไรไปบ้าง เพราะสิ่งที่มันพลาดคือสิ่งที่ไม่ปรากฏในสรุป สำหรับงาน CRUD, การเขียนเทสต์ตามแพตเทิร์น หรือการอัปเดตเอกสาร นี่คือการแลกที่ดี แต่สำหรับโค้ดที่แตะเงิน แตะข้อมูลส่วนบุคคล หรือแตะการทำงานพร้อมกัน การประหยัดหลักหมื่นโทเคนไม่คุ้มกับบั๊กเดียวที่หลุดขึ้น production
แหล่งข่าว
อ่านเพิ่มในหมวด เครื่องมือนักพัฒนา
Betelgeuse รัน Qwen3.8 Flash Next ขนาด 68GB บน RTX 3060 กับแรม 16GB ส่วน Basalt วัดให้เห็นว่าเอนจินที่เร่งด้วยแฟล็กลัดทำให้โมเดลลืมของ
Betelgeuse ฟอร์ก llama.cpp ที่เปิดเมื่อ 31 ต.ค. ดึง expert จาก NVMe เข้า VRAM ตามต้องการ อ้าง 22 tok/s แบบไม่ทิ้ง expert แต่ README เตือนเองว่ายังทดลองและตัวเลขมาจากคนละรอบ วันเดียวกันผู้พัฒนา Basalt เผยผลวัดว่าแฟล็กเร่งความเร็วทำคุณภาพ Q8 ตกไปใกล้ Q2
กฎห้ามโคลนเกมของ Claude Code เริ่มกระทบงานจริง บริษัทรับทำเกมกระดานร้องงานลูกค้าหยุด แต่รายงานหลายชิ้นปนกับตัวกรองไซเบอร์คนละเรื่อง
ต่อจากที่เราพบกฎนี้ในไบนารี Claude Code ผู้ใช้เริ่มรายงานว่างานเชิงพาณิชย์ถูกปฏิเสธ และ Tom's Hardware กับ Mashable หยิบไปรายงาน แต่เมื่อไล่ issue ที่อ้างถึง พบว่าหลายรายการเกิดก่อนกฎจะมา จึงน่าจะเป็นตัวกรองด้านไซเบอร์ ส่วน Anthropic ยังไม่ชี้แจง
Claude Code ส่ง transcript ของ background agent ให้โมเดลทุก ~30 วินาทีเพื่อเขียนสถานะ 3–5 คำ ผู้วัดรายงานกินราว 16% และยังปิดแบบทางการไม่ได้
รายงานอิสระพบว่าฟีเจอร์ agent_summary ของ Claude Code ส่ง transcript เต็มของ background agent ไปถามสถานะทุก ~30 วินาที คิดเป็น 16.4% ของค่าใช้จ่ายในระบบของผู้วัด Issue เปิดมาตั้งแต่ ส.ค. ยังไม่มีสวิตช์ปิดที่รองรับ เราตรวจพบโค้ดนี้ใน 2.1.314 และพบกฎใหม่เรื่องเกมที่ไม่อยู่ใน changelog