Task #93: Add Chronicler session management architecture

Per Gemini consultation on model switching:
- Added future expansion section for Chronicler Orchestration Layer
- Middleware routing (Haiku/4.5/4.6 based on query type)
- Compressed state management (not raw history)
- RAG for historical context queries
- Prompt caching at API level

Saved consultation: docs/consultations/2026-04-07-model-switching.md

Long-term solution integrated into Codex roadmap.
Short-term: exploring Claude Projects optimization.

Chronicler #66 - The Indexer
This commit is contained in:
Claude
2026-04-07 20:05:12 +00:00
parent 52688618ee
commit f2e99ed9f6
2 changed files with 144 additions and 0 deletions

View File

@@ -429,6 +429,56 @@ Per Gemini's recommendation:
---
## 🔄 FUTURE EXPANSION: Chronicler Session Management
**Added:** April 7, 2026 by Chronicler #66 (per Gemini consultation)
### The Problem
Chronicler sessions hit "Context Bloat Wall" — switching between models (4.5 for ops, 4.6 for coding) loses context. Current workarounds (copy-paste, handoff docs) are manual and error-prone.
### The Long-Term Solution (Build into Codex)
Gemini recommends evolving Trinity Codex into a full **Chronicler Orchestration Layer**:
1. **Middleware Router in Dify**
- Simple queries → route to Haiku (cheap, fast)
- Documentation queries → route to Opus 4.5
- Complex coding queries → route to Opus 4.6
- User experience feels like one continuous Chronicler
2. **Compressed State Management**
- End of session: Model generates dense JSON state summary
- State stored in Codex (not raw chat history)
- New session injects only compressed state + system prompt
- 90%+ token reduction vs passing full history
3. **RAG for Historical Context**
- Instead of passing chat history, query Codex
- "What did #62 decide about ModpackChecker schema?" → vector search
- Past decisions accessible without token bloat
4. **Prompt Caching (API-level)**
- Cache system prompt + persona + standards docs
- New requests read cached context at ~10% token cost
- Requires API access (not web UI)
### Implementation Phases
| Phase | What | When |
|-------|------|------|
| 1 | Basic Codex (current spec) | After soft launch |
| 2 | Add session state storage | After Phase 1 stable |
| 3 | Add model routing logic | When token costs justify |
| 4 | Full orchestration layer | RV-Ready milestone |
### Reference
- Gemini consultation: `docs/consultations/2026-04-07-model-switching.md`
- Context handoff template: `docs/templates/context-handoff-template.md`
---
## Open Questions for Implementation
1. What's the current Dify version on TX1?