ในการพัฒนา AI Agent บน Claude API ปัจจัยสำคัญที่สุดที่ช่วยลดทั้งค่าใช้จ่าย (Cost) และความหน่วง (Latency) ได้อย่างเห็นผล ไม่ใช่การเปลี่ยนไปใช้โมเดลที่เล็กลง แต่คือการดัน Prompt Cache Hit Rate ให้สูงที่สุด

Thariq Shihipar วิศวกรจากทีม Claude Code ของ Anthropic เปิดเผยเบื้องหลังผ่านบทความ Lessons from Building Claude Code: Prompt Caching Is Everything และโพสต์บน X (@trq212) ว่า สถาปัตยกรรม harness ของ Claude Code ถูกสร้างขึ้นโดยมี Prompt Caching เป็นศูนย์กลางตั้งแต่วันแรก

ตัวเลขสำคัญที่กำหนดเกมนี้คือ Cache Read มีราคาเพียง 0.1 เท่าของ Base Input หรือพูดง่ายๆ คือ Prompt ที่ติด Cache จะจ่ายเพียง 10% ของราคาปกติเท่านั้น แต่ถ้าหลุด Cache (Cache Miss) จะต้องจ่ายเต็ม 100% ใหม่ทั้งหมด นักพัฒนาที่สร้าง Agent โดยไม่เข้าใจกลไกนี้ อาจกำลังจ่ายค่า API แพงกว่าที่ควรจะเป็นถึง 10 เท่าในทุกๆ รอบการทำงาน

ทำไม Prompt Caching ถึงเป็นหัวใจสำคัญของ Agent

Thariq ชี้ว่า ผลิตภัณฑ์ประเภท Long-running Agent อย่าง Claude Code จะเกิดขึ้นไม่ได้เลยหากไม่มี Prompt Caching เพราะระบบต้องนำผลการคำนวณจากข้อความก่อนหน้ามาใช้ซ้ำ เพื่อให้ตอบสนองได้เร็วและคุมค่าใช้จ่ายอยู่

ทีมงาน Claude Code จริงจังกับเรื่องนี้ถึงขั้นตั้งระบบแจ้งเตือน (Alert) ผูกกับ Cache Hit Rate โดยตรง หากตัวเลขตกลงเพียงไม่กี่เปอร์เซ็นต์ ทีมจะประกาศเป็น Incident ระดับ SEV ทันทีเหมือนกรณี Production ล่ม เพราะส่งผลกระทบต่อต้นทุนและประสบการณ์ผู้ใช้อย่างมีนัยสำคัญ

สำหรับนักพัฒนาทั่วไป เรื่องนี้ไม่ใช่แค่เทคนิคการปรับแต่งแบบทางเลือก (Nice-to-have) แต่เป็นข้อกำหนดเชิงสถาปัตยกรรมที่ต้องวางแผนตั้งแต่ก่อนเขียนโค้ดบรรทัดแรก บทเรียน 7 ข้อต่อไปนี้คือข้อสรุปจากประสบการณ์จริงของทีม Anthropic

กฎข้อที่ 1: จัดลำดับ Prompt จาก Static ไป Dynamic เสมอ

Prompt Caching ของ Claude API ทำงานด้วยระบบ Prefix Matching ระบบจะจำข้อมูลตั้งแต่จุดเริ่มต้นของ Request ไปจนถึงจุดตัด cache_control แต่ละจุด ดังนั้น ลำดับของข้อมูลจึงมีความสำคัญสูงสุด เพราะเราต้องการให้แต่ละ Session ใช้ Prefix ร่วมกันให้ได้มากที่สุด

ทีม Claude Code จัดโครงสร้าง Prompt ออกเป็น 4 ชั้นในแนวตั้ง โดยวาง ข้อมูลคงที่ (Static) ไว้ด้านบน และข้อมูลแปรผัน (Dynamic) ไว้ด้านล่าง:

1. Static System Prompt + Tools: แคชร่วมกันได้ทั่วโลกในทุก Session
2. CLAUDE.md: แคชรายโปรเจกต์
3. Session Context: แคชเฉพาะภายในแต่ละ Session
4. Conversation Messages: ส่วนบทสนทนาที่ขยายขึ้นเรื่อยๆ ในแต่ละรอบ

[ Layer 1: Static System Prompt + Tools ]   ← cache_control breakpoint #1
[ Layer 2: CLAUDE.md ]                       ← cache_control breakpoint #2
[ Layer 3: Session Context ]                 ← cache_control breakpoint #3
[ Layer 4: Conversation Messages ]           ← dynamic (ไม่ใส่ breakpoint)

Claude API อนุญาตให้ตั้งจุดตัด cache_control ได้สูงสุด 4 จุดต่อ Request จึงต้องวางตำแหน่งอย่างรอบคอบ

Thariq เตือนว่าโครงสร้างนี้เปราะบางมาก ความผิดพลาดเล็กน้อยอาจทำให้ Prefix เปลี่ยนและหลุดแคชทั้งระบบ เช่น:

• การใส่ Timestamp ละเอียดลงใน System Prompt ซึ่งเปลี่ยนทุกวินาที
• การสลับลำดับ Tool Definition แบบไม่คงที่ระหว่าง Deploy
• การเปลี่ยน Parameter ของ Tool ระหว่าง Session

กฎข้อที่ 2: ส่งข้อมูลอัปเดตผ่าน Message ห้ามแตะ System Prompt

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

แนวทางที่ถูกต้องคือ ส่งข้อมูลอัปเดตผ่าน Message ในรอบถัดไป โดยใช้แท็กกำกับ เช่น <system-reminder> แนบไปกับ User Message หรือ Tool Result วิธีนี้ช่วยให้ System Prompt คงเดิม Prefix ไม่เปลี่ยน และยังประหยัดค่าใช้จ่ายได้เต็มที่

กฎข้อที่ 3: ห้ามสลับโมเดลกลาง Session

Prompt Cache ของ Claude API จะแยกขาดจากกันตามแต่ละโมเดล การสลับโมเดลกลางคันจึงทำให้ต้นทุนพุ่งสูงขึ้นอย่างไม่คาดคิด

Thariq ยกตัวอย่างว่า หากบทสนทนาดำเนินไปจนมี Context ถึง 100,000 โทเคนบน Opus แล้วเราต้องการถามคำถามสั้นๆ ง่ายๆ การสลับไปใช้ Haiku จะ แพงกว่า การให้ Opus ตอบต่อ เพราะ Haiku ต้องเริ่มสร้าง Cache ใหม่ทั้งหมดตั้งแต่ต้น

หากจำเป็นต้องใช้โมเดลอื่น ให้แยกการทำงานผ่าน Subagent เช่น ให้ Agent หลักส่งงานย่อยไปให้ Subagent ที่รันด้วย Haiku ทำงานเฉพาะกิจ (เช่น สำรวจ Codebase) โดยไม่แตะต้อง Prefix ของ Session หลัก

กฎข้อที่ 4: ห้ามเพิ่มหรือลบ Tool กลาง Session

การเปลี่ยนรายการ Tool กลางบทสนทนาเป็นสาเหตุยอดฮิตที่ทำให้ Cache พัง เพราะคำนิยามของ Tool (Tool Definitions) เป็นส่วนหนึ่งของ Cached Prefix การเพิ่มหรือตัด Tool แม้แต่ตัวเดียวจะทำให้ Hash เปลี่ยนทันที

แม้หลายคนจะคิดว่าการตัด Tool ที่ไม่ได้ใช้ออกจะช่วยประหยัดโทเคน แต่ในความเป็นจริง การทำเช่นนั้นจะทำให้เราต้องจ่ายค่า Input เต็มจำนวนของประวัติการคุยทั้งหมดในรอบถัดไป ซึ่งไม่คุ้มค่าอย่างยิ่ง

กฎข้อที่ 5: Plan Mode คือการออกแบบสถาปัตยกรรมรอบ Cache

ฟีเจอร์ Plan Mode ของ Claude Code เป็นตัวอย่างคลาสสิกของการแก้ปัญหาเชิงวิศวกรรม เมื่อผู้ใช้เปิด Plan Mode (สั่งให้อ่านโค้ดได้อย่างเดียว ห้ามแก้ไฟล์) แทนที่ทีมงานจะตัด Tool อย่าง Edit หรือ Write ออก ซึ่งจะทำให้ Cache พัง ทีมงานเลือกใช้วิธีคง Tool ทั้งหมดไว้เหมือนเดิม แล้วเพิ่ม Tool ใหม่เข้าไป 2 ตัว คือ EnterPlanMode และ ExitPlanMode

การสลับโหมดจะทำผ่าน Message สั่งการในรอบถัดไปเพื่อบอกให้โมเดลรู้ว่ากำลังอยู่ในโหมดวางแผน ผลลัพธ์คือ Tool List คงเดิม Prefix ไม่หลุด และยังควบคุมพฤติกรรมของ AI ได้ตามต้องการ

หลักการสำคัญคือ ให้ใช้ "การเรียก Tool" เป็นตัวเปลี่ยนสถานะของระบบ แทนที่จะใช้ "การเพิ่มหรือตัด Tool"

กฎข้อที่ 6: จัดการ Tool จำนวนมากด้วย Tool Search และ defer_loading

เมื่อ Agent ต้องเชื่อมต่อกับ MCP Server ที่มี Tool หลายสิบตัว การใส่ Schema เต็มของทุก Tool จะเปลืองโทเคนมหาศาล แต่การตัด Tool ออกก็ทำให้แคชหลุด

ทางออกของ Anthropic คือการใช้กลไก defer_loading: true โดยส่งเฉพาะโครงร่างย่อ (Stub) ของ Tool ในลำดับเดิมเสมอ เมื่อโมเดลต้องการใช้งานจริง จะค้นหาผ่าน Tool Search แล้วระบบจึงจะโหลด Schema ตัวเต็มเข้ามา วิธีนี้ช่วยให้ Prefix คงที่และประหยัดค่าใช้จ่ายไปพร้อมกัน

กฎข้อที่ 7: การ Compaction ต้อง Fork จาก Parent Prefix ให้ตรงกันทุกไบต์

เมื่อ Context Window เริ่มเต็ม ระบบต้องสรุปย่อบทสนทนาเดิม (Compaction) เพื่อให้ทำงานต่อได้ หลุมพรางที่พบบ่อยคือการเปิด Request ใหม่เพื่อสั่งสรุปความ โดยใช้ System Prompt สั้นๆ และไม่ใส่ Tool ซึ่งจะทำให้ Prefix ไม่ตรงกับบทสนทนาเดิม และต้องจ่ายค่า Input เต็มจำนวนของเนื้อหาทั้งหมด

วิธีที่ถูกต้องคือ Fork จาก Parent Prefix โดยส่งคำขอที่มี System Prompt, Tool Set และ History ชุดเดิมทั้งหมด แล้วแนบคำสั่งสรุปความเข้าไปที่ท้ายสุดของ Message

POST /messages
  system: <ชุดเดิมของ parent ตรงกัน byte ต่อ byte>
  tools:  <ชุดเดิมของ parent ตรงกัน byte ต่อ byte>
  messages: [
    ...conversation เดิมของ parent ทั้งหมด,
    { role: "user", content: "<compaction prompt>" }   // append ไว้ท้ายสุด
  ]

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

ตัวเลขต้นทุนที่พิสูจน์ความคุ้มค่า

ตารางเปรียบเทียบตัวคูณราคาของ Claude API จาก Anthropic API Prompt Caching Reference:

สำหรับ Claude Opus ราคา Base Input อยู่ที่ 5 ดอลลาร์ต่อ 1 ล้านโทเคน แต่เมื่อติด Cache จะลดเหลือเพียง 0.50 ดอลลาร์ต่อ 1 ล้านโทเคน

เงื่อนไขขั้นต่ำในการเกิด Cache คือต้องมีขนาดตั้งแต่ 4,096 โทเคน สำหรับ Opus และ Haiku ส่วน Sonnet อยู่ที่ 1,024 โทเคน โดยสามารถติดตามประสิทธิภาพได้จากฟิลด์ cache_creation_input_tokens, cache_read_input_tokens และ input_tokens ใน response.usage

สรุป 4 แนวทางปฏิบัติสำหรับนักพัฒนา

1. ยึด Prefix Matching เป็นแกนหลักของการออกแบบ: จัดเรียงเนื้อหาจาก Static ไป Dynamic และคุมไม่ให้ Timestamp หรือลำดับของ Tool สลับไปมา
2. ส่งการเปลี่ยนแปลงผ่าน Message Channel เสมอ: ใช้รูปแบบ <system-reminder> หรือ Tool Result แทนการแก้ System Prompt
3. รักษา Tool Set และ Model ให้คงที่ตลอด Session: หากต้องการเปลี่ยนพฤติกรรม ให้ใช้ Pattern แบบ State Transition หรือใช้ Subagent
4. กระบวนการ Fork ต้องแชร์ Prefix กับ Parent เสมอ: ใช้กับทั้งงานสรุปความ (Compaction) และงานคำนวณคู่ขนาน พร้อมทั้งมอนิเตอร์ Cache Hit Rate อย่างใกล้ชิด