Technical reference
การแคชพรอมต์
การแคชพรอมต์ช่วยให้ผู้ให้บริการโมเดลนำคำนำหน้าพรอมต์ที่ไม่เปลี่ยนแปลง (คำสั่งระบบ/นักพัฒนา นิยามเครื่องมือ และบริบทคงที่อื่น ๆ) กลับมาใช้ซ้ำระหว่างรอบได้ แทนที่จะประมวลผลใหม่ทุกคำขอ ซึ่งช่วยลดต้นทุนโทเค็นและเวลาแฝงในเซสชันที่ทำงานยาวนานและมีบริบทซ้ำ
OpenClaw ปรับข้อมูลการใช้งานจากผู้ให้บริการให้อยู่ในรูป cacheRead และ cacheWrite เมื่อใดก็ตามที่ API ต้นทางเปิดเผยตัวนับเหล่านี้ สรุปการใช้งาน (/status และคำสั่งที่คล้ายกัน) จะใช้รายการการใช้งานล่าสุดจากทรานสคริปต์เป็นค่าทดแทน เมื่อสแนปช็อตเซสชันปัจจุบันไม่มีตัวนับแคช โดยค่าปัจจุบันที่ไม่เป็นศูนย์จะมีลำดับความสำคัญเหนือค่าทดแทนเสมอ
เอกสารอ้างอิงของผู้ให้บริการ:
การตั้งค่าหลัก
cacheRetention
ค่า: "none" | "short" | "long" สามารถกำหนดเป็นค่าเริ่มต้นส่วนกลาง แยกตามโมเดล และแยกตามเอเจนต์ได้
agents: defaults: params: cacheRetention: "long" # none | short | long models: "anthropic/claude-opus-4-6": params: cacheRetention: "short" # แทนที่ค่าเริ่มต้นส่วนกลางสำหรับโมเดลนี้ list: - id: "alerts" params: cacheRetention: "none" # แทนที่ค่าเริ่มต้นทั้งสองระดับสำหรับเอเจนต์นี้ลำดับการผสาน (รายการหลังมีลำดับความสำคัญสูงกว่า):
agents.defaults.params- ค่าเริ่มต้นส่วนกลางสำหรับทุกโมเดลagents.defaults.models["provider/model"].params- ค่าที่แทนที่แยกตามโมเดล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 นาที
แหล่งที่มา: src/agents/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ซึ่งเป็นtrueโดยค่าเริ่มต้น แต่โปรไฟล์ความเข้ากันได้ของ 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ไว้ที่0API Chat Completions ของ OpenAI ไม่ได้จัดทำเอกสารหรือส่งตัวนับcache_write_tokensแต่ OpenClaw ยังคงอ่านprompt_tokens_details.cache_write_tokensจาก API ดังกล่าวสำหรับพร็อกซีที่เข้ากันได้กับ OpenRouter และพร็อกซีรูปแบบ DeepSeek ที่รายงานจำนวนการเขียนแยกต่างหาก - ในการใช้งานจริง OpenAI มีพฤติกรรมคล้ายแคชคำนำหน้าเริ่มต้น มากกว่าการนำประวัติทั้งหมดที่เลื่อนไปข้างหน้าของ Anthropic มาใช้ซ้ำ โปรดดู ความคาดหวังจากการใช้งานจริงของ OpenAI ด้านล่าง
Amazon Bedrock
- การอ้างอิงโมเดล Anthropic Claude (
amazon-bedrock/*anthropic.claude*รวมถึงคำนำหน้าโปรไฟล์การอนุมานของระบบ AWSus./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.tssrc/agents/live-cache-regression-runner.tssrc/agents/live-cache-regression-baseline.ts
เรียกใช้ด้วย:
OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cacheไฟล์ค่าพื้นฐานจัดเก็บตัวเลขจากการใช้งานจริงที่สังเกตได้ล่าสุด พร้อมเกณฑ์ขั้นต่ำการถดถอยเฉพาะผู้ให้บริการที่การทดสอบใช้ตรวจสอบ การเรียกใช้แต่ละครั้งใช้รหัสเซสชันและเนมสเปซพรอมต์ใหม่ เพื่อไม่ให้สถานะแคชก่อนหน้าปนเปื้อนตัวอย่างปัจจุบัน Anthropic และ OpenAI ใช้การบังคับใช้ที่ต่างกัน: หาก Anthropic ต่ำกว่าเกณฑ์ขั้นต่ำจะถือเป็นการถดถอยอย่างชัดเจน (การทดสอบล้มเหลว) ส่วน OpenAI หากต่ำกว่าเกณฑ์ขั้นต่ำจะเป็นเพียงการเฝ้าระวัง (บันทึกเป็นคำเตือน แต่ไม่ทำให้การเรียกใช้ล้มเหลว) ทั้งสองไม่ได้ใช้เกณฑ์เดียวกันข้ามผู้ให้บริการ
ความคาดหวังจากการใช้งานจริงของ Anthropic
- คาดว่าจะมีการเขียนข้อมูลช่วงวอร์มอัปอย่างชัดเจนผ่าน
cacheWrite - คาดว่าจะนำประวัติเกือบทั้งหมดกลับมาใช้ซ้ำในการโต้ตอบรอบถัด ๆ ไป เนื่องจากการควบคุมแคชของ Anthropic เลื่อนจุดแบ่งแคชไปตามบทสนทนา
- ค่าขั้นต่ำอ้างอิงสำหรับเลนแบบคงที่ เครื่องมือ รูปภาพ และรูปแบบ MCP เป็นเกณฑ์ตรวจจับการถดถอยแบบบังคับ
สิ่งที่คาดหวังจากการใช้งาน OpenAI แบบสด
- คาดว่าจะมีเฉพาะ
cacheReadโดยcacheWriteจะคงเป็น0บน Chat Completions - ให้ถือว่าการนำแคชกลับมาใช้ซ้ำในการโต้ตอบรอบถัด ๆ ไปจะคงที่อยู่ที่ระดับหนึ่งซึ่งขึ้นอยู่กับผู้ให้บริการ ไม่ใช่การนำประวัติทั้งหมดที่เลื่อนไปตามบทสนทนากลับมาใช้ซ้ำแบบ Anthropic
- ค่าขั้นต่ำใช้สำหรับเฝ้าดูเท่านั้น (หากไม่ถึงค่าจะบันทึกเป็นคำเตือน ไม่ใช่ทำให้การทดสอบล้มเหลว) โดยอ้างอิงจากพฤติกรรมการใช้งานจริงที่สังเกตพบบน
gpt-5.4-mini:
| สถานการณ์ | ค่าขั้นต่ำของ cacheRead |
ค่าขั้นต่ำของอัตราการพบแคช |
|---|---|---|
| คำนำหน้าคงที่ | 4,608 | 0.90 |
| ทรานสคริปต์เครื่องมือ | 4,096 | 0.85 |
| ทรานสคริปต์รูปภาพ | 3,840 | 0.82 |
| ทรานสคริปต์รูปแบบ MCP | 4,096 | 0.85 |
ตัวเลขอ้างอิงล่าสุดที่สังเกตพบ (จาก 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ค่าเริ่มต้น:
| คีย์ | ค่าเริ่มต้น |
|---|---|
filePath |
$OPENCLAW_STATE_DIR/logs/cache-trace.jsonl |
includeMessages |
true |
includePrompt |
true |
includeSystem |
true |
ตัวสลับผ่านตัวแปรสภาพแวดล้อม (สำหรับการแก้จุดบกพร่องครั้งเดียว)
| ตัวแปร | ผลลัพธ์ |
|---|---|
OPENCLAW_CACHE_TRACE=1 |
เปิดใช้งานการติดตามแคช |
OPENCLAW_CACHE_TRACE_FILE=path |
เขียนทับพาธเอาต์พุต |
OPENCLAW_CACHE_TRACE_MESSAGES=0|1 |
สลับการบันทึกเพย์โหลดข้อความทั้งหมด |
OPENCLAW_CACHE_TRACE_PROMPT=0|1 |
สลับการบันทึกข้อความพรอมต์ |
OPENCLAW_CACHE_TRACE_SYSTEM=0|1 |
สลับการบันทึกพรอมต์ระบบ |
สิ่งที่ควรตรวจสอบ
- เหตุการณ์การติดตามแคชอยู่ในรูปแบบ 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 ที่มีการตั้งค่าแคช: เป็นพฤติกรรมที่คาดไว้ เนื่องจากคำขอเหล่านี้จะถูกแปลงเป็นการไม่เก็บรักษาแคชขณะรันไทม์
เอกสารที่เกี่ยวข้อง: