Architecture: How should LLM model IDs, pricing, and capabilities be manag...

Documentation for Sessions

🏗️ Architecture: How should LLM model IDs, pricing, and capabilities be manag...

Date: 2026-03-09
Time: 19:37:10 UTC
Session: gspace1-191.2
Agent: angular
Confidence: 95%
Status: ✅ Documented


📋 Decision Context

Question:

How should LLM model IDs, pricing, and capabilities be managed across 4 backends and 2 frontends?

Task: Not specified


🎯 Decision Made

Chosen:

Single source of truth in ai-models.config.ts with AI_MODELS_CONFIG, AI_MODEL_PRICING, and AI_MODEL_CAPABILITIES. All 6 consumer files import from this central config instead of hardcoding model IDs.

Options Considered:

  1. Keep hardcoded lists and manually sync on model changes
  2. Create a runtime API endpoint that serves model config
  3. Use env vars for every model ID
  4. Single config file imported everywhere (chosen)

💭 Reasoning

Root cause: 6 files hardcoded model IDs independently. When claude-3-5-haiku-20241022 was deprecated, only some files were updated, causing SmartRouter to send requests to a 404 model. The central config (ai-models.config.ts) already existed but wasn't imported by most consumers. Fix: added AI_MODEL_CAPABILITIES to the config, re-exported via @libs-foundational/api-config for frontend access, and updated all 6 consumers (provider-factory, smart-router, cost-tracker x2, chat-model, chat-cost) to derive their data from it. Now a model change requires editing one file.


📁 Files Involved


🔗 Related


Auto-generated by MCP Smart Consolidation