คำนวณจุดคุ้มทุน Prompt Caching ของ Claude ให้คุ้มค่าที่สุด

ต้นทุนของ Prompt caching ก่อนที่จะประหยัดค่าใช้จ่ายได้

Prompt caching ช่วยให้ Claude สามารถนำส่วนหน้าของ prompt กลับมาใช้ใหม่ได้แทนที่จะต้องอ่านข้อมูลเดิมซ้ำในทุกการเรียกใช้งาน โดยการตัดสินใจทั้งหมดขึ้นอยู่กับตัวคูณ 2 ค่าที่นำไปคำนวณกับราคา input พื้นฐานของโมเดล ณ เดือนสิงหาคม 2026 การเขียนข้อมูลลง cache มีต้นทุนอยู่ที่ 1.25 เท่าของราคา input พื้นฐานสำหรับอายุการใช้งาน 5 นาที หรือ 2 เท่าสำหรับอายุการใช้งาน 1 ชั่วโมง ส่วนการอ่านข้อมูลจาก cache มีต้นทุนอยู่ที่ 0.1 เท่า ตัวคูณเหล่านี้คงที่ในทุกโมเดล ดังนั้นจุดคุ้มทุนที่ระบุด้านล่างจึงไม่เปลี่ยนแปลงแม้ราคาต่อ token จะปรับเปลี่ยนก็ตาม

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

จุดคุ้มทุนในสมการบรรทัดเดียว

ให้ B คือต้นทุนพื้นฐานของ input สำหรับ prefix หากส่งโดยไม่มีการแคช หากไม่มีการแคช N คำขอจะมีต้นทุนเท่ากับ N คูณ B สำหรับการแคช 5 นาที คำขอแรกจะเขียน prefix ที่ 1.25B และอีก N ลบ 1 คำขอที่เหลือจะอ่านที่ 0.1B เมื่อตั้งสมการให้เท่ากันจะได้ 0.9N = 1.15 ดังนั้น N = 1.28 คำขอที่สองจึงมีราคาถูกกว่าการไม่แคชเลย

ทำซ้ำเช่นเดิมด้วยการเขียน 2 เท่าของแคช 1 ชั่วโมง จะได้ 0.9N = 1.9 ดังนั้น N = 2.11 แคชระยะยาวต้องมีการอ่านสองครั้งจึงจะถึงจุดคุ้มทุน ซึ่งเป็นเหตุผลว่าทำไมจึงไม่ใช่ตัวเลือกเริ่มต้น

แผนภูมิด้านล่างแสดงราคาสำหรับ prefix ขนาด 20,000 token บน Claude Opus 5 ซึ่งมีอัตรา input พื้นฐานอยู่ที่ $5 ต่อล้าน token ณ เดือนสิงหาคม 2026 ให้ปรับสเกลตัวเลขทุกตัวด้วย 0.6 สำหรับโมเดลราคา $3 ต่อล้าน token รูปแบบของเส้นกราฟจะไม่เปลี่ยนแปลง

[
  {
    "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 หากไม่แคช และ $0.125 หากแคช ดังนั้นการแคช prompt ที่ใช้ครั้งเดียวจึงเป็นการขาดทุนโดยตรง เมื่อถึงคำขอที่สอง แคช 5 นาทีจะมีราคาอยู่ที่ $0.135 เทียบกับ $0.20 ในขณะที่แคช 1 ชั่วโมงยังคงมีราคาสูงกว่า ณ จุดนั้น คือ $0.21 เทียบกับ $0.20 และจะคุ้มทุนกว่าการไม่แคชก็ต่อเมื่อถึงคำขอที่สาม: $0.22 เทียบกับ $0.30 เมื่อถึง 20 คำขอ ส่วนต่างราคาจะอยู่ที่ $2.00 เทียบกับ $0.315

การเกิด cache hit จะเป็นการรีเฟรชรายการนั้นด้วย ซึ่งเป็นเหตุผลว่าทำไมตารางราคาที่เผยแพร่จึงเรียกคอลัมน์นั้นว่า cache hits and refreshes ดังนั้น endpoint ที่มีการใช้งานหนาแน่นจะคงรายการ 5 นาทีไว้ได้เรื่อยๆ ในราคาอ่าน และอายุการใช้งาน 1 ชั่วโมงจะคุ้มค่ากับการเขียน 2 เท่าก็ต่อเมื่อ traffic ของคุณมีช่วงว่างเว้นจริงๆ เท่านั้น

ต้นทุนที่เกิดจากอัตราการเข้าถึงแคชต่ำ

ทราฟฟิกจริงมักจะพลาดการเข้าถึงแคช คำขอที่พลาดแคชแต่ยังคงมี breakpoint อยู่จะถูกคิดค่าใช้จ่ายในฐานะการเขียน ดังนั้นวิธีที่ถูกต้องในการจำลองสถานการณ์นี้คือการคำนวณต้นทุนตามฟังก์ชันของอัตราการเข้าถึงแคช (hit rate) แผนภูมิด้านล่างแสดงข้อมูลสำหรับคำขอ 1,000 รายการ โดยแต่ละรายการมี prefix ขนาด 20,000 token เท่ากัน

[
  {
    "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"
  }
]

ที่อัตราการเข้าถึงแคช 0 เปอร์เซ็นต์ คุณจะต้องจ่าย $125.00 แทนที่จะเป็น $100.00 และแคชระยะเวลา 1 ชั่วโมงจะทำให้ค่าใช้จ่ายเพิ่มขึ้นเป็นสองเท่าอยู่ที่ $200.00 เมื่อแก้สมการ 1.25 ลบ 1.15h = 1 จะพบว่าแคชระยะเวลา 5 นาทีจะเริ่มประหยัดค่าใช้จ่ายได้ที่อัตราการเข้าถึงแคชประมาณ 22 เปอร์เซ็นต์ ซึ่งเป็นเหตุผลว่าทำไมที่ 25 เปอร์เซ็นต์จึงแสดงค่าเป็น $96.25 การคำนวณแบบเดียวกันสำหรับการเขียน 2 เท่าจะได้ผลลัพธ์ประมาณ 53 เปอร์เซ็นต์สำหรับแคชระยะเวลา 1 ชั่วโมง ดังนั้นที่อัตราการเข้าถึงแคช 50 เปอร์เซ็นต์จึงยังมีค่าใช้จ่ายอยู่ที่ $105.00 ซึ่งสูงกว่าเส้นราคาแบบไม่ใช้แคช ที่อัตรา 90 เปอร์เซ็นต์ ทั้งสองค่าจะอยู่ที่ $21.50 และ $29.00 และที่อัตรา 99 เปอร์เซ็นต์ แคชระยะสั้นจะลดค่าใช้จ่ายลงเหลือ $11.15 ซึ่งใกล้เคียงกับราคาต่ำสุดที่หนึ่งในสิบของราคาแบบไม่ใช้แคช

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

คำนำหน้าแบบใดที่คุ้มค่าต่อการทำ breakpoint

คำขอหนึ่งรายการสามารถมี cache breakpoint ได้สูงสุดสี่จุด คำถามจึงอยู่ที่ว่าบล็อกใดบ้างที่ควรได้รับ breakpoint ตัวเลือกที่เหมาะสมคือบล็อกที่มีข้อมูลเหมือนกันทุกประการในแต่ละการเรียกใช้งาน และมีขนาดใหญ่พอที่จะสร้างความแตกต่างได้ แผนภูมิด้านล่างแสดงราคาของรูปแบบทั่วไปสี่แบบจากการเรียกใช้งาน 1,000 ครั้ง โดยมีอัตรา hit rate อยู่ที่ 90 เปอร์เซ็นต์บน cache ระยะเวลา 5 นาที

[
  {
    "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 token เปล่าๆ ช่วยประหยัดค่าใช้จ่ายได้ $7.85 ต่อการเรียกใช้งาน 1,000 ครั้ง เมื่อเทียบกับราคา $10.00 หากไม่ใช้ cache นี่คือมูลค่าเงินจริงเมื่อใช้งานในปริมาณมาก แต่ไม่ใช่สิ่งที่ทำให้การทำ caching น่าสนใจ หากเพิ่มคำจำกัดความของเครื่องมือเข้าไป คุณจะอยู่ที่ 8,000 tokens และประหยัดไปได้ $31.40 เอกสารนโยบายขนาด 25,000 tokens ที่ทุกคำขอต้องสอบถามข้อมูล จะช่วยประหยัดได้ $98.12 แถวสุดท้ายคือสิ่งที่เปลี่ยนสถาปัตยกรรม: codebase หรือบริบทของ transcript ขนาด 120,000 tokens มีต้นทุน $600.00 หากไม่ใช้ cache และ $129.00 หากใช้ cache ซึ่งเป็นการประหยัดไปได้ถึง $471.00

การประหยัดจะแปรผันตามขนาดของคำนำหน้าและอัตรา hit rate เท่านั้น โดยไม่มีปัจจัยอื่น สิ่งนี้เปลี่ยนมุมมองว่าอะไรที่ควรใส่ไว้ใน prompt ตั้งแต่แรก: ต้นทุนที่แท้จริงของ Claude tokens หนึ่งล้าน tokens จะลดลงเหลือหนึ่งในสิบของราคาป้ายสำหรับทุกสิ่งที่คุณส่งมากกว่าหนึ่งครั้ง

ลักษณะค่าใช้จ่ายในใบแจ้งหนี้รายเดือน

แผนภูมิด้านล่างนี้ใช้จำนวน token ส่วนนำ 8,000 จากด้านบน รวมกับ system prompt และคำจำกัดความของเครื่องมือ โดยคิดอัตราการเรียกใช้ cache สำเร็จที่ 90 เปอร์เซ็นต์ และคำนวณสเกลตามปริมาณคำขอรายเดือน

[
  {
    "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 และที่ระดับหนึ่งล้านคำขอ ค่าใช้จ่ายสำหรับ input token แบบไม่ใช้ cache จะอยู่ที่ $40,000.00 โดยการใช้ caching จะช่วยลดค่าใช้จ่ายลงได้ $31,400.00 ตัวเลขเหล่านี้เป็นเพียงค่าใช้จ่ายของ input token เท่านั้น ส่วน output token จะถูกคิดราคาแยกต่างหากและ caching ไม่ส่งผลต่อค่าใช้จ่ายในส่วนนี้ ซึ่งเป็นสิ่งที่ควรคำนึงถึงก่อนที่คุณจะรับปากใครว่าจะสามารถลดค่าใช้จ่ายลงได้ถึง 90 เปอร์เซ็นต์ การใช้ caching ควรทำควบคู่ไปกับแนวทางปฏิบัติอื่นๆ ในการ ควบคุมค่าใช้จ่ายของ 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) ล่าสุดเท่านั้น ดังนั้นในการเรียกครั้งที่สองที่ทำงานปกติ ค่านี้จะมีขนาดเล็ก ซึ่งมักจะเป็นเพียงข้อความใหม่ของผู้ใช้เท่านั้น การเรียกทั้งสองครั้งมีค่าใช้จ่าย เนื่องจาก Claude API ไม่มีระดับการใช้งานฟรี แม้ว่าส่วนนำขนาด 20,000 โทเค็นที่กล่าวถึงข้างต้นจะมีค่าใช้จ่ายรวมกันประมาณสิบสี่เซนต์ก็ตาม

การตรวจสอบแบบเดียวกันจากเชลล์ โดยเทียบกับเนื้อหาคำขอที่คุณบันทึกไว้ใน 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) เมื่อคุณต้องการตัดสินใจเลือกจุดแบ่งที่แน่นอนด้วยตนเอง

กฎการเรียงลำดับที่ทำลายอัตราการเข้าถึงแคช

แคชจะจับคู่ข้อมูลแบบ byte-for-byte ตาม prefix ตั้งแต่เริ่มต้นคำขอ โดยคำขอจะถูกประกอบขึ้นตามลำดับที่กำหนดไว้ คือ tools ตามด้วย system และสุดท้ายคือ messages การเปลี่ยนแปลงในระดับใดก็ตามจะทำให้ระดับนั้นและทุกสิ่งที่ตามมาเป็นโมฆะ หากคุณแก้ไขคำอธิบายของ tool เพียงรายการเดียว ทั้ง system prompt และประวัติข้อความทั้งหมดจะถือว่าไม่ถูกต้องทันที แม้ว่าคุณจะไม่ได้แตะต้องส่วนเหล่านั้นเลยก็ตาม

นั่นนำไปสู่กฎข้อเดียวที่ไม่มีข้อยกเว้น: สิ่งใดก็ตามที่มีการเปลี่ยนแปลงระหว่างการเรียกใช้งาน จะต้องวางไว้หลังทุกสิ่งที่ไม่มีการเปลี่ยนแปลงเสมอ

สิ่งที่มักเป็นปัญหาคือ timestamp บรรทัดที่ระบุว่า Current time: 2026-08-03T14:07:11Z ไว้ที่ด้านบนสุดของ system prompt จะทำให้อัตราการเข้าถึงแคชเป็น 0 เปอร์เซ็นต์อย่างแน่นอน เพราะค่า hash ของ prefix จะแตกต่างกันในทุกการเรียกใช้งาน และไม่มีรายการก่อนหน้าใดสามารถจับคู่ได้ ให้ย้ายข้อมูลดังกล่าวไปไว้ใน user message ที่ส่วนท้ายแทน ตัวระบุ session หรือ nonce ประจำคำขอ (per-request nonce) ก็ทำให้เกิดปัญหาในลักษณะเดียวกันและมีวิธีแก้ไขแบบเดียวกัน เอกสารที่ดึงมาซึ่งแตกต่างกันในแต่ละคำขอควรวางไว้หลังบล็อกที่แคชไว้เช่นกัน มิฉะนั้นเอกสารเหล่านั้นจะผลักดัน token ที่คงที่ทั้งหมดไปอยู่หลังขอบเขตที่เปลี่ยนแปลงตลอดเวลา

ปัญหาที่สองคือการวางจุดพัก (breakpoint) ไว้บนบล็อกที่มีการเปลี่ยนแปลง การเขียนแคชจะเกิดขึ้นที่จุดพัก ดังนั้นหากบล็อกนั้นแตกต่างกันทุกครั้ง จะไม่มีข้อมูลที่คงที่ถูกจัดเก็บไว้เลย และการตรวจสอบย้อนหลังจะพบเพียงรายการที่คำขอก่อนหน้าเขียนไว้ที่จุดพักซึ่งเปลี่ยนแปลงไปตามคำขอของตนเอง ให้วาง cache_control ไว้ที่บล็อกสุดท้ายที่มีเนื้อหาเหมือนกันในทุกคำขอ

ปัญหาที่สามคือการเปลี่ยนแปลงพารามิเตอร์ที่คุณอาจไม่ได้มองว่าเป็นเนื้อหาของ prompt โมเดลที่ต่างกันจะมีแคชที่ต่างกัน การเปลี่ยนตัวเลือกของ tool จะทำให้ข้อมูลตั้งแต่ระดับ system เป็นต้นไปเป็นโมฆะ และการเพิ่มหรือลบ tool ออกก็จะทำให้ทุกอย่างเป็นโมฆะเช่นกัน

คำนำหน้าขั้นต่ำและการทำงานแบบเงียบ (no-op)

คำนำหน้าที่สั้นกว่าค่าขั้นต่ำของโมเดลจะไม่ถูกแคช และระบบจะไม่มีการแจ้งเตือนใดๆ ทั้งสิ้น ไม่มีการแสดงข้อผิดพลาดหรือคำเตือน คำขอจะทำงานสำเร็จและตัวนับทั้งสองค่าจะแสดงเป็น 0 ณ เดือนสิงหาคม 2026 ค่าขั้นต่ำที่ประกาศไว้มีดังนี้:

• 512 โทเค็นสำหรับ Claude Opus 5 และ Claude Fable 5
• 1,024 โทเค็นสำหรับ Claude Sonnet 5 และ Claude Opus 4.8
• 4,096 โทเค็นสำหรับ Claude Haiku 4.5

หากตัวนับทั้งสองแสดงค่าเป็น 0 ในคำขอที่คุณคาดว่าควรจะถูกแคช ให้ตรวจสอบความยาวของคำนำหน้าเป็นอันดับแรก นี่คือเหตุผลว่าทำไมโมเดลที่ราคาถูกที่สุดจึงไม่ใช่ตัวเลือกที่ประหยัดที่สุดโดยอัตโนมัติสำหรับภาระงานที่ต้องใช้การแคช เนื่องจาก Claude Haiku 4.5 ต้องการคำนำหน้าที่ยาวกว่า Claude Opus 5 ถึงแปดเท่าก่อนที่ระบบแคชจะเริ่มทำงาน ดังนั้น system prompt ขนาด 2,000 โทเค็นจึงถูกแคชในโมเดลหนึ่ง แต่ถูกละเลยไปอย่างเงียบๆ ในอีกโมเดลหนึ่ง

ตำแหน่งที่ Claude Code ทำการแคชข้อมูลให้คุณ และตำแหน่งที่ไม่สามารถทำได้

Claude Code จะทำการแคชส่วน prefix ของตัวเองเอาไว้ โดย system prompt และคำนิยามของเครื่องมือ (tool definitions) จะถูกวางไว้ที่ส่วนหน้าของทุกคำขอและไม่มีการเปลี่ยนแปลง ดังนั้นข้อมูลส่วนนี้จะถูกเขียนเพียงครั้งเดียวและอ่านซ้ำตลอดช่วงเวลาของเซสชัน นี่คือเหตุผลที่ค่าใช้จ่ายต่อรอบในเซสชันที่ยาวนานนั้นต่ำกว่าขนาดของบริบท (context size) ที่ปรากฏอยู่มาก และค่านี้จะแสดงอยู่ในตัวนับตามที่อธิบายไว้ใน วิธีที่ Claude Code รายงานการใช้งานโทเค็น

ส่วนที่ระบบไม่สามารถช่วยคุณได้คือการแก้ไขข้อมูลที่อยู่ใกล้กับส่วนต้นของบริบท ประวัติการสนทนาเป็นการเพิ่มข้อมูลต่อท้ายเท่านั้น (append-only) ดังนั้นการสนทนาใหม่ตามปกติจะเป็นการขยาย 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 ของ 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 มีความยาวเพียงพอ ให้ตรวจสอบเนื้อหาที่อาจเปลี่ยนแปลงระหว่างการเรียกใช้งานซึ่งวางอยู่ ณ หรือก่อนจุดตัด (breakpoint) เช่น การประทับเวลา (timestamp) หรือตัวระบุเซสชัน (session identifier) ใน system prompt หากตัวนับเคยทำงานได้ปกติแต่หยุดทำงาน แสดงว่าช่วงเวลาว่างระหว่างคำขอแต่ละครั้งยาวนานกว่าอายุของ cache

การทำ prompt caching ส่งผลต่อคำตอบของ Claude หรือไม่?

ไม่ส่งผล ระบบ cache จะจัดเก็บรูปแบบที่ประมวลผลแล้วของ tokens ที่คุณส่งไปก่อนหน้า และโมเดลจะเห็น prompt ในรูปแบบเดิมไม่ว่าจะใช้วิธีใดก็ตาม นี่เป็นฟีเจอร์สำหรับจัดการค่าใช้จ่ายและลด latency ไม่ใช่การเปลี่ยนแปลงพฤติกรรมของโมเดล ซึ่งหมายความว่าคุณสามารถเปิดใช้งานฟีเจอร์นี้กับ prompt ที่ทำงานได้ปกติอยู่แล้วโดยไม่จำเป็นต้องทำการประเมินผล (evaluation) ใหม่

ฉันควรจ่ายเงินเพื่อใช้ cache ระยะเวลา 1 ชั่วโมงหรือไม่?

ควรใช้เฉพาะในกรณีที่ traffic ของคุณมีช่วงว่างยาวนานกว่า 5 นาที และอัตราการเรียกใช้ cache (hit rate) ยังคงสูงกว่าประมาณ 53 เปอร์เซ็นต์ ค่าใช้จ่ายในการเขียน 2 เท่าถือเป็นความเสี่ยงที่สูงกว่าการเขียนแบบ 1.25 เท่าถึงสองเท่าหากเกิด cache miss สำหรับ cache ระยะเวลา 5 นาที ระบบจะรีเฟรชอายุการใช้งานทุกครั้งที่มีการเรียกใช้ (hit) ดังนั้นหากมี traffic ที่สม่ำเสมอ cache จะคงอยู่ได้ด้วยราคาการอ่านโดยไม่ต้องจ่ายค่าธรรมเนียมสำหรับอายุการใช้งานที่ยาวนานกว่า