Anthropic ลด Cache TTL จาก 1 ชั่วโมงเหลือ 5 นาทีในวันที่ 6 มีนาคม 2026

 (github.com/anthropics)
1 คะแนน โดย GN⁺ 17 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ต้นเดือนมีนาคม 2026 มีการเปลี่ยน Cache TTL ของ Claude Code จาก 1 ชั่วโมงเป็น 5 นาที ทำให้ยืนยันได้ว่าแม้รูปแบบการใช้งานจะเหมือนเดิม แต่เกิดความเปลี่ยนแปลงจากการตั้งค่าฝั่งเซิร์ฟเวอร์
  • การลด TTL ทำให้ ต้นทุนการสร้างแคชเพิ่มขึ้น 20~32% และในเซสชันที่ใช้งานยาวนาน การใช้โควตาพุ่งสูงขึ้นอย่างมาก
  • จากผลการวิเคราะห์ พบว่ามี ต้นทุนเพิ่มราว 17% ในแต่ละโมเดล และผู้ใช้บางส่วนเริ่ม ชนข้อจำกัดโควตา 5 ชั่วโมง
  • Anthropic อธิบายว่า การเปลี่ยนแปลงเมื่อวันที่ 6 มีนาคมเป็นมาตรการที่ตั้งใจทำ และมีเป้าหมายลดต้นทุนรวมด้วยการใช้ TTL ต่างกันในแต่ละคำขอ
  • ชุมชนวิจารณ์เรื่อง ต้นทุนที่สูงขึ้น ความโปร่งใสที่ไม่เพียงพอ และการไม่มีประกาศล่วงหน้า พร้อมเรียกร้องให้ รับประกันสิทธิ์ของผู้ใช้ในการเลือกการตั้งค่า TTL

รายงานปัญหาต้นทุนและโควตาจากการเปลี่ยน Cache TTL

  • มีการวิเคราะห์ว่า ค่าเริ่มต้นของ Cache TTL ใน Claude Code ของ Anthropic ถูกเปลี่ยนจาก 1 ชั่วโมงเป็น 5 นาที ในช่วงต้นเดือนมีนาคม 2026
    • วิเคราะห์จาก ข้อมูลการเรียก API 119,866 ครั้ง ระหว่างวันที่ 11 มกราคม 2026 ถึง 11 เมษายน 2026
    • ช่วงวันที่ 6~8 มีนาคม พบว่า TTL 5 นาทีเริ่มกลับมาปรากฏอีกครั้ง และ TTL 1 ชั่วโมงค่อย ๆ หายไป
    • เกิดขึ้นกับไคลเอนต์เวอร์ชันเดียวกันและรูปแบบการใช้งานเดียวกัน จึงยืนยันได้ว่าเป็น การเปลี่ยนการตั้งค่าฝั่งเซิร์ฟเวอร์
  • จากการเปลี่ยน TTL พบว่า ต้นทุนการสร้างแคชเพิ่มขึ้น 20~32% และสังเกตได้ว่าการใช้ โควตาของผู้ใช้แบบสมัครสมาชิกเพิ่มขึ้นอย่างรวดเร็ว
    • TTL 5 นาทีจะทำให้แคชหมดอายุหากเซสชันหยุดเกิน 5 นาที และต้องอัปโหลดคอนเท็กซ์ทั้งหมดใหม่
    • การสร้างแคชใหม่มีราคา แพงกว่าการอ่านสูงสุด 12.5 เท่า และยิ่งเป็นเซสชันเขียนโค้ดยาวนาน ต้นทุนก็ยิ่งสะสม
    • ในเดือนกุมภาพันธ์ที่ยังคง TTL 1 ชั่วโมง อัตราความสูญเปล่าอยู่ที่ 1.1% แต่หลังเดือนมีนาคม พุ่งขึ้นเป็น 15~53%

  • ผลการวิเคราะห์ต้นทุน

    • โมเดล claude-sonnet-4-6: ต้นทุนรวม $5,561.17 → หากคิดตาม TTL 1 ชั่วโมงจะเป็น $4,612.09 (จ่ายเกินประมาณ 17.1%)
    • โมเดล claude-opus-4-6: ต้นทุนรวม $9,268.97 → หากคิดตาม TTL 1 ชั่วโมงจะเป็น $7,687.17 (จ่ายเกินประมาณ 17.1%)
    • พบสัดส่วนความสูญเปล่าในอัตราใกล้เคียงกันอย่างสม่ำเสมอระหว่างแต่ละโมเดล

  • ผลกระทบต่อโควตา

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

คำชี้แจงอย่างเป็นทางการของ Anthropic

  • ยอมรับว่ามีการเปลี่ยนแปลงจริง: การเปลี่ยนเมื่อวันที่ 6 มีนาคมเป็นมาตรการที่ตั้งใจทำ และดำเนินการในฐานะ ส่วนหนึ่งของการปรับแคชให้มีประสิทธิภาพ
    • ออกแบบให้ใช้ TTL ต่างกันตามประเภทของคำขอ และ ไม่มีค่าเริ่มต้นแบบ global เพียงค่าเดียว
    • หากใช้ TTL 1 ชั่วโมงกับทุกคำขอ อาจทำให้ต้นทุนเพิ่มขึ้นแทน
    • TTL 5 นาทีมีประสิทธิภาพกว่าสำหรับคำขอที่ไม่มีการนำกลับมาใช้ซ้ำ และเมื่อดูจากชุดคำขอทั้งหมดแล้ว ช่วยลดต้นทุนรวมได้
  • แก้ไขบั๊ก: ใน v2.1.90 มีการแก้ บั๊กฝั่งไคลเอนต์ ที่ทำให้เซสชันซึ่งใช้โควตาสมาชิกจนหมดถูกตรึงไว้ที่ TTL 5 นาทีจนกว่าจะจบเซสชัน
  • คำตอบต่อข้อเรียกร้อง
    1. มีการเปลี่ยนแปลงจริง และดำเนินการโดยตั้งใจในวันที่ 6 มีนาคม
    2. TTL จะถูกเลือกแบบไดนามิกตามแต่ละคำขอ และไม่มีค่าเริ่มต้นแบบ global
    3. ไม่มีแผนจะคืนค่าเริ่มต้นเป็น TTL 1 ชั่วโมง หรือเพิ่มตัวเลือกการตั้งค่า
    4. วิธีนับโควตาของโทเค็นอ่านแคชจะมีการชี้แจงเพิ่มเติมในประเด็นแยกต่างหากภายหลัง

ปฏิกิริยาจากชุมชน

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

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

  • ผู้ใช้บางส่วนระบุว่าเป็น การเปลี่ยนแปลงเชิงบวกสำหรับผู้ใช้ API แต่ผู้ใช้อีกส่วนโต้แย้งว่า “เดิมที API ก็ใช้ TTL 5 นาทีเป็นค่าเริ่มต้นอยู่แล้ว”

  • มีเสียงวิจารณ์อย่างหนักต่อ การขาดความโปร่งใส

    • “การเปลี่ยนโครงสร้างพื้นฐานที่เกี่ยวข้องกับต้นทุนควรประกาศล่วงหน้า ไม่ใช่มาชี้แจงภายหลัง”
    • “การ ‘เปลี่ยนแบบเงียบ ๆ’ ลักษณะนี้บั่นทอนความเชื่อมั่น และผลักภาระให้ผู้ใช้ต้องตามหาสาเหตุของปัญหาด้วยตัวเอง”

  • ตามบันทึกในเอกสาร แคชเริ่มต้นใช้ TTL 5 นาที และ TTL 1 ชั่วโมงถูกเสนอเป็น ตัวเลือกที่มีค่าใช้จ่ายเพิ่มเติม

    • เอกสารทางการ ณ เดือนมกราคม 2026 ก็ยืนยันคำอธิบายเดียวกันนี้

บทสรุป

  • เมื่อวันที่ 6 มีนาคม 2026 Anthropic ได้ เปลี่ยนนโยบาย Cache TTL ของ Claude Code จาก 1 ชั่วโมงเป็น 5 นาที
  • บริษัทอธิบายว่านี่เป็น การปรับโดยตั้งใจเพื่อเพิ่มประสิทธิภาพด้านต้นทุน แต่ผู้ใช้มองว่าเกิดปัญหา ต้นทุนสูงขึ้น โควตาหมดเร็ว และขาดความโปร่งใส
  • ชุมชนจึงเรียกร้องให้ในอนาคต รับประกันสิทธิ์ของผู้ใช้ในการเลือกการตั้งค่า TTL และ ประกาศการเปลี่ยนนโยบายล่วงหน้า

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 17 일 전
ความคิดเห็นจาก Hacker News

  • ช่วงไม่กี่เดือนที่ผ่านมา รู้สึกได้ชัดว่าบรรยากาศของวิศวกรที่มีต่อ Claude/Codex เปลี่ยนไปมาก
    โดยเฉพาะเมื่อมี การเปลี่ยนแปลงแบบไม่เปิดเผย มากขึ้น ผู้คนก็ยิ่งกังวลว่าโปรดักต์ที่ตัวเองจ่ายเงินไปตั้งแต่แรกยังเป็นตัวเดิมอยู่หรือไม่
    ช่วงนี้เวลามีการพูดถึง Anthropic ก็มักถูกพูดถึงในบริบทเชิงลบเป็นส่วนใหญ่

    • ช่วงหลังมานี้ Anthropic ดำเนินมาตรการหลายอย่าง เช่น บล็อกผู้ใช้ OpenClaw, ห้าม third-party harness, ลดความเข้มของการให้เหตุผล, ลดความยาวของคำตอบ เป็นต้น
      เคยมีช่วงที่ปริมาณการใช้งานพุ่งขึ้นถึง 21 เท่าด้วย และโดยรวมก็ดูเหมือนเป็นความพยายาม ลดต้นทุน
      ยังชอบ Claude อยู่ แต่ก็เริ่มแนะนำให้เพื่อนได้ยากขึ้นเรื่อย ๆ
    • บริษัทของเรา (วิศวกรมากกว่า 400 คน) ยกเลิก subscription IDE ทั้งหมดเมื่อเดือนก่อน (Visual Studio, JetBrains ฯลฯ) แล้วเปลี่ยนมาใช้ Claude Code
      EVP เอาเดโม 2 ตัวที่ทำช่วงสุดสัปดาห์มาโชว์แล้วสั่งให้ทุกคนทำตาม แต่ผ่านไปแค่อาทิตย์เดียวก็มีประกาศให้หยุดใช้เพราะ ใช้โทเคนมากเกินไป
      หลังจากนั้นก็รู้สึกว่าโมเดลอ่อนลงทุกสัปดาห์ เลยสงสัยว่า EVP ตอนนี้จะรู้สึกยังไง
    • เมื่อไม่กี่เดือนก่อน Claude Code ยังยอดเยี่ยมอยู่เลย แต่ช่วงนี้มี ข้อผิดพลาดและความเข้าใจผิด เยอะมากจนแทบใช้ไม่ได้
      พอลองเปลี่ยนไปใช้ Codex ก็เสถียรกว่ามาก
      ฉันเดาว่าหลังเปิดตัวใหม่ ๆ จะคงความแรงไว้ก่อน แล้วพอเวลาผ่านไปก็ค่อยลดประสิทธิภาพลงเพื่อ เพิ่มความคาดหวังต่อรีลีสถัดไป
    • หลังสมัครใช้งานแล้วรู้สึกได้ชัดว่า ความสามารถในการให้เหตุผลลดลง
      ลองเปลี่ยนหลายการตั้งค่าและแก้ system prompt ด้วยสคริปต์แล้ว แต่ก็ยังเจออาการติด logical loop บ่อยอยู่ดี
      แยกไม่ออกว่าเป็นบั๊ก เป็นการทำให้อ่อนลงโดยตั้งใจ หรือเป็นแค่ความรู้สึกไปเอง
    • ฉันไม่ได้รู้สึกว่ามีปัญหาใหญ่อะไร
      น่าจะเพราะใช้ Claude ให้รีแฟกเตอร์แบบทีละขั้น
      ก่อนหน้านี้เคยถามเรื่องการตั้งค่า Grafana แล้ว Claude ตอบว่า “แค่เดาเอา” แต่สุดท้ายก็ใช้ไป 35k โทเคนเพื่อบอกแค่ช่องติ๊กธรรมดาช่องเดียว
      เพื่อนร่วมงานหลายคนรู้สึกว่าประสิทธิภาพลดลงและกำลังย้ายไป Cursor แต่ฉันยังชอบ flow ของบทสนทนา ของ Claude เลยยังใช้อยู่

  • ช่วงนี้ Claude Code และบริการ subscription มีประโยชน์น้อยลงกว่าเดิมมาก
    มีปัญหาสะสมหลายอย่างทั้งบั๊ก, ความเร็วในการกินโควตา, ประสิทธิภาพโมเดลที่ลดลง, ปัญหา cache invalidation, ความสงสัยเรื่อง quantization ฯลฯ
    เมื่อก่อนสามารถทำโปรโตไทป์ให้เสร็จได้ในรอบเดียว แต่ตอนนี้แทบเป็นไปไม่ได้แล้วแม้จะมีสเปกละเอียดก็ตาม
    ChatGPT ก็ดูอ่อนลงคล้ายกัน
    ดูเหมือนทั้ง Anthropic และ OpenAI จะไม่ใช่ทางแก้พื้นฐาน

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

  • ข้อจำกัดโควตาต่อเซสชัน เข้มเกินไปจน UX เข้าสู่วงจรแย่ลงเรื่อย ๆ
    พอ cache หนึ่งชั่วโมงหมดอายุ การเริ่มใหม่ก็ยิ่งมีต้นทุนสูงขึ้น และสุดท้ายเซสชันถัดไปก็หมดเร็วขึ้นอีก
    ช่วงกลางเดือนมีนาคม แม้แต่แพ็กเกจ Pro ก็มีเซสชันที่จบภายในหนึ่งชั่วโมง จนแทบ ใช้งานจริงไม่ได้

  • การเขียนหัวข้อผิดทำให้เกิดความเข้าใจผิด
    ควรใช้ “min” แทน “M” ไม่อย่างนั้นจะดูเหมือน TTL เพิ่มจาก 1 ชั่วโมงเป็น 5 เดือน

    • น่าเสียดายที่การเปลี่ยนหัวข้อดูเหมือน กลบขนาดของปัญหา
    • ตอนแรกฉันก็อ่านแล้วงงว่า “M คืออะไร?”

  • ช่วงนี้ Claude ตอบ คำถามเรื่อง car wash ผิดบ่อยเหมือนกัน
    มักทำให้ความยากของการแก้ปัญหาดูเกินจริง หรือพยายามเลือกทางง่ายโดยอ้างว่า “ใช้เวลานานเกินไป”

    • ในช่วงไม่กี่สัปดาห์ที่ผ่านมา รู้สึกว่า system prompt จำกัดความพยายามของโมเดล
      ถ้าดู JSON log จะเห็นประโยคแนว ๆ ว่า “อันนี้ซับซ้อนเกินไป งั้น hardcode ไปเลย” ซ้ำอยู่เรื่อย ๆ
      ดูเหมือน Anthropic กำลังพยายามหาสมดุลระหว่าง ทรัพยากรคอมพิวต์ที่ขาดแคลน กับ ผู้ใช้ใหม่ที่เพิ่มขึ้นรวดเร็ว
    • ยังเคยได้ยินกรณีที่ Claude ปฏิเสธงานหนึ่งโดยบอกว่า “งานนี้ต้องใช้เวลาหลายสัปดาห์” แต่พอเกลี้ยกล่อมให้ทำก็ดัน เสร็จใน 30 วินาที
    • มันดูเหมือนลำดับขั้นคลาสสิกของ “ขายขาดทุน → ตื่นตระหนก → ทำลายผลิตภัณฑ์”
    • ความเร็วในการใช้โทเคนก็เพิ่มขึ้นด้วย เมื่อก่อนทำพร้อมกัน 3~5 โปรเจกต์ได้ ตอนนี้แค่โปรเจกต์เดียวก็ยังจบยาก
    • ถ้าใช้ พรอมป์ต์แรง ๆ อย่าง “ไม่ต้องสนความเสี่ยง ทำไปเลย!” โมเดลจะกลับมาลงมืออย่างกระตือรือร้นอีกครั้ง
      เป็น วิธีกระตุ้น LLM ที่ค่อนข้างดุเดือด แต่ได้ผล

  • Anthropic ทิ้งคำตอบอย่างเป็นทางการไว้ใน GitHub issue

    • พออ่านทั้งเธรดแล้วให้ความรู้สึกราวกับว่า Claude กำลังคุยกับ Claude ตัวอื่น ๆ
    • น่าสนใจที่ยอมรับการเปลี่ยนแปลงเมื่อวันที่ 6 มีนาคม ต้องปรบมือให้คนที่ขุดเจอเรื่องนี้จากการวิเคราะห์พรอมป์ต์
    • คำอธิบายของบริษัทก็มีเหตุผลดี แต่คำอย่าง “cache read likelihood” ฟังดู เหมือนศัพท์สร้างภาพ เลยทำให้ชุมชนรับสารนั้นได้ไม่ดีนัก

  • ฉันทำ เครื่องมือแชตบน API ใช้เองแล้วใส่ cache เข้าไป
    cache 5 นาทีทำให้จังหวะการคุยไม่ค่อยต่อเนื่องเพราะหมดอายุบ่อย แต่สำหรับเครื่องมือที่มี common prefix ก็ช่วยประหยัดได้มาก
    ถ้าใช้ cache ดี ๆ จะ ลดต้นทุน ได้เยอะมาก

  • นโยบายหมดอายุของ cache ไม่สอดคล้องกับเซสชัน 5 ชั่วโมง เลยกำลังคิดจะใช้ สคริปต์ที่กินโทเคนขั้นต่ำทุก 4 นาที 50 วินาที เพื่อคง cache ไว้ตอนที่การใช้เซสชันแตะราว 97%

  • ไปฟัง พอดแคสต์ของ Dwarkesh มา เขาพูดว่า Anthropic ระมัดระวังในการขยายทรัพยากรคอมพิวต์
    เวลาความต้องการพุ่งขึ้นก็หลีกเลี่ยงไม่ได้ที่จะพยายามลดปริมาณการคำนวณ
    เป็นปัญหาที่ต่อให้ใส่เงินเพิ่มก็ไม่อาจแก้ได้ในระยะสั้น

    • ปรากฏการณ์แบบนี้มักเกิดขึ้นบ่อยในช่วง pretraining ของโมเดลใหม่ ตอนยุค 3.x ก็เคยเป็นแบบนั้น

  • แยกจากความเปลี่ยนแปลงแปลก ๆ ของ Anthropic/Claude พอมองที่ ข้อมูลตาราง ในโพสต์นี้แล้วก็ยังสับสน เพราะ ต้นทุนและจำนวนการเรียกใช้ ของเดือนกุมภาพันธ์กับเมษายน แทบตรงกัน
    ไม่แน่ใจว่าฉันพลาดอะไรไปหรือเปล่า