โดย วิธีคำนวณจุดคุ้มทุน Claude Prompt Caching ให้คุ้มค่าที่สุด
วิเคราะห์ต้นทุน Claude Prompt Caching ด้วยตัวคูณเขียน 1.25 เท่าและอ่าน 0.1 เท่า เรียนรู้วิธีคำนวณจุดคุ้มทุนที่แท้จริงเพื่อให้การใช้งาน API ของคุณประหยัดค่าใช้จ่ายได้สูงสุด
ต้นทุนของ Prompt caching ก่อนที่จะเริ่มประหยัดค่าใช้จ่าย
Prompt caching ช่วยให้ Claude สามารถนำส่วนหน้าของ prompt กลับมาใช้ใหม่ได้แทนที่จะต้องอ่านข้อมูลเดิมซ้ำในทุกการเรียกใช้งาน โดยการตัดสินใจทั้งหมดขึ้นอยู่กับตัวคูณสองค่าเมื่อเทียบกับราคา input พื้นฐานของโมเดล ณ เดือนสิงหาคม 2026 การเขียนข้อมูลลง cache มีต้นทุนอยู่ที่ 1.25 เท่าของราคา input พื้นฐานสำหรับอายุการใช้งาน 5 นาที หรือ 2 เท่าสำหรับอายุการใช้งาน 1 ชั่วโมง ส่วนการอ่านข้อมูลจาก cache มีต้นทุนอยู่ที่ 0.1 เท่า ตัวคูณเหล่านี้คงที่ในทุกโมเดล ดังนั้นจุดคุ้มทุนที่ระบุด้านล่างจึงไม่เปลี่ยนแปลงแม้ราคาต่อ token จะปรับเปลี่ยนก็ตาม
การแลกเปลี่ยนนี้คือการจ่ายค่าธรรมเนียมเพิ่มในตอนนี้เพื่อแลกกับส่วนลดในภายหลัง คุณต้องจ่ายเพิ่มหนึ่งครั้งเพื่อจัดเก็บส่วนนำของ prompt จากนั้นทุกคำขอในภายหลังที่เริ่มต้นด้วยชุดข้อมูลเดียวกันทุกประการจะเสียค่าใช้จ่ายเพียงหนึ่งในสิบของราคา input ปกติสำหรับส่วนนั้น หากส่วนนำดังกล่าวไม่ถูกนำกลับมาใช้เลยภายในช่วงเวลาที่กำหนด คุณจะเสียค่าใช้จ่ายเพิ่มขึ้น 25 เปอร์เซ็นต์โดยไม่ได้รับประโยชน์ใดๆ
จุดคุ้มทุนในสมการบรรทัดเดียว
ให้ B คือต้นทุนพื้นฐานของ prefix หากส่งโดยไม่มีการทำ caching หากไม่ใช้ cache จำนวน N คำขอจะมีต้นทุนเท่ากับ N คูณ B แต่ถ้าใช้ cache 5 นาที คำขอแรกจะมีต้นทุนการเขียน prefix อยู่ที่ 1.25B และคำขอที่เหลืออีก N ลบ 1 ครั้งจะมีต้นทุนการอ่านอยู่ที่ 0.1B เมื่อตั้งสมการให้ทั้งสองฝั่งเท่ากันจะได้ 0.9N = 1.15 ดังนั้น N = 1.28 ซึ่งหมายความว่าคำขอที่สองก็มีราคาถูกกว่าการไม่ใช้ cache แล้ว
หากคำนวณซ้ำด้วยต้นทุนการเขียนที่เพิ่มขึ้น 2 เท่าของ cache 1 ชั่วโมง จะได้ 0.9N = 1.9 ดังนั้น N = 2.11 ซึ่ง cache ระยะยาวต้องมีการอ่านอย่างน้อยสองครั้งจึงจะถึงจุดคุ้มทุน นี่คือเหตุผลว่าทำไมมันจึงไม่ใช่ตัวเลือกเริ่มต้น
แผนภูมิด้านล่างแสดงราคาสำหรับ prefix ขนาด 20,000 token บน Claude Opus 5 ซึ่งมีอัตราค่าบริการพื้นฐานอยู่ที่ $5 ต่อล้าน token ณ เดือนสิงหาคม 2026 คุณสามารถปรับสเกลตัวเลขทุกค่าด้วย 0.6 สำหรับโมเดลที่มีราคา $3 ต่อล้าน token โดยที่รูปทรงของเส้นกราฟจะยังคงเดิม
The data behind this chart
[
{
"requests": 1,
"uncached_usd": "0.10",
"cached_5m_usd": "0.125",
"cached_1h_usd": "0.20"
},
{
"requests": 2,
"uncached_usd": "0.20",
"cached_5m_usd": "0.135",
"cached_1h_usd": "0.21"
},
{
"requests": 3,
"uncached_usd": "0.30",
"cached_5m_usd": "0.145",
"cached_1h_usd": "0.22"
},
{
"requests": 5,
"uncached_usd": "0.50",
"cached_5m_usd": "0.165",
"cached_1h_usd": "0.24"
},
{
"requests": 10,
"uncached_usd": "1.00",
"cached_5m_usd": "0.215",
"cached_1h_usd": "0.29"
},
{
"requests": 20,
"uncached_usd": "2.00",
"cached_5m_usd": "0.315",
"cached_1h_usd": "0.39"
}
]คำขอเพียงรายการเดียวจะมีต้นทุน $0.10 หากไม่ใช้ cache และ $0.125 หากใช้ cache ดังนั้นการทำ caching สำหรับ prompt ที่ใช้เพียงครั้งเดียวจึงเป็นการขาดทุนโดยเปล่าประโยชน์ เมื่อถึงคำขอที่สอง cache 5 นาทีจะมีต้นทุนอยู่ที่ $0.135 เทียบกับ $0.20 ในขณะที่ cache 1 ชั่วโมงยังคงมีราคาสูงกว่าอยู่ที่ $0.21 เมื่อเทียบกับ $0.20 เท่าเดิม และมันจะเริ่มคุ้มทุนกว่าการไม่ใช้ cache ก็ต่อเมื่อถึงคำขอที่สามเท่านั้น คือ $0.22 เทียบกับ $0.30 และเมื่อถึง 20 คำขอ ส่วนต่างของราคาจะอยู่ที่ $2.00 เทียบกับ $0.315
การเกิด cache hit จะเป็นการรีเฟรชรายการนั้นไปด้วย ซึ่งเป็นเหตุผลว่าทำไมตารางราคาที่เผยแพร่จึงเรียกคอลัมน์นั้นว่า cache hits and refreshes ดังนั้น endpoint ที่มีการใช้งานอย่างต่อเนื่องจะช่วยรักษาข้อมูลใน cache 5 นาทีให้คงอยู่ได้ตลอดไปในราคาการอ่าน ส่วน cache ที่มีอายุ 1 ชั่วโมงจะคุ้มค่ากับต้นทุนการเขียนที่สูงขึ้น 2 เท่าก็ต่อเมื่อ traffic ของคุณมีช่วงเว้นว่างที่ชัดเจนเท่านั้น
ต้นทุนที่เกิดจากอัตราการเข้าถึงแคชต่ำ
Traffic จริงมักจะเกิดการ miss คำขอที่พลาดจากแคชแต่ยังคงมี breakpoint ติดมาด้วยจะถูกคิดค่าใช้จ่ายในฐานะการเขียน (write) ดังนั้นวิธีที่ถูกต้องในการจำลองสถานการณ์นี้คือการคำนวณต้นทุนตามฟังก์ชันของอัตราการเข้าถึงแคช (hit rate) แผนภูมิด้านล่างแสดงการคำนวณสำหรับคำขอ 1,000 รายการ โดยแต่ละรายการมี prefix ขนาด 20,000 token เท่ากัน
The data behind this chart
[
{
"hit_rate_percent": 0,
"cost_5m_usd": "125.00",
"cost_1h_usd": "200.00",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 25,
"cost_5m_usd": "96.25",
"cost_1h_usd": "152.50",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 50,
"cost_5m_usd": "67.50",
"cost_1h_usd": "105.00",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 75,
"cost_5m_usd": "38.75",
"cost_1h_usd": "57.50",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 90,
"cost_5m_usd": "21.50",
"cost_1h_usd": "29.00",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 95,
"cost_5m_usd": "15.75",
"cost_1h_usd": "19.50",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 99,
"cost_5m_usd": "11.15",
"cost_1h_usd": "11.90",
"uncached_usd": "100.00"
}
]ที่อัตรา hit rate 0 เปอร์เซ็นต์ คุณจะต้องจ่าย $125.00 แทนที่จะเป็น $100.00 และแคชระยะเวลา 1 ชั่วโมงจะทำให้ค่าใช้จ่ายเพิ่มขึ้นเป็นสองเท่าที่ $200.00 เมื่อแก้สมการ 1.25 ลบ 1.15h เท่ากับ 1 จะพบว่าแคชระยะเวลา 5 นาทีจะเริ่มประหยัดค่าใช้จ่ายได้ที่อัตรา hit rate ประมาณ 22 เปอร์เซ็นต์ ซึ่งเป็นเหตุผลว่าทำไมที่ 25 เปอร์เซ็นต์จึงแสดงค่าเป็น $96.25 การคำนวณแบบเดียวกันสำหรับกรณีการเขียน 2 เท่า (2x write) จะได้ค่าประมาณ 53 เปอร์เซ็นต์สำหรับแคชระยะเวลา 1 ชั่วโมง ดังนั้นที่อัตรา hit rate 50 เปอร์เซ็นต์จึงยังมีค่าใช้จ่ายอยู่ที่ $105.00 ซึ่งสูงกว่าเส้นกรณีไม่ใช้แคช ที่อัตรา 90 เปอร์เซ็นต์ ทั้งสองกรณีจะอยู่ที่ $21.50 และ $29.00 ตามลำดับ และที่อัตรา 99 เปอร์เซ็นต์ แคชระยะสั้นจะลดค่าใช้จ่ายลงเหลือ $11.15 ซึ่งใกล้เคียงกับจุดต่ำสุดที่หนึ่งในสิบของราคาแบบไม่ใช้แคช
อัตรา hit rate คือตัวเลขที่คุณต้องวัดผล (instrument) เพราะเป็นปัจจัยเดียวที่คุณควบคุมได้หลังจากกำหนดขนาด prefix เรียบร้อยแล้ว
คำนำหน้าแบบใดที่คุ้มค่าต่อการตั้ง breakpoint
คำขอหนึ่งรายการสามารถรองรับ cache breakpoint ได้สูงสุดสี่จุด คำถามจึงอยู่ที่ว่าบล็อกข้อมูลใดควรได้รับสิทธิ์นี้ ผู้สมัครที่เหมาะสมคือบล็อกที่มีเนื้อหาเหมือนกันทุกไบต์ในแต่ละครั้งที่เรียกใช้งาน และมีขนาดใหญ่พอที่จะสร้างความแตกต่างได้ แผนภูมิด้านล่างแสดงราคาของรูปแบบทั่วไปสี่แบบจากการเรียกใช้งาน 1,000 ครั้ง โดยมีอัตรา hit rate อยู่ที่ 90 เปอร์เซ็นต์บน cache ระยะเวลา 5 นาที
The data behind this chart
[
{
"label": "System prompt",
"prefix_size_tokens": "2,000",
"uncached_usd": "10.00",
"cached_usd": "2.15",
"saved_usd": "7.85"
},
{
"label": "System plus tools",
"prefix_size_tokens": "8,000",
"uncached_usd": "40.00",
"cached_usd": "8.60",
"saved_usd": "31.40"
},
{
"label": "Policy document",
"prefix_size_tokens": "25,000",
"uncached_usd": "125.00",
"cached_usd": "26.88",
"saved_usd": "98.12"
},
{
"label": "Codebase context",
"prefix_size_tokens": "120,000",
"uncached_usd": "600.00",
"cached_usd": "129.00",
"saved_usd": "471.00"
}
]ระบบ prompt ที่ใช้โทเค็นเปล่าๆ ขนาด 2,000 ช่วยประหยัดค่าใช้จ่ายได้ $7.85 ต่อการเรียกใช้งาน 1,000 ครั้ง เมื่อเทียบกับราคา $10.00 กรณีไม่ใช้ cache นี่คือเงินจริงเมื่อใช้งานในปริมาณมาก แต่ไม่ใช่สิ่งที่ทำให้การทำ caching น่าสนใจ หากเพิ่มคำจำกัดความของเครื่องมือเข้าไป คุณจะใช้โทเค็นขนาด 8,000 และประหยัดได้ $31.40 เอกสารนโยบายขนาด 25,000 โทเค็นที่ทุกคำขอต้องอ้างอิงถึงจะช่วยประหยัดได้ $98.12 แถวสุดท้ายคือสิ่งที่เปลี่ยนสถาปัตยกรรม: โค้ดเบสหรือบริบทของบทสนทนาขนาด 120,000 โทเค็น มีค่าใช้จ่าย $600.00 หากไม่ใช้ cache และ $129.00 หากใช้ cache ซึ่งประหยัดไปได้ถึง $471.00
การประหยัดจะแปรผันตามขนาดของคำนำหน้าและอัตรา hit rate เท่านั้น สิ่งนี้เปลี่ยนมุมมองว่าอะไรที่ควรใส่ไว้ใน prompt บ้าง: ราคาที่แท้จริงของ Claude หนึ่งล้านโทเค็น จะลดลงเหลือเพียงหนึ่งในสิบของราคาหน้าป้ายสำหรับทุกสิ่งที่คุณส่งมากกว่าหนึ่งครั้ง
ลักษณะค่าใช้จ่ายในใบแจ้งหนี้รายเดือน
แผนภูมิด้านล่างนี้ใช้ token prefix ขนาด 8,000 จากด้านบน ร่วมกับ system prompt และคำนิยามของเครื่องมือ โดยคำนวณที่อัตราการเรียกใช้แคชสำเร็จ (hit rate) 90 เปอร์เซ็นต์ และขยายผลไปยังปริมาณคำขอรายเดือน
The data behind this chart
[
{
"label": "10k requests",
"uncached_usd": "400.00",
"cached_usd": "86.00",
"saved_usd": "314.00"
},
{
"label": "100k requests",
"uncached_usd": "4,000.00",
"cached_usd": "860.00",
"saved_usd": "3,140.00"
},
{
"label": "1M requests",
"uncached_usd": "40,000.00",
"cached_usd": "8,600.00",
"saved_usd": "31,400.00"
}
]ที่ปริมาณ 10,000 คำต่อเดือน เงินที่ประหยัดได้คือ $314.00 ซึ่งเป็นส่วนต่างระหว่าง $400.00 และ $86.00 ที่ปริมาณ 100,000 คำขอ ยอดประหยัดจะอยู่ที่ $3,140.00 และที่ปริมาณ 1 ล้านคำขอ ค่าใช้จ่ายสำหรับ input แบบไม่ใช้แคชจะอยู่ที่ $40,000.00 โดยการใช้แคชจะช่วยลดค่าใช้จ่ายไปได้ $31,400.00 ตัวเลขเหล่านี้เป็นเพียงค่าใช้จ่ายสำหรับ input token เท่านั้น ส่วน output จะมีการคิดราคาแยกต่างหากและไม่ได้รับผลประโยชน์จากการทำแคช ซึ่งควรคำนึงถึงก่อนที่จะรับปากใครว่าจะลดค่าใช้จ่ายได้ถึง 90 เปอร์เซ็นต์ การทำแคชเป็นเพียงส่วนหนึ่งของแนวทางปฏิบัติทั่วไปในการ ควบคุมค่าใช้จ่ายของ AI agent บน VPS
วิธีพิสูจน์ว่าแคชทำงานอยู่
อย่าเพิ่งเชื่อการออกแบบเพียงอย่างเดียว ให้ตรวจสอบบล็อกการใช้งาน (usage block) ในการตอบกลับ ทุกการตอบกลับจาก Messages API จะรายงานจำนวนโทเค็นที่เขียนลงแคช, จำนวนโทเค็นที่อ่านจากแคช และจำนวนโทเค็นใหม่ที่ต้องประมวลผล
from anthropic import Anthropic
client = Anthropic()
resp = client.messages.create(
model="claude-opus-5",
max_tokens=512,
system=[
{
"type": "text",
"text": POLICY_DOCUMENT,
"cache_control": {"type": "ephemeral"},
}
],
messages=[{"role": "user", "content": question}],
)
u = resp.usage
print("write:", u.cache_creation_input_tokens)
print("read: ", u.cache_read_input_tokens)
print("fresh:", u.input_tokens)ให้รันคำสั่งเดิมสองครั้งด้วยเอกสารชุดเดียวกันแต่เปลี่ยนคำถาม การเรียกใช้งานครั้งแรกจะรายงานค่า cache_creation_input_tokens ที่ไม่ใช่ศูนย์ และค่า cache_read_input_tokens ที่เป็นศูนย์ ส่วนการเรียกใช้งานครั้งที่สองจะให้ผลลัพธ์ตรงกันข้าม เนื่องจากพบส่วนนำ (prefix) แล้ว ค่า input_tokens จะนับเฉพาะโทเค็นที่อยู่หลังจุดพัก (breakpoint) ล่าสุด ดังนั้นในการเรียกใช้งานครั้งที่สองที่ทำงานปกติ ค่านี้จะมีขนาดเล็ก ซึ่งมักจะเป็นเพียงข้อความใหม่ของผู้ใช้เท่านั้น
การตรวจสอบแบบเดียวกันจากเชลล์ โดยใช้เนื้อหาคำขอที่คุณบันทึกไว้ใน request.json:
curl -s https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d @request.json | jq '.usage'การเรียกใช้งานครั้งที่สองที่ทำงานปกติจะแสดงผลลัพธ์ในลักษณะนี้:
{
"input_tokens": 42,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 20143,
"output_tokens": 187
}บรรทัดหนึ่งจะแสดงความจริงให้คุณเห็น หากค่า cache_read_input_tokens ยังคงเป็น 0 ในทุกการเรียกใช้งาน แสดงว่าคุณกำลังจ่ายค่าธรรมเนียมการเขียนเพิ่มขึ้น 1.25 เท่าในทุกครั้งโดยไม่ได้รับผลประโยชน์ใดๆ กลับมา
สำหรับอายุการใช้งาน 1 ชั่วโมง จุดพักจะมาพร้อมกับระยะเวลาคงอยู่ (TTL):
{
"type": "text",
"text": "your stable prefix",
"cache_control": {"type": "ephemeral", "ttl": "1h"}
}นอกจากนี้ยังมีระบบแคชอัตโนมัติ โดยใช้ฟิลด์ cache_control เพียงฟิลด์เดียวที่ระดับบนสุดของคำขอ หลังจากนั้น API จะจัดการจุดพักให้เองเมื่อบทสนทนาขยายตัวขึ้น ซึ่งจะใช้ช่องจุดพักของคุณไปหนึ่งช่องจากทั้งหมดสี่ช่อง ให้เริ่มต้นด้วยวิธีนี้ก่อน แล้วค่อยเปลี่ยนไปใช้จุดพักแบบระบุตำแหน่งเอง (explicit breakpoints) เมื่อคุณต้องการกำหนดขอบเขตที่แน่นอนด้วยตนเอง
กฎการจัดลำดับที่ทำลายอัตราการเข้าถึงแคช (hit rate)
แคชจะจับคู่ prefix แบบ byte-ต่อ-byte ตั้งแต่เริ่มต้นคำขอ โดยคำขอจะถูกประกอบขึ้นตามลำดับที่กำหนดไว้ตายตัว ได้แก่ tools, ตามด้วย system, และปิดท้ายด้วย messages การเปลี่ยนแปลงในระดับใดก็ตามจะทำให้ระดับนั้นและทุกสิ่งที่ตามมาเป็นโมฆะ หากคุณแก้ไขคำอธิบายของ tool เพียงรายการเดียว ทั้ง system prompt และประวัติข้อความทั้งหมดจะถือว่าไม่ถูกต้องทันที แม้ว่าคุณจะไม่ได้แตะต้องส่วนเหล่านั้นเลยก็ตาม
กฎข้อนี้จึงไม่มีข้อยกเว้น: สิ่งใดก็ตามที่มีการเปลี่ยนแปลงระหว่างการเรียกใช้งาน จะต้องวางไว้หลังสิ่งที่ไม่มีการเปลี่ยนแปลงเสมอ
สิ่งที่มักเป็นต้นเหตุคือ timestamp บรรทัดที่ระบุ Current time: 2026-08-03T14:07:11Z ไว้ที่ส่วนบนสุดของ system prompt จะทำให้อัตราการเข้าถึงแคชเป็น 0 เปอร์เซ็นต์อย่างแน่นอน เพราะค่า hash ของ prefix จะแตกต่างกันในทุกการเรียกใช้งาน และไม่มีรายการก่อนหน้าใดที่สามารถจับคู่ได้ ให้ย้ายข้อมูลดังกล่าวไปไว้ใน user message ที่ส่วนท้ายแทน ตัวระบุเซสชัน (session identifier) หรือ nonce ในแต่ละคำขอ ก็ส่งผลเสียในลักษณะเดียวกันและมีวิธีแก้ไขแบบเดียวกัน เอกสารที่ดึงมาซึ่งแตกต่างกันในแต่ละคำขอควรวางไว้หลังบล็อกที่แคชไว้เช่นกัน มิฉะนั้นเอกสารเหล่านั้นจะผลักดัน token ที่คงที่ทั้งหมดไปอยู่หลังขอบเขตที่เปลี่ยนแปลงตลอดเวลา
ต้นเหตุที่สองคือการวางจุดพัก (breakpoint) ไว้บนบล็อกที่มีการเปลี่ยนแปลง การเขียนแคชจะเกิดขึ้นที่จุดพัก ดังนั้นหากบล็อกนั้นแตกต่างกันทุกครั้ง จะไม่มีข้อมูลที่คงที่ถูกจัดเก็บไว้เลย และการตรวจสอบย้อนหลังจะพบเพียงรายการที่คำขอก่อนหน้าเขียนไว้ที่จุดพักซึ่งเปลี่ยนแปลงไปเรื่อยๆ ของตนเองเท่านั้น ให้วาง cache_control ไว้ที่บล็อกสุดท้ายที่มีเนื้อหาเหมือนกันในทุกคำขอ
ต้นเหตุที่สามคือการเปลี่ยนแปลงพารามิเตอร์ที่คุณอาจไม่ได้มองว่าเป็นเนื้อหาของ prompt โมเดลที่ต่างกันจะมีแคชที่ต่างกัน การเปลี่ยนตัวเลือกของ tool จะทำให้ข้อมูลตั้งแต่ระดับ system เป็นต้นไปเป็นโมฆะ การเพิ่มหรือลบ tool ออกจะทำให้ทุกอย่างเป็นโมฆะทั้งหมด
คำนำหน้าขั้นต่ำและการทำงานแบบเงียบ (no-op)
คำนำหน้าที่สั้นกว่าค่าขั้นต่ำของโมเดลจะไม่ถูกแคช และระบบจะไม่มีการแจ้งเตือนใดๆ ทั้งสิ้น ไม่มีการแสดงข้อผิดพลาดหรือคำเตือน คำขอจะดำเนินการสำเร็จและตัวนับทั้งสองค่าจะแสดงเป็น 0 ณ เดือนสิงหาคม 2026 ค่าขั้นต่ำที่ประกาศไว้มีดังนี้:
- 512 tokens สำหรับ Claude Opus 5 และ Claude Fable 5
- 1,024 tokens สำหรับ Claude Sonnet 5 และ Claude Opus 4.8
- 4,096 tokens สำหรับ Claude Haiku 4.5
หากตัวนับทั้งสองค่าแสดงเป็น 0 ในคำขอที่คุณคาดว่าควรจะถูกแคช ให้ตรวจสอบความยาวของคำนำหน้าเป็นอันดับแรก นี่คือเหตุผลว่าทำไมโมเดลที่ราคาถูกที่สุดจึงไม่ได้เป็นตัวเลือกที่ประหยัดที่สุดเสมอไปสำหรับงานที่ต้องใช้การแคช เนื่องจาก Claude Haiku 4.5 ต้องการคำนำหน้าที่ยาวกว่า Claude Opus 5 ถึงแปดเท่าก่อนที่ระบบแคชจะเริ่มทำงาน ดังนั้น system prompt ขนาด 2,000 tokens จึงถูกแคชในโมเดลหนึ่ง แต่ถูกเพิกเฉยอย่างเงียบๆ ในอีกโมเดลหนึ่ง
ตำแหน่งที่ Claude Code ทำการแคชข้อมูลและข้อจำกัด
Claude Code จะทำการแคชส่วน prefix ของตนเอง โดย system prompt และคำนิยามของเครื่องมือ (tool definitions) จะถูกวางไว้ที่ส่วนต้นของทุกคำขอและไม่มีการเปลี่ยนแปลง ดังนั้นข้อมูลส่วนนี้จะถูกเขียนเพียงครั้งเดียวและอ่านซ้ำตลอดทั้งเซสชัน นี่คือเหตุผลที่ค่าใช้จ่ายต่อรอบ (per-turn) ของเซสชันที่ยาวนานนั้นต่ำกว่าขนาดของบริบท (context size) มาก และจะปรากฏในตัวนับที่อธิบายไว้ใน วิธีที่ Claude Code รายงานการใช้โทเค็น
ส่วนที่ระบบไม่สามารถช่วยลดค่าใช้จ่ายได้คือการแก้ไขข้อมูลที่อยู่ใกล้กับส่วนต้นของบริบท ประวัติการสนทนาเป็นการเพิ่มข้อมูลต่อท้ายเท่านั้น ดังนั้นรอบการสนทนาใหม่ตามปกติจะเป็นการขยาย prefix ที่ถูกแคชไว้แล้ว การแก้ไขไฟล์ที่ถูกอ่านในช่วงต้นของเซสชันจะทำให้เนื้อหาตรงกลางของ prefix นั้นเปลี่ยนไป และโทเค็นทุกตัวที่อยู่หลังจุดที่มีการเปลี่ยนแปลงจะต้องถูกเขียนใหม่ทั้งหมด การทิ้งช่วงว่างไว้นานเกินไปก็ส่งผลเช่นเดียวกัน เนื่องจากรายการที่แคชไว้จะหมดอายุและรอบถัดไปจะต้องเสียค่าใช้จ่ายในการเขียนใหม่ทั้งหมด ทั้งสองกรณีนี้ไม่ใช่ข้อผิดพลาดของโปรแกรม แต่เป็นไปตามกฎของ prefix ที่ทำงานตามที่ระบุไว้ทุกประการ
หากคุณกำลังเขียนไคลเอนต์ของคุณเอง ให้ใช้รูปแบบโครงสร้างตั้งแต่คำขอแรกแทนการปรับแก้ในภายหลัง โดยสร้างการเรียกใช้งานในลักษณะเดียวกับ แอป Claude API แรกบน VPS คือวางบล็อกข้อมูลที่คงที่ไว้ส่วนหน้า และวางบล็อกข้อมูลที่มีการเปลี่ยนแปลงไว้ส่วนท้ายสุด
รูปแบบความล้มเหลวและสิ่งที่คุณจะพบ
ทุกการเรียกคือการเขียน (Write) cache_creation_input_tokens ไม่เป็นศูนย์ในทุกคำขอ ในขณะที่ cache_read_input_tokens ยังคงเป็น 0 แสดงว่ามีบางอย่างที่จุดพัก (breakpoint) หรือก่อนหน้านั้นเปลี่ยนแปลงไประหว่างการเรียกแต่ละครั้ง ให้พิมพ์อักขระ 200 ตัวแรกของ prefix ที่คุณประกอบขึ้นมาในสองคำขอที่ต่อเนื่องกัน แล้วเปรียบเทียบด้วยสายตา
ตัวนับทั้งสองเป็น 0 prefix มีขนาดต่ำกว่าค่าขั้นต่ำของโมเดล หรือฟิลด์ cache_control ไม่เคยไปถึง API ให้เริ่มจากการนับโทเค็นของ prefix ก่อน จากนั้นจึงบันทึก log ของเนื้อหาคำขอ (request body) ที่คุณส่งไปจริง
การอ่าน (Read) ทำงานได้แล้วหยุดไป เกิดการ hit ต่อเนื่องกัน ตามด้วยการเขียน แล้วจึงกลับมา hit อีกครั้ง ช่วงเวลาว่างระหว่างคำขอนานกว่าอายุของข้อมูล (lifetime) ให้ยอมรับการเขียนนั้น หรือเปลี่ยนไปใช้ TTL 1 ชั่วโมงเมื่อคุณตรวจสอบแล้วว่าอัตราการ hit ของคุณสูงกว่า 53 เปอร์เซ็นต์
อัตราการ hit ลดลงหลังจากการ deploy มีการแก้ไขคำอธิบายเครื่องมือหรือมีการเปลี่ยนโมเดล ซึ่งทั้งสองกรณีจะทำให้ prefix ทั้งหมดไม่ถูกต้อง (invalidate) ให้คาดการณ์ว่าจะมีรอบการเขียนที่สิ้นเปลืองทรัพยากรหนึ่งรอบหลังจากการ deploy ทุกครั้งที่มีการแก้ไข prompt
ค่าใช้จ่ายเพิ่มขึ้นหลังจากที่คุณเปิดใช้งานการแคช (Caching) อัตราการ hit ของคุณต่ำกว่าจุดคุ้มทุน หากต่ำกว่าประมาณ 22 เปอร์เซ็นต์สำหรับการแคช 5 นาที การส่ง prefix โดยไม่แคชจะมีราคาถูกกว่า และหากต่ำกว่าประมาณ 53 เปอร์เซ็นต์ กรณีเดียวกันนี้ก็เป็นจริงสำหรับการแคช 1 ชั่วโมง
FAQ
ต้องใช้ prompt ซ้ำกี่ครั้งจึงจะคุ้มค่ากับการทำ caching?
เพียงครั้งเดียวสำหรับ cache ระยะเวลา 5 นาที การเขียนข้อมูลมีต้นทุน 1.25 เท่าของ input ปกติ และการอ่านมีต้นทุน 0.1 เท่า ดังนั้นคำขอที่ไม่มี cache จำนวน N ครั้งจะมีต้นทุนเท่ากับ N ในขณะที่คำขอที่มี cache จำนวน N ครั้งจะมีต้นทุนเท่ากับ 1.25 บวกด้วย 0.1 คูณกับ N ลบ 1 จุดคุ้มทุนอยู่ที่ N = 1.28 ดังนั้นคำขอที่สองจึงเริ่มคุ้มทุนแล้ว สำหรับ cache ระยะเวลา 1 ชั่วโมง การเขียนข้อมูลมีต้นทุน 2 เท่าและจุดคุ้มทุนอยู่ที่ N = 2.11 ซึ่งหมายความว่าต้องมีการอ่านซ้ำสองครั้ง
ทำไม cache_read_input_tokens ถึงเป็นศูนย์เสมอ?
ให้ตรวจสอบความยาวของ prefix ก่อน หากต่ำกว่าค่าขั้นต่ำของโมเดล ซึ่ง ณ เดือนสิงหาคม 2026 คือ 512 tokens สำหรับ Claude Opus 5 และ 4,096 tokens สำหรับ Claude Haiku 4.5 ระบบจะข้ามการทำ caching ไปโดยเงียบๆ และตัวนับทั้งสองจะแสดงค่าเป็น 0 หาก prefix ยาวเพียงพอ ให้ตรวจสอบว่ามีเนื้อหาที่เปลี่ยนแปลงระหว่างการเรียกใช้งานซึ่งวางอยู่ ณ ตำแหน่งหรือก่อนจุดตัดหรือไม่ เช่น timestamp หรือ session identifier ใน system prompt หากตัวนับเคยทำงานปกติแต่หยุดไป แสดงว่าช่วงเวลาว่างระหว่างคำขอแต่ละครั้งนานเกินกว่าอายุของ cache
การทำ prompt caching ส่งผลต่อคำตอบของ Claude หรือไม่?
ไม่ส่งผล ระบบ cache จะจัดเก็บรูปแบบที่ประมวลผลแล้วของ tokens ที่คุณส่งไปก่อนหน้า และโมเดลจะเห็น prompt ชุดเดิมไม่ว่าจะใช้วิธีใดก็ตาม นี่เป็นฟีเจอร์สำหรับจัดการเรื่องค่าใช้จ่ายและ latency ไม่ใช่การเปลี่ยนแปลงพฤติกรรมของโมเดล ซึ่งหมายความว่าคุณสามารถเปิดใช้งานฟีเจอร์นี้กับ prompt ที่ทำงานได้ดีอยู่แล้วโดยไม่จำเป็นต้องรันการประเมินผลใหม่
ฉันควรจ่ายเงินเพื่อใช้ cache ระยะเวลา 1 ชั่วโมงหรือไม่?
ควรใช้เฉพาะเมื่อ traffic ของคุณมีช่วงว่างนานกว่า 5 นาที และอัตรา hit rate ของคุณยังคงสูงกว่าประมาณ 53 เปอร์เซ็นต์ การเขียนข้อมูลที่ต้นทุน 2 เท่าถือเป็นความเสี่ยงที่สูงกว่าการเขียนที่ 1.25 เท่าถึงสองเท่าเมื่อเกิด cache miss สำหรับ cache ระยะเวลา 5 นาที ระบบจะรีเฟรชอายุทุกครั้งที่เกิด hit ดังนั้นหากมี traffic เข้ามาอย่างสม่ำเสมอ cache จะยังคงอยู่ได้โดยจ่ายเพียงราคาค่าอ่าน โดยไม่จำเป็นต้องจ่ายค่าธรรมเนียมสำหรับอายุ cache ที่นานกว่า