การแคชพรอมต์

การแคชพรอมต์ช่วยให้ผู้ให้บริการโมเดลนำคำนำหน้าพรอมต์ที่ไม่เปลี่ยนแปลง (คำสั่งระดับระบบ/นักพัฒนา นิยามเครื่องมือ และบริบทคงที่อื่นๆ) กลับมาใช้ข้ามเทิร์นได้ แทนที่จะประมวลผลใหม่ทุกคำขอ ซึ่งช่วยลดค่าใช้จ่ายด้านโทเค็นและเวลาแฝงสำหรับเซสชันที่ทำงานเป็นเวลานานและมีบริบทซ้ำกัน

OpenClaw ปรับการใช้งานจากผู้ให้บริการให้อยู่ในรูปแบบ cacheRead และ cacheWrite ทุกแห่งที่ API ต้นทางเปิดเผยตัวนับเหล่านั้น ข้อมูลสรุปการใช้งาน (/status และรายการที่คล้ายกัน) จะใช้รายการการใช้งานล่าสุดในทรานสคริปต์เป็นค่าทดแทนเมื่อสแนปชอตเซสชันสดไม่มีตัวนับแคช โดยค่าจากข้อมูลสดที่ไม่เป็นศูนย์จะมีลำดับความสำคัญเหนือค่าทดแทนเสมอ

เอกสารอ้างอิงของผู้ให้บริการ:

• การแคชพรอมต์ของ Anthropic
• การแคชพรอมต์ของ OpenAI

ตัวควบคุมหลัก

cacheRetention

ค่า: "none" | "short" | "long" กำหนดค่าได้ทั้งเป็นค่าเริ่มต้นส่วนกลาง แยกตามโมเดล และแยกตามเอเจนต์ "standard" ไม่ใช่นามแฝง ให้ใช้ "short" สำหรับช่วงเวลาการแคชเริ่มต้นของผู้ให้บริการ ค่าที่ไม่ถูกต้องจะถูกละเว้นพร้อมคำเตือน

agents:  defaults:    params:      cacheRetention: "long" # none | short | long    models:      "anthropic/claude-opus-4-6":        params:          cacheRetention: "short" # overrides the global default for this model  list:    - id: "alerts"      params:        cacheRetention: "none" # overrides both defaults for this agent

ลำดับการผสาน (ค่าที่มาทีหลังมีผล):

1. agents.defaults.params - ค่าเริ่มต้นส่วนกลางสำหรับทุกโมเดล
2. agents.defaults.models["provider/model"].params - ค่าแทนที่แยกตามโมเดล
3. agents.list[].params - ค่าแทนที่แยกตามเอเจนต์ โดยจับคู่ตามรหัสเอเจนต์

แหล่งที่มา: src/agents/embedded-agent-runner/extra-params.ts (resolveExtraParams)

contextPruning.mode: "cache-ttl"

ตัดบริบทผลลัพธ์จากเครื่องมือที่เก่าออกหลังจากพ้นช่วง TTL ของแคช เพื่อไม่ให้คำขอหลังจากไม่มีการใช้งานต้องแคชประวัติขนาดใหญ่เกินไปซ้ำอีก

agents:  defaults:    contextPruning:      mode: "cache-ttl"      ttl: "1h"

ดูพฤติกรรมทั้งหมดได้ที่ การตัดเซสชัน

การรักษาแคชให้อุ่นด้วย Heartbeat

Heartbeat สามารถรักษาช่วงเวลาของแคชให้อุ่นอยู่เสมอ และลดการเขียนแคชซ้ำหลังจากเว้นช่วงโดยไม่มีการใช้งาน กำหนดค่าได้ทั้งแบบส่วนกลาง (agents.defaults.heartbeat) หรือแยกตามเอเจนต์ (agents.list[].heartbeat)

agents:  defaults:    heartbeat:      every: "55m"

พฤติกรรมของผู้ให้บริการ

Anthropic (API โดยตรงและ Vertex AI)

• รองรับ cacheRetention สำหรับผู้ให้บริการ anthropic และ anthropic-vertex รวมถึงโมเดล Claude บน amazon-bedrock และปลายทางแบบกำหนดเองที่เข้ากันได้กับ anthropic-messages เมื่อกำหนด cacheRetention ไว้อย่างชัดเจน
• เมื่อไม่ได้กำหนดค่า OpenClaw จะตั้งค่าเริ่มต้น cacheRetention: "short" สำหรับ Anthropic โดยตรง (เฉพาะผู้ให้บริการ anthropic และ anthropic-vertex เท่านั้น เส้นทางอื่นในตระกูล Anthropic ต้องระบุค่าอย่างชัดเจน)
• การตอบกลับแบบ Anthropic Messages ดั้งเดิมเปิดเผย cache_read_input_tokens และ cache_creation_input_tokens ซึ่งแมปไปยัง cacheRead และ cacheWrite
• cacheRetention: "short" แมปไปยังแคชชั่วคราวเริ่มต้น 5 นาที ส่วน cacheRetention: "long" จะขอ TTL 1 ชั่วโมง (cache_control: { type: "ephemeral", ttl: "1h" }) เมื่อกำหนดไว้อย่างชัดเจน การเก็บรักษาระยะยาวแบบโดยนัย/ขับเคลื่อนด้วยสภาพแวดล้อม (OPENCLAW_CACHE_RETENTION=long โดยไม่มี cacheRetention ที่กำหนดไว้อย่างชัดเจน) จะอัปเกรดเป็น TTL 1 ชั่วโมงเฉพาะบนโฮสต์ api.anthropic.com หรือ Vertex AI (aiplatform.googleapis.com / *-aiplatform.googleapis.com) เท่านั้น ส่วนโฮสต์อื่นจะใช้แคช 5 นาทีต่อไป

แหล่งที่มา: packages/ai/src/transports/anthropic-payload-policy.ts (resolveAnthropicEphemeralCacheControl, isLongTtlEligibleEndpoint)

OpenAI (API โดยตรง)

• การแคชพรอมต์ทำงานโดยอัตโนมัติบนโมเดลรุ่นใหม่ที่รองรับ โดย OpenClaw จะไม่แทรกเครื่องหมายแคชระดับบล็อก
• OpenClaw ส่ง prompt_cache_key เพื่อให้การกำหนดเส้นทางแคชคงที่ข้ามเทิร์น โฮสต์ api.openai.com โดยตรงจะได้รับค่านี้โดยอัตโนมัติ พร็อกซีที่เข้ากันได้กับ OpenAI (oMLX, llama.cpp และปลายทางแบบกำหนดเอง) ต้องมี compat.supportsPromptCacheKey: true ในการกำหนดค่าโมเดลเพื่อเลือกใช้ โดยระบบจะไม่ตรวจพบสิ่งนี้โดยอัตโนมัติสำหรับพร็อกซี
• prompt_cache_retention: "24h" จะถูกเพิ่มเฉพาะเมื่อเลือก cacheRetention: "long" และปลายทางที่แก้ไขแล้วรองรับทั้งคีย์แคชและการเก็บรักษาระยะยาว (compat.supportsLongCacheRetention ซึ่งเป็นจริงโดยค่าเริ่มต้น ส่วนโปรไฟล์ความเข้ากันได้ของ Together AI และ Cloudflare จะปิดใช้งาน) cacheRetention: "none" จะระงับทั้งสองฟิลด์
• แคชฮิตจะแสดงผ่าน usage.prompt_tokens_details.cached_tokens (Chat Completions) หรือ input_tokens_details.cached_tokens (Responses API) ซึ่งแมปไปยัง cacheRead
• เพย์โหลดของ Responses API ยังอาจเปิดเผย input_tokens_details.cache_write_tokens ซึ่งแมปไปยัง cacheWrite และคิดราคาตามอัตราการเขียนแคชของโมเดล เพย์โหลด Responses ที่ไม่มีฟิลด์นี้จะคง cacheWrite ไว้ที่ 0 API Chat Completions ของ OpenAI ไม่ได้ระบุหรือส่งตัวนับ cache_write_tokens แต่ OpenClaw ยังคงอ่าน prompt_tokens_details.cache_write_tokens ในตำแหน่งนั้นสำหรับพร็อกซีที่เข้ากันได้กับ OpenRouter และพร็อกซีแบบ DeepSeek ซึ่งรายงานจำนวนการเขียนแยกต่างหาก
• ในทางปฏิบัติ OpenAI ทำงานคล้ายแคชคำนำหน้าเริ่มต้นมากกว่าการนำประวัติทั้งหมดแบบเลื่อนตามข้อมูลของ Anthropic กลับมาใช้ใหม่ โปรดดู พฤติกรรมที่คาดหวังจาก OpenAI แบบสด ด้านล่าง

Amazon Bedrock

• การอ้างอิงโมเดล Anthropic Claude (amazon-bedrock/*anthropic.claude* รวมถึงคำนำหน้าโปรไฟล์การอนุมานระบบของ AWS ได้แก่ us./eu./global.anthropic.claude*) รองรับการส่งผ่าน cacheRetention อย่างชัดเจน
• โมเดล Bedrock ที่ไม่ใช่ Anthropic (เช่น amazon.nova-*) จะถูกแก้ไขเป็นไม่มีการเก็บรักษาแคชขณะรันไทม์ ไม่ว่าจะกำหนดค่า cacheRetention ไว้เป็นค่าใดก็ตาม
• ARN ของโปรไฟล์การอนุมานแอปพลิเคชัน Bedrock แบบทึบ (รหัสโปรไฟล์ที่ไม่มี claude) จะถูกแก้ไขเป็นไม่มีการเก็บรักษาแคชเช่นกัน เว้นแต่จะกำหนด cacheRetention ไว้อย่างชัดเจน เนื่องจากไม่สามารถอนุมานตระกูลโมเดลจาก ARN เพียงอย่างเดียวได้

OpenRouter

สำหรับการอ้างอิงโมเดล openrouter/anthropic/* OpenClaw จะแทรกเครื่องหมาย cache_control ของ Anthropic ในบล็อกพรอมต์ระดับระบบ/นักพัฒนา แต่เฉพาะเมื่อคำขอยังคงมุ่งไปยังเส้นทาง OpenRouter ที่ผ่านการตรวจสอบแล้ว (openrouter บนปลายทางเริ่มต้น หรือผู้ให้บริการ/URL ฐานใดๆ ที่แก้ไขไปยัง openrouter.ai) การเปลี่ยนให้โมเดลชี้ไปยัง URL พร็อกซีที่เข้ากันได้กับ OpenAI ใดๆ จะหยุดการแทรกนี้

อนุญาตให้ใช้ contextPruning.mode: "cache-ttl" สำหรับการอ้างอิงโมเดล openrouter/anthropic/*, openrouter/deepseek/*, openrouter/moonshot/*, openrouter/moonshotai/* และ openrouter/zai/* เนื่องจากเส้นทางเหล่านี้จัดการการแคชพรอมต์ฝั่งผู้ให้บริการโดยไม่ต้องใช้เครื่องหมายที่ OpenClaw แทรก

แหล่งที่มา: extensions/openrouter/index.ts (OPENROUTER_CACHE_TTL_MODEL_PREFIXES)

การสร้างแคช DeepSeek บน OpenRouter เป็นแบบพยายามให้ดีที่สุดและอาจใช้เวลาสองสามวินาที คำขอต่อเนื่องที่ส่งทันทีอาจยังแสดง cached_tokens: 0 ให้ตรวจสอบด้วยคำขอที่มีคำนำหน้าเดิมซ้ำอีกครั้งหลังจากหน่วงเวลาสั้นๆ โดยใช้ usage.prompt_tokens_details.cached_tokens เป็นสัญญาณว่าแคชฮิต

Google Gemini (API โดยตรง)

• การส่งข้อมูล Gemini โดยตรง (api: "google-generative-ai") รายงานแคชฮิตผ่าน cachedContentTokenCount จากต้นทาง ซึ่งแมปไปยัง cacheRead
• ตระกูลโมเดลที่มีสิทธิ์: gemini-2.5* และ gemini-3* (ไม่รวมรุ่น Live/พรีวิวที่อยู่นอกการจับคู่คำนำหน้านั้น เช่น gemini-live-2.5-flash-preview)
• เมื่อกำหนด cacheRetention บนโมเดลที่มีสิทธิ์ OpenClaw จะสร้าง นำกลับมาใช้ และรีเฟรชทรัพยากร cachedContents สำหรับพรอมต์ระบบโดยอัตโนมัติ โดยไม่ต้องใช้แฮนเดิลเนื้อหาที่แคชด้วยตนเอง TTL คือ 300s สำหรับ cacheRetention: "short" และ 3600s สำหรับ "long"
• ยังคงสามารถส่งแฮนเดิลเนื้อหาที่แคชไว้ล่วงหน้าของ Gemini ผ่านเป็น params.cachedContent (หรือ params.cached_content แบบเดิม) ได้ การระบุแฮนเดิลอย่างชัดเจนจะข้ามเส้นทางการจัดการแคชอัตโนมัติทั้งหมด
• สิ่งนี้แยกต่างหากจากการแคชคำนำหน้าพรอมต์ของ Anthropic/OpenAI โดย OpenClaw จะจัดการทรัพยากร cachedContents ดั้งเดิมของผู้ให้บริการสำหรับ Gemini แทนการแทรกเครื่องหมายแคชแบบอินไลน์

แหล่งที่มา: src/agents/embedded-agent-runner/google-prompt-cache.ts

ผู้ให้บริการผ่านชุดทดสอบ CLI (Claude Code, Gemini CLI)

แบ็กเอนด์ CLI ที่ส่งเหตุการณ์การใช้งานแบบ JSONL (jsonlDialect: "claude-stream-json" หรือ "gemini-stream-json") จะผ่านตัวแยกวิเคราะห์การใช้งานร่วมกัน ซึ่งรู้จักชื่อฟิลด์หลายรูปแบบ รวมถึงตัวนับ cached แบบธรรมดาที่แมปไปยัง cacheRead เมื่อเพย์โหลด JSON ของ CLI ไม่มีฟิลด์โทเค็นอินพุตโดยตรง OpenClaw จะคำนวณค่านั้นเป็น input_tokens - cached นี่เป็นเพียงการปรับข้อมูลการใช้งานให้เป็นรูปแบบมาตรฐาน และไม่ได้สร้างเครื่องหมายแคชพรอมต์แบบ Anthropic/OpenAI สำหรับโมเดลที่ขับเคลื่อนผ่าน CLI เหล่านี้

แหล่งที่มา: src/agents/cli-output.ts (toCliUsage)

ผู้ให้บริการอื่น

หากผู้ให้บริการไม่รองรับโหมดแคชใดๆ ข้างต้น cacheRetention จะไม่มีผล

ขอบเขตแคชของพรอมต์ระบบ

OpenClaw แบ่งพรอมต์ระบบออกเป็น คำนำหน้าคงที่ และ คำต่อท้ายที่เปลี่ยนแปลงได้ ณ ขอบเขตคำนำหน้าแคชภายใน เนื้อหาเหนือขอบเขต (นิยามเครื่องมือ เมทาดาทา Skills และไฟล์เวิร์กสเปซ) จะถูกจัดลำดับให้คงความเหมือนกันทุกไบต์ข้ามเทิร์น เนื้อหาใต้ขอบเขต (เช่น HEARTBEAT.md การประทับเวลารันไทม์ และเมทาดาทาอื่นที่แตกต่างในแต่ละเทิร์น) สามารถเปลี่ยนแปลงได้โดยไม่ทำให้คำนำหน้าที่แคชไว้ใช้ไม่ได้

ตัวเลือกการออกแบบที่สำคัญ:

• ไฟล์บริบทโปรเจกต์ในเวิร์กสเปซที่คงที่จะถูกจัดลำดับไว้ก่อน HEARTBEAT.md เพื่อไม่ให้การเปลี่ยนแปลงของ Heartbeat ทำลายคำนำหน้าคงที่
• ขอบเขตนี้ใช้กับการจัดรูปแบบการส่งข้อมูลในตระกูล Anthropic, ตระกูล OpenAI, Google และ CLI เพื่อให้ผู้ให้บริการที่รองรับทั้งหมดได้รับประโยชน์จากความคงที่ของคำนำหน้าแบบเดียวกัน
• คำขอ Codex Responses และ Anthropic Vertex ถูกกำหนดเส้นทางผ่านการจัดรูปแบบแคชที่รับรู้ขอบเขต เพื่อให้การนำแคชกลับมาใช้สอดคล้องกับข้อมูลที่ผู้ให้บริการได้รับจริง
• ลายนิ้วมือของพรอมต์ระบบถูกปรับให้อยู่ในรูปแบบมาตรฐาน (ช่องว่าง อักขระขึ้นบรรทัดใหม่ บริบทที่เพิ่มโดยฮุก และลำดับความสามารถของรันไทม์) เพื่อให้พรอมต์ที่ไม่มีการเปลี่ยนแปลงด้านความหมายใช้แคชร่วมกันข้ามเทิร์นได้

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

กลไกป้องกันความคงที่ของแคชใน OpenClaw

• แค็ตตาล็อกเครื่องมือ MCP ที่รวมมาในชุดจะถูกเรียงลำดับแบบกำหนดผลลัพธ์แน่นอน (ตามชื่อเซิร์ฟเวอร์ แล้วตามชื่อเครื่องมือ) ก่อนลงทะเบียนเครื่องมือ เพื่อไม่ให้การเปลี่ยนลำดับ listTools() ทำให้บล็อกเครื่องมือเปลี่ยนไปมาและทำลายคำนำหน้าแคชพรอมต์
• เซสชันแบบเดิมที่มีบล็อกรูปภาพที่บันทึกไว้จะเก็บ 3 เทิร์นที่เสร็จสมบูรณ์ล่าสุด ไว้ครบถ้วน (นับเทิร์นที่เสร็จสมบูรณ์ทั้งหมด ไม่ใช่เฉพาะเทิร์นที่มีรูปภาพ) บล็อกรูปภาพเก่ากว่าที่ประมวลผลแล้วจะถูกแทนที่ด้วยเครื่องหมายข้อความ เพื่อไม่ให้คำขอต่อเนื่องที่มีรูปภาพจำนวนมากต้องส่งเพย์โหลดเก่าขนาดใหญ่ซ้ำต่อไป

รูปแบบการปรับแต่ง

การรับส่งข้อมูลแบบผสม (ค่าเริ่มต้นที่แนะนำ)

เก็บค่าพื้นฐานอายุยาวไว้ในเอเจนต์หลัก และปิดใช้งานการแคชสำหรับเอเจนต์แจ้งเตือนที่ทำงานเป็นช่วงสั้นๆ:

agents:  defaults:    model:      primary: "anthropic/claude-opus-4-6"    models:      "anthropic/claude-opus-4-6":        params:          cacheRetention: "long"  list:    - id: "research"      default: true      heartbeat:        every: "55m"    - id: "alerts"      params:        cacheRetention: "none"

ค่าพื้นฐานที่ให้ความสำคัญกับต้นทุน

• กำหนดค่าพื้นฐาน cacheRetention: "short"
• เปิดใช้งาน contextPruning.mode: "cache-ttl"
• ตั้งค่า Heartbeat ให้ต่ำกว่า TTL เฉพาะสำหรับเอเจนต์ที่ได้รับประโยชน์จากแคชอุ่น

การทดสอบการถดถอยแบบสด

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

• src/agents/live-cache-regression.live.test.ts
• src/agents/live-cache-regression-runner.ts
• src/agents/live-cache-regression-baseline.ts

เรียกใช้ด้วย:

OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache

ไฟล์ค่าฐานจัดเก็บตัวเลขจากระบบจริงที่สังเกตได้ล่าสุด รวมถึงค่าต่ำสุดสำหรับตรวจจับการถดถอยเฉพาะผู้ให้บริการที่การทดสอบใช้ตรวจสอบ การรันแต่ละครั้งใช้ ID เซสชันและเนมสเปซพรอมต์ใหม่เฉพาะการรัน เพื่อไม่ให้สถานะแคชก่อนหน้าปนเปื้อนตัวอย่างปัจจุบัน Anthropic และ OpenAI ใช้การบังคับใช้ต่างกัน: การต่ำกว่าค่าต่ำสุดของ Anthropic ถือเป็นการถดถอยร้ายแรง (การทดสอบล้มเหลว) ส่วนการต่ำกว่าค่าต่ำสุดของ OpenAI ใช้สำหรับเฝ้าระวังเท่านั้น (บันทึกเป็นคำเตือนและไม่ทำให้การรันล้มเหลว) ทั้งสองไม่ได้ใช้เกณฑ์เดียวกันข้ามผู้ให้บริการ

ความคาดหวังจากระบบจริงของ Anthropic

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

ความคาดหวังจากระบบจริงของ OpenAI

• คาดว่าจะมีเฉพาะ cacheRead; cacheWrite ยังคงเป็น 0 บน Chat Completions
• ให้ถือว่าการนำแคชกลับมาใช้ซ้ำในการโต้ตอบรอบถัดไปเป็นระดับคงที่เฉพาะผู้ให้บริการ ไม่ใช่การนำประวัติทั้งหมดกลับมาใช้ซ้ำแบบเลื่อนตาม Anthropic
• ค่าต่ำสุดใช้สำหรับเฝ้าระวังเท่านั้น (หากต่ำกว่าจะบันทึกเป็นคำเตือน ไม่ใช่ทำให้การทดสอบล้มเหลว) โดยได้มาจากพฤติกรรมที่สังเกตจากระบบจริงบน gpt-5.4-mini:

ตัวเลขค่าฐานที่สังเกตได้ล่าสุด (จาก live-cache-regression-baseline.ts) อยู่ที่: คำนำหน้าแบบเสถียร cacheRead=4864, อัตราการพบ 0.966; ทรานสคริปต์เครื่องมือ cacheRead=4608, อัตราการพบ 0.896; ทรานสคริปต์รูปภาพ cacheRead=4864, อัตราการพบ 0.954; ทรานสคริปต์รูปแบบ MCP cacheRead=4608, อัตราการพบ 0.891

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

การกำหนดค่า diagnostics.cacheTrace

diagnostics:  cacheTrace:    enabled: true    filePath: "~/.openclaw/logs/cache-trace.jsonl" # ไม่บังคับ    includeMessages: false # ค่าเริ่มต้น true    includePrompt: false # ค่าเริ่มต้น true    includeSystem: false # ค่าเริ่มต้น true

ค่าเริ่มต้น:

ตัวสลับผ่านตัวแปรสภาพแวดล้อม (สำหรับดีบักเฉพาะกิจ)

สิ่งที่ควรตรวจสอบ

• เหตุการณ์การติดตามแคชอยู่ในรูปแบบ JSONL พร้อมสแนปชอตตามลำดับขั้น เช่น session:loaded, prompt:before, stream:context และ session:after
• ผลกระทบต่อโทเค็นแคชในแต่ละรอบมองเห็นได้ในพื้นผิวการใช้งานปกติ: cacheRead และ cacheWrite จะแสดงใน /usage tokens, /status, สรุปการใช้งานเซสชัน และเลย์เอาต์ messages.usageTemplate แบบกำหนดเอง
• สำหรับ Anthropic คาดว่าจะพบทั้ง cacheRead และ cacheWrite เมื่อการแคชทำงานอยู่
• สำหรับ OpenAI คาดว่าจะพบ cacheRead เมื่อพบข้อมูลในแคช ส่วน cacheWrite จะมีค่าเฉพาะในเพย์โหลด Responses API ที่มีข้อมูลนี้ (ดู OpenAI ด้านบน)
• OpenAI ยังส่งคืนส่วนหัวสำหรับการติดตามและการจำกัดอัตรา เช่น x-request-id, openai-processing-ms และ x-ratelimit-*; ใช้ค่าเหล่านี้เพื่อติดตามคำขอ แต่การคำนวณการพบข้อมูลในแคชยังคงต้องมาจากเพย์โหลดการใช้งาน ไม่ใช่จากส่วนหัว

การแก้ปัญหาอย่างรวดเร็ว

• ค่า cacheWrite สูงในรอบส่วนใหญ่: ตรวจสอบอินพุตพรอมต์ระบบที่เปลี่ยนแปลงบ่อย และตรวจสอบว่าโมเดล/ผู้ให้บริการรองรับการตั้งค่าแคช
• ค่า cacheWrite สูงบน Anthropic: มักหมายความว่าจุดแบ่งแคชอยู่บนเนื้อหาที่เปลี่ยนแปลงทุกคำขอ
• ค่า cacheRead ของ OpenAI ต่ำ: ตรวจสอบว่าคำนำหน้าแบบเสถียรอยู่ด้านหน้า คำนำหน้าที่ซ้ำกันมีอย่างน้อย 1024 โทเค็น และนำ prompt_cache_key เดิมกลับมาใช้ซ้ำสำหรับรอบที่ควรใช้แคชร่วมกัน
• cacheRetention ไม่มีผล: ตรวจสอบว่าคีย์โมเดลตรงกับ agents.defaults.models["provider/model"]
• คำขอ Bedrock Nova ที่มีการตั้งค่าแคช: เป็นพฤติกรรมที่คาดไว้ เนื่องจากระบบจะแปลงค่าเหล่านี้เป็นการไม่เก็บแคชขณะรันไทม์

เอกสารที่เกี่ยวข้อง:

• Anthropic
• การใช้โทเค็นและค่าใช้จ่าย
• การตัดแต่งเซสชัน
• เอกสารอ้างอิงการกำหนดค่า Gateway

ที่เกี่ยวข้อง

• การใช้โทเค็นและค่าใช้จ่าย
• การใช้งาน API และค่าใช้จ่าย