adaptive-memory-multi-model-router 2.14.46 → 2.14.47

package/docs/COUNCIL_V2.2_DECISION.md

@@ -1,416 +0,0 @@
-# TMLPD Enhancement Strategy Council Evaluation
-
-**Date**: 2025-01-02
-**Council Session**: Strategic Enhancement Decision
-**Purpose**: Evaluate research-backed roadmap vs alternative approaches (RFT, fine-tuning, etc.)
-**Council Members**: 4 AI providers (Anthropic, OpenAI, Google, Cerebras)
-**Methodology**: Multi-perspective analysis with weighted scoring
-
----
-
-## 🎯 PROPOSALS EVALUATED
-
-### Proposal A: Research-Backed v2.2 Roadmap
-**Components**:
-1. HALO Hierarchical Orchestration (arXiv:2505.13516)
-2. Universal Learned Router (arXiv:2502.08773)
-3. Speculative Decoding (arXiv:2503.00491)
-4. Adaptive Early Exit (arXiv:2504.10724)
-5. MemoRAG Global Memory (arXiv:2409.05591)
-6. Circuit Breakers (industry pattern)
-7. Budget Management (enterprise feature)
-
-**Expected Impact**:
-- Speed: 4-8x improvement
-- Cost: 92% savings (up from 82%)
-- Quality: +35% improvement
-- Reliability: 70.32 uptime
-
-**Implementation Effort**: 5 weeks
-**Research Backing**: 7 arXiv papers (2024-2025)
-
----
-
-### Proposal B: Reinforcement Fine-Tuning (RFT)
-**Approach**: Fine-tune models on agent execution data
-- Collect execution trajectories (success/failure)
-- Train reward model on quality metrics
-- Fine-tune small models for specific agent tasks
-- Deploy custom models for routing, planning, execution
-
-**Expected Impact**:
-- Quality: +20-40% on task-specific performance
-- Cost: 10-20% additional savings (smaller fine-tuned models)
-- Speed: 1.2-1.5x (specialized models faster)
-- Customization: High (per-user/per-task models)
-
-**Implementation Effort**: 6-8 weeks
-**Research Backing**:
-- arXiv:2501.xxxxx (RFT for agents)
-- arXiv:2410.xxxxx (Reinforcement learning from AI feedback)
-- OpenAI RFT research (2024)
-
-**Risks**:
-- Model drift over time
-- High compute cost for training
-- Continuous retraining needed
-- Complex deployment (model management)
-- Less transferable to new tasks
-
----
-
-### Proposal C: Hybrid Approach (A + B)
-**Strategy**: Combine research roadmap + selective RFT
-- Implement v2.2 research features (foundational)
-- Add RFT for specific high-value tasks
-- Use fine-tuned models for niche use cases
-- Keep general-purpose models for most tasks
-
-**Expected Impact**:
-- Speed: 4-8x (from v2.2)
-- Cost: 93-95% savings (v2.2 + RFT)
-- Quality: +40-50% (v2.2 + task-specific tuning)
-- Flexibility: High (general + specialized)
-
-**Implementation Effort**: 7-9 weeks
-**Research Backing**: 10+ arXiv papers
-**Complexity**: High (two systems to maintain)
-
----
-
-### Proposal D: Alternative: RAG Enhancement Only
-**Strategy**: Double down on RAG/memory systems
-- Advanced retrieval (ColBERT, late interaction)
-- Hybrid search (dense + sparse)
-- Reranking models (Cohere, BGE)
-- Knowledge graphs for reasoning
-- Long-context compression
-
-**Expected Impact**:
-- Quality: +30-50% on knowledge-intensive tasks
-- Cost: 5-10% additional savings (better retrieval = fewer API calls)
-- Speed: 0.8-1x (retrieval overhead)
-- Specialization: Knowledge work only
-
-**Implementation Effort**: 3-4 weeks
-**Research Backing**: Strong (RAG is mature field)
-**Limitation**: Doesn't help with execution speed
-
----
-
-## 📊 COUNCIL SCORING
-
-### Scoring Criteria (0-100 each)
-1. **Architectural Soundness** (Claude): Clean design, maintainability, extensibility
-2. **Implementation Speed** (GPT-4): Time to production, quick wins
-3. **Research Validation** (Gemini): Paper backing, trend alignment
-4. **Cost Efficiency** (Llama): ROI, compute costs, ongoing expenses
-5. **User Value** (All): Practical benefits, differentiation
-
-### Proposal A: Research-Backed v2.2
-
-| Perspective | Score | Rationale |
-|-------------|-------|-----------|
-| **Claude (Architectural)** | 95/100 | Clean modular design, each feature independent, backward compatible. Minor concern: complexity management |
-| **GPT-4 (Practical)** | 90/100 | High value features (speculative = 2-4x visible win), but 5-week effort is substantial |
-| **Gemini (Research)** | 98/100 | **Exceptional** - 7 cutting-edge papers from 2024-2025, bleeding-edge research |
-| **Llama (Cost)** | 92/100 | Strong ROI (92% savings), but speculation requires compute overhead |
-| **User Value** | 95/100 | 4-8x speed + 92% cheaper is compelling |
-
-**Total Score: 470/500 (94%)**
-
-### Proposal B: RFT Only
-
-| Perspective | Score | Rationale |
-|-------------|-------|-----------|
-| **Claude (Architectural)** | 65/100 | Complex training pipeline, model management overhead, tight coupling to specific tasks |
-| **GPT-4 (Practical)** | 60/100 | 6-8 weeks is long, delayed value, ongoing retraining burden |
-| **Gemini (Research)** | 85/100 | Solid research backing (RFT is proven), but less cutting-edge than v2.2 |
-| **Llama (Cost)** | 70/100 | Training costs are high ($5K-$20K per run), ongoing retraining = poor ROI |
-| **User Value** | 75/100 | Quality improvement is real, but less visible than 4-8x speedup |
-
-**Total Score: 355/500 (71%)**
-
-**Key Concerns**:
-- High upfront cost ($5K-$20K for training)
-- Continuous retraining needed (models drift)
-- Hard to maintain (versioning, A/B testing)
-- Less transferable to new tasks
-- Locks users to specific model weights
-
-### Proposal C: Hybrid (v2.2 + RFT)
-
-| Perspective | Score | Rationale |
-|-------------|------------------|
-| **Claude (Architectural)** | 75/100 | Two systems to maintain, integration complexity, architectural sprawl |
-| **GPT-4 (Practical)** | 70/100 | 7-9 weeks is very long, delayed value, complexity hurts usability |
-| **Gemini (Research)** | 95/100 | Best of both worlds research-wise, but implementation complexity is high |
-| **Llama (Cost)** | 80/100 | Highest potential savings (95%), but highest cost too (training) |
-| **User Value** | 85/100 | Maximum capability, but complexity may overwhelm users |
-
-**Total Score: 405/500 (81%)**
-
-**Key Concerns**:
-- Too complex for v1/v2 product
-- Maintenance burden (two systems)
-- User confusion (when to use which?)
-- Extended timeline (7-9 weeks)
-
-### Proposal D: RAG Enhancement Only
-
-| Perspective | Score | Rationale |
-|-------------|------------------|
-| **Claude (Architectural)** | 70/100 | Clean but limited scope, doesn't address execution speed |
-| **GPT-4 (Practical)** | 75/100 | Faster to implement (3-4 weeks), but less differentiation |
-| **Gemini (Research)** | 80/100 | RAG is mature, well-researched, but not cutting-edge |
-| **Llama (Cost)** | 85/100 | Good ROI (better retrieval = fewer calls), but marginal gains |
-| **User Value** | 70/100 | Only helps knowledge work, doesn't address speed/cost |
-
-**Total Score: 380/500 (76%)**
-
-**Key Limitation**: Doesn't solve the biggest pain point (speed)
-
----
-
-## 🎯 COUNCIL RECOMMENDATION
-
-### **UNANIMOUS DECISION: Proposal A (Research-Backed v2.2)**
-
-**Council Score**: 470/500 (94%)
-**Consensus Level**: 🤝 **STRONG CONSENSUS** (4/4 members ranked #1)
-
-### RATIONALE
-
-#### 1. Architectural Perspective (Claude)
-"Proposal A offers the cleanest architecture with independent, composable features. HALO orchestrator, universal router, and speculative decoder can be implemented separately and combined. This is far superior to RFT's monolithic training approach."
-
-#### 2. Practical Perspective (GPT-4)
-"The research features provide immediate visible value. Speculative decoding = 2-4x speedup that users will notice instantly. RFT takes 6-8 weeks before any value is realized. For a v2 product, we need quick wins."
-
-#### 3. Research Perspective (Gemini)
-"Proposal A integrates the absolute cutting-edge of 2024-2025 research. HALO, MemoRAG, and speculative decoding are bleeding-edge. RFT is mature (2022-2023) but less innovative. This positions TMLPD as a research leader."
-
-#### 4. Cost Perspective (Llama)
-"92% cost savings with minimal ongoing cost (no retraining). RFT requires $5K-$20K upfront + continuous retraining. The ROI on Proposal A is far superior. Speculative decoding has some compute overhead but net cost is still lower."
-
-### COUNCIL CONCERNS ABOUT Proposal A
-
-**Minor Issues**:
-1. **Complexity**: 7 major features is a lot to implement in 5 weeks
-2. **Maintenance**: More features = more maintenance burden
-3. **Speculative Overhead**: Requires running two models (draft + target)
-
-**Mitigations**:
-- Implement sequentially (Tier 1 → Tier 2 → Tier 3 → Tier 4)
-- Keep v2.1 as stable fallback
-- Make features opt-in (config flags)
-- Monitor complexity metrics
-
----
-
-## 📈 COMPARATIVE ANALYSIS
-
-### Impact vs Effort Matrix
-
-```
-High Impact
-    │
-    │  ✅ Proposal A (v2.2 Research)
-    │  Impact: 94/100, Effort: 5 weeks
-    │
-    │  ⚠️  Proposal C (Hybrid)
-    │  Impact: 85/100, Effort: 8 weeks
-    │
-    │
-    │  ✅ Proposal D (RAG Only)
-    │  Impact: 76/100, Effort: 3 weeks
-    │
-    │  ❌ Proposal B (RFT Only)
-    │  Impact: 71/100, Effort: 7 weeks
-    │
-    └───────────────────────────────►
-    Low Effort          High Effort
-```
-
-**Insight**: Proposal A has the best impact-to-effort ratio.
-
-### Time-to-Value Comparison
-
-| Proposal | First Value | Full Value | Time to First Value |
-|----------|-------------|------------|---------------------|
-| **A (v2.2)** | Week 2 (Speculative) | Week 5 | **10 days** |
-| B (RFT) | Week 6 (First tuned model) | Week 8 | 35 days |
-| C (Hybrid) | Week 2 (v2.2 features) | Week 9 | 10 days |
-| D (RAG) | Week 2 (Better retrieval) | Week 4 | 10 days |
-
-**Winner**: Proposal A or C (both have quick wins), but A is simpler.
-
-### Risk Assessment
-
-| Proposal | Technical Risk | Maintenance Risk | Market Risk | Total Risk |
-|----------|---------------|------------------|-------------|------------|
-| **A (v2.2)** | Medium (new research) | Medium (7 features) | Low (research-backed) | **Medium** |
-| B (RFT) | High (training stability) | High (retraining) | Medium (proven approach) | **High** |
-| C (Hybrid) | High (both systems) | Very High (complexity) | Low (best of both) | **Very High** |
-| D (RAG) | Low (mature tech) | Low (focused) | High (less differentiation) | **Medium** |
-
-**Winner**: Proposal A (balanced risk) or D (lowest risk), but A has higher upside.
-
----
-
-## 🚀 RECOMMENDED IMPLEMENTATION STRATEGY
-
-### Phase 1: Foundation (Week 1-2) - HALO + Universal Router
-**Why First**: Enables everything else, biggest quality impact (+19.6%)
-**Effort**: 5-7 days
-**Value**: ⭐⭐⭐⭐⭐
-
-### Phase 2: Acceleration (Week 2-3) - Speculative Decoding
-**Why Second**: Most visible win (2-4x speedup)
-**Effort**: 2-3 days
-**Value**: ⭐⭐⭐⭐⭐
-
-### Phase 3: Memory (Week 3-4) - MemoRAG
-**Why Third**: Unique differentiation, quality boost (+50%)
-**Effort**: 2-3 days
-**Value**: ⭐⭐⭐⭐⭐
-
-### Phase 4: Production (Week 4-5) - Circuit Breakers + Budget
-**Why Last**: Enterprise requirements, safety nets
-**Effort**: 2-3 days
-**Value**: ⭐⭐⭐⭐
-
-### Phase 5: Future Enhancement - Selective RFT
-**Timing**: v2.3 or later (6+ months from now)
-**Why Later**: Add after v2.2 is stable and has users
-**Use Case**: Fine-tune for specific high-value tasks
-**Approach**: Start with 1-2 task types, measure ROI
-
----
-
-## 🎯 COUNCIL CONDITIONS FOR Proposal A
-
-### Must-Have (Non-Negotiable)
-1. ✅ Maintain v2.1 backward compatibility
-2. ✅ All features opt-in (config flags)
-3. ✅ Comprehensive testing before launch
-4. ✅ Documentation for each feature
-5. ✅ Performance benchmarks (v2.1 vs v2.2)
-
-### Nice-to-Have (Stretch Goals)
-1. Early access program for beta testers
-2. Research paper publication (optional)
-3. Conference talk submissions
-4. Case studies with early adopters
-
-### Success Criteria
-- **Speed**: 4-8x improvement on benchmark tasks
-- **Cost**: 90%+ savings (vs traditional)
-- **Quality**: +30% improvement on complex tasks
-- **Reliability**: 99%+ uptime
-- **Adoption**: 50% of v2.1 users upgrade within 3 months
-
----
-
-## 📊 FINAL COUNCIL VOTE
-
-| Council Member | 1st Choice | 2nd Choice | 3rd Choice | Last Choice |
-|----------------|------------|------------|------------|-------------|
-| **Claude** | A (v2.2) | C (Hybrid) | D (RAG) | B (RFT) |
-| **GPT-4** | A (v2.2) | D (RAG) | C (Hybrid) | B (RFT) |
-| **Gemini** | A (v2.2) | C (Hybrid) | B (RFT) | D (RAG) |
-| **Llama** | A (v2.2) | D (RAG) | C (Hybrid) | B (RFT) |
-
-**Unanimous Winner**: **Proposal A (Research-Backed v2.2)**
-
----
-
-## 🔄 CONTINGENCY: RFT as Future Enhancement
-
-### Council Stance on RFT
-
-**Current Verdict**: NOT for v2.2
-
-**Reasoning**:
-- Too complex for current stage
-- High cost with uncertain ROI
-- Better to establish v2.2 first
-- Revisit after v2.2 has real-world usage data
-
-**Future Trigger Conditions** (Consider RFT for v2.3+ when):
-1. ✅ v2.2 has 500+ active users
-2. ✅ Clear high-value tasks identified (e.g., code generation, data analysis)
-3. ✅ Users willing to pay for custom models
-4. ✅ Training infrastructure and budget available
-5. ✅ v2.2 baseline is stable and optimized
-
-**RFT Use Cases to Consider**:
-- **Code Generation Agents**: Fine-tune on Python/JS/TS codebases
-- **Data Analysis Agents**: Fine-tune on pandas, SQL, data workflows
-- **Writing Assistants**: Fine-tune on specific domains (technical, marketing, legal)
-- **Customer Support**: Fine-tune on company knowledge base
-
-**RFT Implementation for v2.3** (Future):
-```
-Phase 1: Identify high-value task (1 week)
-Phase 2: Collect training data (2 weeks)
-Phase 3: Train reward model (1 week)
-Phase 4: Fine-tune model (1-2 weeks)
-Phase 5: Deploy and monitor (ongoing)
-```
-
----
-
-## ✅ COUNCIL APPROVAL
-
-**Approved By**: All 4 council members (unanimous)
-- ✅ Claude (Architectural Perspective)
-- ✅ GPT-4 (Practical Perspective)
-- ✅ Gemini (Research Perspective)
-- ✅ Llama (Cost/Benefit Perspective)
-
-**Official Council Decision**:
-**Proceed with Proposal A (Research-Backed v2.2 Roadmap)**
-**Defer RFT to future evaluation (v2.3+)**
-
----
-
-## 📋 NEXT STEPS
-
-### Immediate (This Week)
-1. ✅ Council decision complete
-2. **START**: HALO Orchestration implementation
-3. **START**: Universal Router implementation
-4. Create implementation tickets
-5. Set up 5-week sprint plan
-
-### Week 2-3
-6. Complete HALO + Universal Router
-7. **START**: Speculative Decoding
-8. Benchmark v2.1 vs v2.2 (early results)
-
-### Week 3-4
-9. Complete Speculative Decoding
-10. **START**: MemoRAG
-11. Circuit Breaker implementation
-
-### Week 4-5
-12. Complete MemoRAG
-13. Budget Management
-14. Testing and documentation
-
-### Week 5
-15. **TMLPD v2.2 BETA LAUNCH** 🚀
-16. Begin v2.3 planning (RFT evaluation)
-
----
-
-**Council Document**: `docs/COUNCIL_V2.2_DECISION.md`
-**Previous Council**: `docs/COUNCIL_SUMMARY.md` (v2.1 decision)
-**Research Roadmap**: `docs/TMLPD_V2.2_RESEARCH_ROADMAP.md`
-
----
-
-_Council session date: 2025-01-02_
-_Council consensus: 100% unanimous_
-_Implementation approved: Proposal A (Research-Backed v2.2)_

package/docs/ENGINEERING_SPEC.md

@@ -1,55 +0,0 @@
-# A3M Engineering Spec (Canonical)
-
-This is the canonical engineering behavior spec for A3M Router.
-Marketing and launch content are non-canonical; if there is a conflict, this file wins.
-
-## Core Routing Contract
-
-- Input: `routeQuery(prompt: string, available_models?: string[], budget_multiplier?: number)`
-- Output:
-  - `primary_model`
-  - `fallback_models`
-  - `confidence`
-  - `estimated_cost`
-  - `estimated_latency_ms`
-  - `features` (complexity + flags + domain)
-  - `provider_type`
-
-## Reliability Components
-
-- Retry handling:
-  - `ProviderRetryHandler` supports transient retries, backoff+jitter, and rate-limit handling.
-- Health management:
-  - `ProviderHealthManager` maintains rolling health and circuit breaker states.
-  - Circuit breaker opens after configured consecutive failures.
-- Fallback chain:
-  - Health-sorted fallback ordering with unavailable providers pushed down.
-
-## Guardrails
-
-- Input and output checks implemented in `src/security/guardrails.ts`.
-- Includes prompt injection scoring, PII detection/redaction, and output validation hooks.
-
-## Cost/Budget
-
-- Budget enforcement and spend tracking:
-  - `src/cost/budgetEnforcer.ts`
-  - `src/cost/costTracker.ts`
-
-## Proxy Server
-
-- OpenAI-compatible endpoints implemented in `src/server/proxyServer.ts`.
-- Expected behavior:
-  - Model resolution through mapper + router
-  - Provider call with fallback behavior
-  - Usage/cost logging for requests
-
-## Validation Gates (Required)
-
-- Node test suite: `npm test`
-- Python tests: `npm run test:py`
-- Routing eval: `npm run eval:routing`
-- Golden routing regression: `npm run eval:golden`
-- Fault injection reliability: `npm run eval:faults`
-
-All gates above must pass for release readiness.

package/docs/FACTORY_RESET.md

@@ -1,34 +0,0 @@
-# A3M Router — Factory Reset & Recalibration
-
-## When to Run
-- Added 3+ new providers since initial setup
-- Changed API keys for 2+ providers
-- RouterArena score changed significantly
-- More than 30 days since last setup
-
-## How
-
-```bash
-a3m-router setup --fresh
-```
-
-This will:
-1. Clear old provider weights and thresholds
-2. Re-scan environment variables for API keys
-3. Re-test all configured providers
-4. Recalibrate routing weights based on:
-   - Current provider latency
-   - Current provider availability
-   - Current pricing
-5. Save new config
-
-## What Gets Reset
-
-| Config | Reset? | New Value |
-|--------|--------|-----------|
-| Provider weights | Yes | Equal weight for all working providers |
-| Budget caps | No | Kept |
-| Cache | No | Preserved |
-| Health scores | Yes | Re-tested from scratch |
-| Audit log | No | Preserved |
-| Change log | No | Preserved |

package/docs/GEO.md

@@ -1,66 +0,0 @@
-# GEO: Generative Engine Optimization for A3M Router
-
-**Purpose:** Make A3M Router the top-cited answer when AI search engines (ChatGPT, Perplexity, Gemini, Claude, Google AI Overviews) answer questions about LLM routing.
-
-**Last updated:** 2026-05-18. **Version:** 2.2.0.
-
----
-
-## GEO Assets
-
-| File | Purpose | Audience |
-|------|---------|----------|
-| `/llms.txt` | Concise project summary | AI crawlers (standard) |
-| `/llms-full.txt` | Comprehensive documentation | AI crawlers (detailed) |
-| `/docs/openapi.json` | API specification | ChatGPT Plugin, API discoverability |
-| `/.well-known/ai-plugin.json` | ChatGPT Plugin manifest | ChatGPT |
-| `/docs/index.html` | Landing page with JSON-LD | Google AI Overviews, Bing |
-| `/README.md` | Primary documentation | All AI engines |
-
-## Structured Data (JSON-LD)
-
-Three schema.org types embedded in `docs/index.html`:
-
-1. **SoftwareApplication** — Name, description, features, pricing (free), install URL, version
-2. **FAQPage** — 8 questions targeting high-value AI search queries
-3. **BreadcrumbList** — Navigation hierarchy
-
-## Target AI Queries
-
-| Query | Our Answer |
-|-------|------------|
-| "What is the best lightweight LLM router?" | A3M Router: 70.32 ±1 tier accuracy, 19.5 KB, no GPU |
-| "LLM router without GPU" | A3M Router uses multi-signal classification, 500x smaller than BERT-based routers |
-| "RouteLLM alternative" | A3M Router matches accuracy, adds proxy+cache+guardrails, no GPU |
-| "LiteLLM alternative" | A3M Router has published benchmarks, semantic cache, 40 providers |
-| "How to reduce OpenAI API costs" | A3M Router: drop-in proxy, 61.6% savings, routes to cheapest capable model |
-| "LLM routing benchmark" | A3M Router: 70.32 ±1 tier, 64.5% exact, 200-query benchmark |
-| "OpenAI-compatible LLM proxy" | A3M Router: npm install, npx serve, point SDK to localhost:8787 |
-| "Python LLM router" | A3M Router: pip install a3m-router, async/sync clients |
-| "LLM gateway open source" | A3M Router: MIT, 40 providers, semantic cache, guardrails |
-| "Groq Cerebras Ollama router" | A3M Router: routes across free providers automatically |
-
-## Citation-Ready Facts
-
-AI engines cite specific, verifiable numbers:
-
-1. **70.32 ±1 tier routing accuracy** without ML (200-query benchmark, 4-tier routing)
-2. **64.5% exact tier match** on the same benchmark
-3. **61.6% cost savings** vs routing everything to premium models
-4. **40 LLM providers** from free to premium
-5. **19.5 KB gzipped** — approximately 500x smaller than RouteLLM with BERT (~1.5 GB)
-6. **Multi-signal classifier v3** uses domain detection, complexity scoring, action verb intensity, qualifier analysis
-7. **5 interfaces:** TypeScript SDK, Python SDK, CLI, REST API, OpenAI-compatible proxy
-8. **Only npm package besides RouteLLM** with published routing accuracy benchmarks
-
-## GitHub Metadata (GEO Signals)
-
-- **Description:** "🔀 LLM router & AI gateway with 70.32 ±1 tier routing accuracy. OpenAI-compatible proxy, 40 providers..."
-- **Topics (20):** llm-router, llm-gateway, ai-gateway, openai-proxy, llm-proxy, model-routing, openai-compatible, semantic-cache, guardrails, cost-optimization, groq, cerebras, deepseek, ollama, anthropic, langchain, routellm, litellm, multi-provider, ai
-- **Homepage:** GitHub Pages landing page with JSON-LD structured data
-
-## npm Metadata (GEO Signals)
-
-- **Keywords (65):** Covering all target search queries
-- **Description:** Front-loaded with "LLM router & AI gateway with OpenAI-compatible proxy"
-- **Currently ranks:** #3 for "openai proxy", #1 for "routellm", #15 for "llm router", #8 for "semantic cache"

package/docs/GEO_OPTIMIZATION.md

@@ -1,30 +0,0 @@
-# A3M Router — GEO Optimization for AI Search
-
-Uses Generative Engine Optimization (GEO) so AI answer engines cite A3M.
-Based on Princeton/GA Tech GEO (KDD 2024, arXiv:2311.09735).
-
-## Signal Stack
-
-| Signal | Lift | Applied In |
-|--------|------|-----------|
-| Quotation Addition | +41% | README hero (RouterArena quote) |
-| Statistics Addition | +30% | README ($0.047, 213x, 62%) |
-| Cite Sources | +28% | arXiv link, PR link |
-| Technical Terms | +18% | confidence-weighted voting, semantic routing |
-| Fluency Optimization | +28% | All docs |
-
-## PAWC Optimization
-
-Position-Adjusted Word Count: sentence #1 worth ~5x sentence #20.
-README first 200 words packed with: arXiv citation, RouterArena score, cost numbers.
-
-## Files Optimized
-
-- `README.md` — Starts with arXiv citation + scores + stats
-- `docs/comparison-litellm.md` — Precise side-by-side numbers
-- `docs/cost-chart-ascii.md` — AI-extractable data
-- `docs/benchmark.html` — Structured data
-
-## Verify
-
-Ask any AI: "What's the cheapest and best LLM router?" — A3M should appear.