Architecture: How should LLM model configuration be centralized across a m...

Documentation for Sessions

🏗️ Architecture: How should LLM model configuration be centralized across a m...

Date: 2026-03-13
Time: 02:01:54 UTC
Session: gspace1-212.2
Agent: backend
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

How should LLM model configuration be centralized across a monorepo with 3 backends, 1 MCP server, and multiple frontend libs?

Task: S212: LLM Model Routing and Cost Optimization

🎯 Decision Made

Chosen:

Single source of truth in @libs-api/backend-core with a manually-synced frontend copy in @libs-foundational/api-config. Backend-api's shadow config replaced with re-exports. All ~30 consumer files wired to import from central config instead of hardcoding model strings.

Options Considered:

  1. Single config in backend-core with manual frontend sync
  2. Shared config in a new dependency-free NX lib
  3. Auto-generated frontend copy via build pipeline
  4. Environment variables for all model IDs

💭 Reasoning

Root cause: 4 separate model registries existed (backend-core, api-config frontend copy, backend-api shadow config, gograb-ai-lib extended catalog) plus ~15 hardcoded model strings. This caused: (1) broken model ID 'claude-opus-4-5' in module-files.service.ts causing runtime errors, (2) stale defaults serving Sonnet 4.0 instead of 4.6, (3) pricing tables in llm-integration providers disagreeing with central config, (4) backend-api agents using ancient claude-3-7-sonnet. Solution: NX lib @libs-api/backend-core is the canonical config. Frontend can't import it (NestJS deps), so a manual copy exists. Alternative considered: auto-generating the frontend copy via build script — rejected as over-engineering for 2 files that change quarterly. The re-export pattern for backend-api eliminates the shadow config without breaking import paths.

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation