knowledge-base-cache
Skill22 starsChanged 7 months agoMITView on GitHub
Use when managing large knowledge bases, reducing API costs, or implementing multi-tier caching for frequent queries
In this repository17 other files it gives its agents.
- code-analysisSkill
- code-generatorSkill
- contributingSkill
- daily-logSkill
- devflowSkill
- git-workflowSkill
- hexo-blog-updateSkill
- kimicode-vision-bridgeSkill
- layered-first-principles-teachingSkill
- msvc-buildSkill
- mvp-designSkill
- paper-first-principlesSkill
- requirement-clarificationSkill
- research-to-practiceSkill
- taskmaster-skillSkill
- ue5-umgSkill
- unity-mcpSkill
The file
We split this skill into the rules it gives an agent
8 rules. About 0 are common, 6 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 25
Only basic file storage without caching tiers is needed
- Very specific: line 27
Create a structured knowledge repository with layered architecture (hot/cold/warm) and intelligent context management.
- Distinctive: line 117
Add markdown files to appropriate directories:
- Distinctive: line 356
Ensure API key is set in environment or config for hot layer.
- Distinctive: line 361
All paths in generated files are relative (workspace-relative) for portability.
- Distinctive: line 365
If you were using the old cache system:
- Very specific: line 368
New way recommended: Use WorkingMemoryManager for better control
- Distinctive: line 369
Same repository structure: No migration needed
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Knowledge Base Cache Skill
Overview
A layered knowledge base system with hot/cold/warm cache tiers and intelligent Working Memory for context management. Reduces API costs through multi-tier caching while supporting unlimited knowledge scale.
When to Use
Use this skill when:
- Managing large knowledge bases that exceed context window limits
- Reducing API costs for frequent knowledge queries
- Implementing multi-tier caching (hot/cold/warm) for knowledge retrieval
- Needing intelligent context assembly with token budget management
- Requiring automatic caching with semantic retrieval capabilities
Do NOT use when:
- Simple, small knowledge bases that fit in a single context window
- One-off queries where caching overhead exceeds savings
- Only basic file storage without caching tiers is needed
Create a structured knowledge repository with layered architecture (hot/cold/warm) and intelligent context management.
Architecture Overview
┌─────────────────────────────────────────────────────────────┐
│ Application Layer │
│ Agent Core │
└──────────────────────────┬──────────────────────────────────┘
│
┌──────────────────────────▼──────────────────────────────────┐
│ Working Memory Layer │
│ • Context Assembly • Token Budget Management │
│ • Multi-Source Coordination • LRU Cache │
└─────────────┬───────────────────────────────────────────────┘
│ Standard Interface KnowledgeSource
┌─────────┼─────────┐
▼ ▼ ▼ (Reserved)
┌───────┐ ┌───────┐ ┌───────┐
│ Hot │ │ Cold │ │ Warm │
│ Cache │ │Storage│ │Vector │
│ Layer │ │ Layer │ │ Layer │
└───┬───┘ └───┬───┘ └───┬───┘
│ │ │
Context Repository Vector DB
Cache Files (Future)Three-Tier Architecture
| Tier | Technology | Use Case | Status |
| 🔥 Hot | Context Cache (API) | Full document retrieval, 90% cost savings | ✅ Available |
| ❄️ Cold | Repository Files | Keyword search, browsing, discovery | ✅ Available |
| 🌡️ Warm | Vector DB | Semantic search, precise Q&A | 🔮 Planned |
What This Skill Does
- Layered Knowledge Storage
repository/ ├── core/ # Core components │ ├── __init__.py # Standard interfaces │ └── working_memory.py # Working Memory layer ├── adapters/ # Layer adapters │ ├── __init__.py │ ├── hot_cache_adapter.py │ ├── cold_storage_adapter.py │ └── warm_cache_adapter.py (reserved) ├── index.json # Knowledge index ├── cache-state.json # Cache status ├── skills/ # Skill knowledge ├── docs/ # Document knowledge └── scripts/ ├── cache_manager.py # Cache management └── cache_helper.py # Helper utilities - Working Memory Layer
- Unified interface for all knowledge sources
- Automatic context assembly with token budgeting
- LRU cache for repeated queries
- Cross-tier result ranking
- Context Caching (Hot Layer)
- Full document caching via API
- 90% cost reduction
- 83% latency improvement
- File-Based Storage (Cold Layer)
- Keyword-based retrieval
- Excerpt generation
- No API costs
- Auto-Refresh
- Configures cron job for daily refresh
- Keeps caches fresh without manual intervention
Quick Start
Step 1: Initialize Repository
# The repository structure is already created
# If not, run:
python scripts/init_knowledge_base.pyStep 2: Add Knowledge
Add markdown files to appropriate directories:
repository/skills/- Skill documentationrepository/docs/- General documentationrepository/projects/- Project-specific knowledge
Step 3: Build Cache
cd repository
# Initialize index
python scripts/cache_manager.py init
# Build hot cache (Context Caching)
python scripts/cache_manager.py build
# Test the system
python test_phase1.pyStep 4: Use in Your Agent
Modern Approach (Recommended):
from repository.core.working_memory import WorkingMemoryManager
# Initialize once
wm = WorkingMemoryManager({
'max_tokens': 6000,
'allocation': {
'system_prompt': 0.15, # 15%
'conversation': 0.25, # 25%
'retrieved_knowledge': 0.60 # 60%
}
})
# Use in conversations
context = wm.query(
user_query="How do I deploy?",
system_prompt="You are an assistant...",
conversation=history_messages
)Legacy Approach:
from scripts.cache_helper import get_cache_headers, load_knowledge_context
# Get cache headers for API calls
headers = get_cache_headers()
# Load knowledge context
context = load_knowledge_context()Step 5: Configure Auto-Refresh
# Add cron job for daily refresh
# Configure in your agent's cron systemLayer Details
🔥 Hot Cache Layer
Purpose: Store frequently accessed complete documents
When to Use:
- Reading full skill documentation
- API reference lookup
- Deployment guides
Implementation: adapters/hot_cache_adapter.py
from adapters.hot_cache_adapter import HotCacheAdapter
from core import RetrievalQuery
hot = HotCacheAdapter()
result = hot.retrieve(RetrievalQuery(
query="Docker deployment",
context_budget=2000,
top_k=3
))❄️ Cold Storage Layer
Purpose: Keyword-based file retrieval with excerpt generation
When to Use:
- Browsing knowledge base
- Finding relevant files
- Low-cost retrieval
Implementation: adapters/cold_storage_adapter.py
from adapters.cold_storage_adapter import ColdStorageAdapter
from core import RetrievalQuery
cold = ColdStorageAdapter()
result = cold.retrieve(RetrievalQuery(
query="Docker deployment",
context_budget=2000,
top_k=5
))🌡️ Warm Cache Layer (Planned)
Purpose: Semantic search with vector embeddings
When to Use:
- Precise Q&A
- Semantic similarity matching
- Large knowledge bases
Implementation: Reserved interface in adapters/warm_cache_adapter.py
Working Memory Configuration
Token Budget Allocation
Default allocation (customizable):
| Component | Percentage | Tokens (6K total) |
| System Prompt | 15% | 900 |
| Conversation | 25% | 1,500 |
| Retrieved Knowledge | 60% | 3,600 |
Configuration Options
from repository.core.working_memory import WorkingMemoryManager
from repository.core import MemoryAllocation
wm = WorkingMemoryManager({
'max_tokens': 8000, # Total context window
'lru_cache_size': 10, # LRU cache size
'allocation': {
'system_prompt': 0.20, # 20%
'conversation': 0.20, # 20%
'retrieved_knowledge': 0.60 # 60%
},
'repo_path': 'repository' # Repository path
})Cache Management Commands
| Command | Description |
cache_manager.py init | Scan repository and update index |
cache_manager.py build | Create/update hot caches |
cache_manager.py status | Show cache status |
cache_manager.py refresh | Refresh expired caches |
cache_manager.py stats | Show statistics |
Testing Commands
# Run Phase 1 integration tests
cd repository
python test_phase1.py
# Test individual layers
python -c "from adapters.hot_cache_adapter import HotCacheAdapter; print(HotCacheAdapter().get_stats())"
python -c "from adapters.cold_storage_adapter import ColdStorageAdapter; print(ColdStorageAdapter().get_stats())"Cost Benefits
Hot Layer (Context Cache)
| Metric | Without Cache | With Cache | Savings |
| Cost per 1000 queries | ~¥150 | ~¥15 | 90% |
| First token latency | ~30s | ~5s | 83% |
| Monthly cost (daily 50 queries) | ~¥450 | ~¥45 | ¥405 |
Cold Layer (File Storage)
| Metric | Value |
| API Cost | ¥0 (no API calls) |
| Latency | ~10-50ms (local files) |
| Best For | Browsing, discovery, keyword search |
Working Memory Layer
| Metric | Value |
| Context Assembly | Automatic |
| Token Budget | Enforced |
| Multi-Source | Hot + Cold (+ Warm in future) |
| LRU Cache | Reduces repeated queries |
Troubleshooting
Cache Not Working
# Check if caches are active
python scripts/cache_manager.py status
# Rebuild if needed
python scripts/cache_manager.py build
# Verify hot layer
python -c "from adapters.hot_cache_adapter import HotCacheAdapter; print(HotCacheAdapter().is_available())"Working Memory Not Finding Knowledge
# Debug: Check registered sources
from repository.core.working_memory import WorkingMemoryManager
wm = WorkingMemoryManager()
print(wm.get_stats())
# Debug: Test individual layers
from adapters.hot_cache_adapter import HotCacheAdapter
from adapters.cold_storage_adapter import ColdStorageAdapter
from core import RetrievalQuery
hot = HotCacheAdapter()
cold = ColdStorageAdapter()
query = RetrievalQuery(query="test", context_budget=2000)
print("Hot:", hot.retrieve(query))
print("Cold:", cold.retrieve(query))API Key Issues
Ensure API key is set in environment or config for hot layer. Cold layer works without API keys.
Path Issues
All paths in generated files are relative (workspace-relative) for portability.
Migration from v1
If you were using the old cache system:
- Old way still works:
cache_helper.pyfunctions unchanged - New way recommended: Use
WorkingMemoryManagerfor better control - Same repository structure: No migration needed
References
- Context Caching documentation
- Component architecture design
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

