Anthropic prompt caching เปิดใช้ง่ายแต่ก็อ่านผลผิดได้ง่ายเช่นกัน คำขอแรกอาจมีราคาแพงขึ้น คำขอถัดมาอาจ miss โดยไม่มี error และ prefix ที่ "ถูกแคช" อาจสั้นเกินไปที่จะเข้าเกณฑ์
คำตอบโดยย่อ: วาง cache breakpoint ไว้ท้ายเนื้อหาที่เหมือนกันทุกคำขอ แล้วยืนยันว่า response ถัดไปรายงาน cache_read_input_tokens มากกว่าศูนย์ผ่าน ฟิลด์ usage ของ response จาก Anthropic เทียบราคาการเขียนแคชครั้งแรกและการอ่านทุกครั้งกับจำนวนการนำกลับมาใช้ซ้ำที่คุณคาดไว้: บน Claude Sonnet 5.5 การอ่านหนึ่งครั้งภายในหน้าต่างห้านาทีคืนทุนส่วนต่างของการเขียนแล้ว ส่วนแคชหนึ่งชั่วโมงต้องอ่านสองครั้ง ตัวเลข API เหล่านี้ไม่ได้บอกว่าการคิดโควตา subscription ของ Claude ทำงานอย่างไร
ราคาและรายละเอียดผลิตภัณฑ์ด้านล่างตรวจสอบเมื่อ 4 ตุลาคม 2026
Anthropic prompt caching ทำงานอย่างไร และเปิดใช้งานอย่างไร?
Claude prompt caching นำ prefix ของพรอมต์ที่ตรงกันกลับมาใช้ซ้ำ เพื่อให้โมเดลอ่าน input ที่แคชไว้แทนการประมวลผลเป็น input ใหม่ทุกครั้ง สำหรับการทดสอบ API ครั้งแรก ให้ใช้ automatic caching: เพิ่มฟิลด์ cache_control ระดับบนสุดลงในคำขอ Messages ในการเรียก Python ของ Anthropic Messages API ที่มีอยู่ ให้เพิ่มอาร์กิวเมนต์คำขอนี้ (แทรกไว้ใน client.messages.create(...)):
cache_control={"type": "ephemeral"}
การตั้งค่า cache control ระดับบนสุดของ Anthropic นี้มาจาก เอกสาร prompt caching ตัวอย่างปัจจุบันใช้ client.messages.create(...) ส่วนเส้นทางเก่า client.beta.prompt_caching.messages.create(...) ไม่จำเป็นอีกต่อไป สำหรับเอกสารหรือชุดเครื่องมือที่คงที่ breakpoint ระดับบล็อกแบบระบุชัดช่วยให้คุณควบคุมได้แม่นยำว่า prefix ที่นำกลับมาใช้ซ้ำสิ้นสุดที่ไหน Anthropic อนุญาตให้มี breakpoint ได้สูงสุดสี่จุด
ในการยืนยัน hit ให้ส่งคำขอสองครั้งด้วยโมเดลเดียวกันและ prefix ที่ไม่เปลี่ยนแปลง โดยคำขอครั้งที่สองเริ่มก่อนแคชหมดอายุ อ่านออบเจกต์ usage ของ response:
| ฟิลด์ | บอกอะไรคุณ |
|---|---|
cache_creation_input_tokens |
โทเคน input ที่ถูกเขียนลงแคชใน response นี้ |
cache_read_input_tokens |
โทเคน input ที่เสิร์ฟจากแคช |
input_tokens |
input ที่ไม่ถูกแคชหลัง breakpoint สุดท้าย |
คำขอแรกควรแสดงการสร้างแคช คำขอถัดมาควรแสดงการอ่านแคช ส่วน automatic caching อาจเขียนส่วนท้ายใหม่อีกด้วย Anthropic นิยาม input รวมว่าเป็นผลรวมของสามฟิลด์นี้ ดังนั้นอย่าใช้ input_tokens เพียงอย่างเดียวเป็นขนาดพรอมต์รวม ถ้าตัวนับแคชทั้งสองเป็นศูนย์ แสดงว่าพรอมต์ไม่ถูกแคช response usage ของ API พิสูจน์พฤติกรรมระดับคำขอที่คุณสังเกตได้ แต่มันไม่ได้ยืนยันอัตรา hit ของ workload จริงทั้งหมดของคุณ
ควรใช้แคชห้านาทีหรือหนึ่งชั่วโมง?
ใช้แคชห้านาทีเมื่อการเรียกใช้ prefix เดิมซ้ำภายในห้านาที เลือกตัวเลือกหนึ่งชั่วโมงเมื่อช่วงห่างจริงเกินหน้าต่างนั้นเป็นประจำแต่ยังอยู่ภายในหนึ่งชั่วโมง Anthropic เริ่มจับเวลา TTL เมื่อคำขอเริ่ม ไม่ใช่เมื่อ response สิ้นสุด การสตรีมสี่นาทีจึงเหลือเวลาให้คำขอถัดไปมาถึงราวหนึ่งนาที
จุดคุ้มทุนขึ้นกับจำนวนการอ่านที่สำเร็จ ไม่ใช่แค่ว่าพรอมต์มี breakpoint หรือไม่ เพื่อเปรียบเทียบง่าย ๆ ให้ใช้ prefix ขนาดคงที่ 100,000 โทเคนบน Claude Sonnet 5.5 ตารางราคาปัจจุบันของ Anthropic ระบุ $2 ต่อล้านโทเคน input ปกติ, $2.50 ต่อล้านสำหรับการเขียนแคชห้านาที, $4 ต่อล้านสำหรับการเขียนแคชหนึ่งชั่วโมง และ $0.20 ต่อล้านสำหรับการอ่าน การอ่านคือ 0.1× ของ input พื้นฐานสำหรับโมเดลนี้
สำหรับการอ่านแคช R ครั้ง prefix ที่แคชไว้มีต้นทุน write rate + (R × read rate) ถ้าไม่แคช ต้นทุนคือ base rate × (1 + R) นั่นให้ยอดรวมต่อไปนี้สำหรับตัว prefix อย่างเดียว ไม่รวม output และส่วนท้ายคำขอที่เปลี่ยนแปลง:
| จำนวนการอ่านหลังการเขียนครั้งแรก ภายใน TTL | ไม่แคช | แคช 5 นาที | แคช 1 ชั่วโมง |
|---|---|---|---|
| 0 | $0.20 | $0.25 (125%) | $0.40 (200%) |
| 1 | $0.40 | $0.27 (67.5%) | $0.42 (105%) |
| 2 | $0.60 | $0.29 (48.3%) | $0.44 (73.3%) |
| 4 | $1.00 | $0.33 (33%) | $0.48 (48%) |
| 10 | $2.20 | $0.45 (20.5%) | $0.60 (27.3%) |
เปอร์เซ็นต์คือต้นทุนแบบแคชหารด้วยต้นทุนแบบไม่แคช บนโมเดลนี้และภายใต้สมมติฐานเหล่านี้ แคชห้านาทีถูกกว่าหลังอ่านหนึ่งครั้ง ส่วนแคชหนึ่งชั่วโมงถูกกว่าหลังอ่านสองครั้ง การเขียนแคชหนึ่งชั่วโมงครั้งแรกมีราคาเป็นสองเท่าของอัตรา input ปกติ การยืด TTL จึงไม่ใช่การประหยัดโดยอัตโนมัติ ตัวคูณ cache-read ปัจจุบันของ Anthropic ต่างกันไปในบางโมเดล — 5% สำหรับ Opus 5.5 และ 2.5% สำหรับ Fable 5.1 กับ Mythos 5.1 — ดังนั้นให้คำนวณใหม่จากแถวของโมเดลที่คุณเรียกใช้จริง ราคาตรวจสอบเมื่อตุลาคม 2026
โพสต์ LinkedIn ของ Roy Derks ยกตัวอย่างสถานการณ์สมมติที่อธิบายเสียงบ่นว่า "แคชทำให้บิลฉันแพงขึ้น": เอเจนต์ตัวหนึ่งรันทุก 10 นาทีด้วยพรอมต์ที่นำกลับมาใช้ซ้ำได้ขนาด 100,000 โทเคน การเรียกทั้งสิบครั้งจึงมาถึงหลังรายการแคชห้านาทีหมดอายุแล้ว ทุกการเรียกจ่ายค่าเขียน 1.25× และไม่มีครั้งไหนได้การอ่าน 0.1× input ที่ไม่แคชราคา $10 จึงกลายเป็น $12.50 แพงขึ้น 25% นั่นคือสถานการณ์ที่คำนวณขึ้น ไม่ใช่ workload ที่วัดจริง เทียบตัวนับ usage และช่วงห่างการเรียกของคุณเองก่อนจะพยากรณ์อะไรจากมัน
ทำไมแคชของฉันถึงไม่ hit?
cache hit ต้องการ prefix เดิมจนถึง breakpoint ที่ทำเครื่องหมายไว้ และความยาวพรอมต์ที่เข้าเกณฑ์
| สิ่งที่คุณเห็น | สาเหตุที่เป็นไปได้ | วิธีแก้ |
|---|---|---|
| ตัวนับแคชทั้งสองค้างอยู่ที่ศูนย์ | prefix ที่ทำเครื่องหมายสั้นกว่าค่าขั้นต่ำของโมเดล สำหรับ Claude Sonnet 5.5 ค่าขั้นต่ำปัจจุบันคือ 512 โทเคน คำขอที่สั้นกว่าจะรันต่อโดยไม่มี error เรื่องแคช | ใส่เนื้อหาที่คงที่ให้มากพอที่จะผ่านค่าขั้นต่ำของโมเดล แล้วตรวจ usage ของ response ถัดไป |
| การเขียนใหม่ทั้งหมดหรือจำนวนมากตามหลังการเปลี่ยนคำขอเล็ก ๆ | ไบต์ที่เปลี่ยนอยู่ก่อน breakpoint ตาราง invalidation ของ Anthropic ครอบคลุมการแก้ tool definitions, web search, citations และ speed toggles, tool_choice, รูปภาพ และ thinking settings การเปลี่ยน tool definition ทำให้แคชทั้งหมดเป็นโมฆะ |
วางคำสั่งและ tool definitions ที่คงไว้ก่อน แล้วย้าย timestamp ค่าที่เปลี่ยนตามคำขอ และ input ใหม่ของผู้ใช้ไปหลัง breakpoint ของ prefix ที่คงที่ |
| บล็อกสุดท้ายที่เปลี่ยนถูกเขียนใหม่ทุกการเรียก | Automatic caching ย้าย breakpoint ไปยังบล็อกสุดท้ายที่แคชได้ ถ้าบล็อกนั้นเปลี่ยน ก็จะไม่มีรายการที่นำกลับมาใช้ซ้ำที่ขอบเขตคงที่ก่อนหน้า | วาง breakpoint แบบระบุชัดบนบล็อกสุดท้ายที่ยังคงเหมือนเดิม |
| ช่วงห่างทำให้เกิดการเขียนโดยไม่คาดคิด | อายุแคช หมดแล้ว หรือ response ยาว ๆ ใช้ TTL ไปเกือบหมดก่อนคำขอถัดไปเริ่ม | วัดช่วงห่างระหว่างเวลาเริ่มคำขอ ใช้ ttl: "1h" ถ้าหน้าต่างการนำกลับมาใช้ซ้ำที่คุณคาดไว้ต้องการมันและค่าเขียนที่เพิ่มนั้นคุ้ม |
| tools หรือ messages ดูเหมือนกันแต่การอ่านลดลง | ลำดับหรือ serialization เปลี่ยน prefix ไป คำแนะนำ troubleshooting ของ Anthropic เตือนว่าลำดับคีย์ JSON ที่ไม่คงที่ภายในบล็อก tool_use ทำลายการนำกลับมาใช้ซ้ำได้ |
รักษาลำดับของ tools และ messages ให้คงที่ และ serialize ค่าที่มีโครงสร้างแบบ deterministic |
prefix ของคำขอเรียงลำดับเป็น tools แล้ว system แล้ว messages การเปลี่ยนแปลงต้นลำดับนั้นทำให้เนื้อหาที่แคชไว้ถัดไปเป็นโมฆะ breakpoint คือขอบเขตที่ Anthropic เขียนรายการ มันไม่ได้ค้นย้อนกลับและสร้างรายการแคชที่ขาดหายไปให้บล็อกคงที่ก่อนหน้า การมองย้อนของมันพบได้เฉพาะรายการที่คำขอก่อนหน้าเขียนไว้แล้วเท่านั้น ดู คำแนะนำเรื่อง invalidation และ breakpoint ของ Anthropic เมื่อฟิลด์ usage แสดง miss ที่คุณอธิบายไม่ได้
Claude Code prompt caching ทำงานอย่างไร?
Claude Code จัดการ prompt caching โดยอัตโนมัติ คุณไม่ต้องเพิ่ม cache_control ในเซสชัน Claude Code ปกติ เลเยอร์คำขอของมันวาง system prompt และบริบทโปรเจกต์ไว้ก่อนบทสนทนาที่โตขึ้นเรื่อย ๆ การเปลี่ยนเลเยอร์ก่อนหน้าจึงทำให้ทุกอย่างหลังมันเป็นโมฆะได้
TTL ขึ้นกับการยืนยันตัวตน: คู่มือ Claude Code prompt caching ปัจจุบัน ระบุหนึ่งชั่วโมงสำหรับบทสนทนาหลักของ subscription แต่ห้านาทีสำหรับ API key และ cloud provider โดยค่าเริ่มต้น Claude Code v2.1.242 ขึ้นไปรองรับการตั้งค่า TTL แยกราย bucket ในการขอหนึ่งชั่วโมงสำหรับทั้งสอง bucket ด้วย environment variable ที่มีในเอกสาร ให้ตั้ง ENABLE_PROMPT_CACHING_1H=1 การตั้งค่ารายตัวหรือ environment variable อาจมีลำดับความสำคัญสูงกว่า ดังนั้นตรวจรายการ precedence ในคู่มือก่อนจะสันนิษฐานว่า TTL ไหนถูกใช้
สำหรับสรุปเซสชัน ให้รัน /usage บล็อก Session ของ Claude Code รายงานอัตรา cache hit และจำนวน miss ของบทสนทนาหลักหลัง response แรก สำหรับหลักฐานระดับคำขอ คู่มือระบุ cache_creation_input_tokens และ cache_read_input_tokens ไว้ ส่วน v2.1.251 ขึ้นไป ข้อมูล status-line เปิดเผยออบเจกต์ prompt_cache ตัวนับเหล่านี้มีประโยชน์กว่าการเดาว่า miss จากช่วงหยุดยาวเพียงอย่างเดียว
การแสดงผล Prompt cache (main) ของ Claude Code อาจรวมสาเหตุที่เป็นไปได้ไว้ด้วย แต่ transcript ของเซสชันเดียวไม่ใช่การวินิจฉัยที่ใช้ได้ทั่วไป ตัวอย่างเช่น issue ของ Anthropic Claude Code รายงานการ resume ของ background-subagent ที่วัดได้สองครั้งบน v2.1.273 ทั้งคู่ถูกวินิจฉัยเป็น messages_changed พร้อมการเขียนแคช 243,214 และ 398,622 โทเคน ให้ถือว่านั่นเป็นรายงานเฉพาะเวอร์ชันและเฉพาะสถานการณ์ ใช้ข้อมูล usage ของคุณเองและ release notes ปัจจุบันก่อนจะโยงการเปลี่ยนแปลงของบิลเข้ากับข้อบกพร่องทั่วไปของผลิตภัณฑ์
อะไรเปลี่ยนไปสำหรับ prompt caching บน Amazon Bedrock และ OpenRouter?
Bedrock prompt caching และ OpenRouter prompt caching เดินตามหลักการเดียวกัน — นำ prefix คงที่ที่เข้าเกณฑ์กลับมาใช้ซ้ำ — แต่พื้นผิว API และพฤติกรรมการ route เปลี่ยนไปตามผู้ให้บริการ
| Route | อะไรที่ต่างกัน | การตรวจสอบเชิงปฏิบัติ |
|---|---|---|
| Anthropic API | เพิ่ม automatic cache_control ระดับบนสุด หรือวาง breakpoint ระดับบล็อกแบบระบุชัด เอกสารปัจจุบันระบุ breakpoint ได้สูงสุดสี่จุดและความยาวโทเคนขั้นต่ำเฉพาะรายโมเดล |
อ่าน usage.cache_creation_input_tokens และ usage.cache_read_input_tokens ของ Anthropic |
| Amazon Bedrock | AWS มีเอกสารทั้ง implicit และ explicit prompt caching การรองรับ ค่าขั้นต่ำโทเคน TTL และฟิลด์ API ต่างกันไปตามโมเดล สำหรับ explicit caching ของ Claude AWS มี checkpoint เดียวแบบเรียบง่ายที่ท้ายเนื้อหาคงที่ และตรวจย้อนกลับราว 20 content block ไวยากรณ์ checkpoint และคำขอที่แน่นอนขึ้นกับ InvokeModel หรือ Converse |
ตรวจ model card ของ Bedrock สำหรับโมเดลและ region นั้น แล้วตรวจฟิลด์ usage ของ response จากผู้ให้บริการ อย่าคัดลอก payload ของ Anthropic API มาทั้งดุ้น |
| OpenRouter | คู่มือของ OpenRouter มีเอกสารทั้ง automatic caching ระดับบนสุดและ marker รายบล็อกแบบระบุชัด มันใช้ provider sticky routing หลังคำขอที่ถูกแคชเพื่อส่งการเรียกถัดไปยัง endpoint เดิมได้ ลำดับ provider แบบกำหนดเองมีสิทธิ์ก่อน Responses API ของมันเปิดเผย automatic caching ส่วนการควบคุมรายบล็อกสไตล์ Anthropic ไม่ถูกเปิดเผยที่นั่น | รักษาเซสชันหรือข้อความเปิดให้คงที่ และตรวจว่า provider ไหนเสิร์ฟแต่ละคำขอ การเปลี่ยน route ส่งผลต่อการนำกลับมาใช้ซ้ำได้ |
บน Bedrock คู่มือแพลตฟอร์มปัจจุบันของ Anthropic ระบุว่า integration Bedrock แบบ legacy สำหรับ Opus 4.6 และเก่ากว่าจะปฏิเสธฟิลด์ automatic ระดับบนสุด เส้นทางที่มีเอกสารรองรับที่นั่นคือ breakpoint แบบระบุชัด หน้าปัจจุบันของ AWS ระบุการรองรับ ค่าขั้นต่ำ และ TTL เฉพาะรายโมเดล ให้ทำตามหน้าของโมเดลที่คุณใช้จริง แทนที่จะยกกฎ integration เก่านั้นไปใช้กับทุกโมเดล Claude บน Bedrock
ถ้าคุณกำลังสร้างเลเยอร์ผู้ให้บริการ ให้แยก input ใหม่ การอ่านแคช และการเขียนแคช เป็นค่า usage คนละตัว เราสร้าง Octolib ที่ Muvon ตัว adapter ของ Anthropic ในนั้น map cache_read_input_tokens และฟิลด์ ephemeral write ของ API แยกกัน ยอดรวมระดับ gateway จึงไม่ซ่อนความแตกต่างนี้ บันทึกของเราเรื่อง การใช้งานโทเคน LLM และเลเยอร์ผู้ให้บริการแบบรวมศูนย์ อธิบายปัญหาเชิงบัญชีที่กว้างกว่า สำหรับ visibility ระดับ proxy ดู OctoHub LLM proxy สำหรับ tradeoff ต้นทุนของการ route โมเดล ดู คู่มือ LLM routing ของเรา
ตอนนี้คุณเปิดแคช ส่งคำขอสองครั้ง ยืนยันฟิลด์ read และเทียบจังหวะการนำกลับมาใช้ซ้ำที่วัดได้กับตารางราคาที่มีวันที่กำกับแล้วได้ ถ้าการตรวจสอบสี่ข้อนั้นไม่ตรงกัน ให้หยุด optimize บิลโดยประมาณ แล้วตรวจ prefix และเส้นทาง provider ก่อน
— Don
เราสร้าง Octolib ที่ Muvon และทำให้การอ่านแคชกับการเขียนแคชมองเห็นได้เป็นฟิลด์ usage แยกกัน ถ้าคุณเจอ response ของผู้ให้บริการที่ทำให้ตัวเลขเหล่านั้นกระทบยอดยาก เปิด issue ได้เลย
