Langcache Semantic Caching for OpenClaw
v1.0.0This skill should be used when the user asks to "enable semantic caching", "cache LLM responses", "reduce API costs", "speed up AI responses", "configure LangCache", "search the semantic cache", "store responses in cache", or mentions Redis LangCache, semantic similarity caching, or LLM response caching. Provides integration with Redis LangCache managed service for semantic caching of prompts and responses.
⭐ 1· 1.6k·0 current·0 all-time
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
OpenClaw
Suspicious
medium confidencePurpose & Capability
The name, description, SKILL.md, and scripts consistently implement Redis LangCache integration and require LANGCACHE_HOST / LANGCACHE_CACHE_ID / LANGCACHE_API_KEY — this matches the stated purpose. However, registry metadata claims "Required env vars: none", which contradicts the SKILL.md and scripts that require LangCache credentials. That metadata mismatch is an incoherence that should be corrected.
Instruction Scope
Runtime instructions and shipped scripts perform only cache-related actions (search, store, delete, flush) against a user-provided LANGCACHE_HOST. However: (1) the CLI advertises "hard blocks" that 'NEVER get cached' but the CLI has a --force flag that explicitly allows storing blocked content (policy bypass). The SKILL.md claims blocked items are "blocked at the code level" — but the code permits override with --force, which contradicts the stated safety guarantee. (2) The Python example requires OPENAI_API_KEY for LLM calls but SKILL.md/prereq section only lists LANGCACHE_* env vars; that omission means the agent may attempt LLM calls without a declared credential. (3) The bash wrapper sources ~/.openclaw/secrets.env automatically, which will load whatever is in that file (not just LANGCACHE_*), so the skill reads arbitrary secret env vars if a user places them there.
Install Mechanism
This is instruction-only (no install spec) and the shipped files are local scripts/examples. No external downloads or archive extraction are in the install path, which minimizes install-time risk.
Credentials
The skill legitimately needs LANGCACHE_HOST/CACHE_ID/API_KEY. But: (1) registry metadata fails to list these required env vars (incoherent). (2) The example Python integration also requires OPENAI_API_KEY (not declared in SKILL.md prereqs), expanding required credentials beyond the advertised set. (3) The bash script sources ~/.openclaw/secrets.env wholesale, giving the script access to any secrets placed there (disproportionate if users store unrelated credentials in that file). (4) The presence of the --force override allows accidental or intentional caching of credentials/PII despite the stated 'NEVER CACHE' policy.
Persistence & Privilege
always:false (no forced persistent inclusion) and the skill does not modify other skills or system-wide agent settings. It does read a user-maintained secrets file and will make outbound requests to the configured LangCache host (and to LLM endpoints in examples), but it does not request elevated platform privileges.
What to consider before installing
What to check before installing/use: 1) Fix metadata mismatch: confirm the registry metadata lists LANGCACHE_HOST, LANGCACHE_CACHE_ID, LANGCACHE_API_KEY as required so permission reviews are accurate. 2) Audit the --force path: the CLI allows bypassing the 'NEVER CACHE' rules — remove or restrict --force unless you explicitly need it and understand the risk of storing PII/credentials. 3) Be careful with ~/.openclaw/secrets.env: the scripts source that file wholesale. Only store the required LANGCACHE_* variables there and tighten its file permissions (chmod 600) — avoid dumping unrelated secrets (OpenAI keys, cloud creds) into it. 4) If you plan to use the Python example, note it expects OPENAI_API_KEY (or another LLM API key); the SKILL.md should declare that. 5) Verify LANGCACHE_HOST endpoint ownership and trust the provider (the skill will send prompts/responses to that host). 6) If you need stricter guarantees, run the scripts in an isolated environment, review/modify the code to remove the --force bypass, and/or hard-code allowed env reads so only the necessary variables are loaded. 7) Overall: functionality appears legitimate for caching, but the policy bypass and metadata/env inconsistencies warrant manual review before deployment.Like a lobster shell, security has layers — review code before you run it.
latestvk972vsv2khe1526y3mjhpagxxh80hdgp
License
MIT-0
Free to use, modify, and redistribute. No attribution required.