body:
# Comprehensive Documentation Site Overhaul

## 🎯 Objective
Transform OmniRoute's scattered documentation into a comprehensive, structured documentation site with interactive features, advanced search, and professional organization inspired by industry best practices.

## 📋 Problem Statement
Current documentation system limitations:
- **Scattered Organization**: Markdown files spread across repository with limited navigation
- **No Dedicated Site**: Lack of professional documentation portal
- **Limited Discoverability**: Poor search and feature discovery
- **Static Content**: No interactive elements or API testing
- **Inconsistent Quality**: Varied formatting and structure

## ✨ Proposed Solution

### New Documentation Structure

### Key Features
- **Interactive API Documentation**: Swagger/OpenAPI with try-it-now functionality
- **Advanced Search**: Algolia/DocSearch with autocomplete and filtering
- **Versioned Content**: Clear version tags and migration guides
- **Code Examples**: Runnable examples with copy-to-clipboard
- **Visual Aids**: Interactive Mermaid diagrams and architecture visualizations
- **Responsive Design**: Mobile-friendly with dark mode support
- **Analytics**: Usage tracking and feedback system

### Technology Stack
- **Framework**: Next.js (consistent with OmniRoute dashboard)
- **Content**: MDX (Markdown + React components)
- **Styling**: Tailwind CSS (matches OmniRoute UI)
- **Search**: Algolia DocSearch or Fuse.js
- **Deployment**: Vercel with preview deployments

## 📈 Expected Benefits
- **50% increase** in documentation page views
- **30% reduction** in support requests for basic questions
- **40% increase** in time spent on documentation pages
- **90% positive** feedback on documentation quality
- **25% increase** in community contributions

## 🔧 Implementation Plan

### Phase 1: Foundation (2 weeks)
- Set up Next.js documentation framework
- Design component library with OmniRoute theme
- Implement MDX processing pipeline
- Set up CI/CD pipeline with preview deployments

### Phase 2: Content Migration (4 weeks)
- Audit and categorize existing documentation
- Create automated migration tools
- Migrate core content with quality validation
- Implement redirects from old URLs

### Phase 3: Advanced Features (3 weeks)
- Implement search functionality with Algolia
- Add interactive API documentation
- Create versioning system
- Implement analytics and feedback

### Phase 4: Testing & Launch (2 weeks)
- Comprehensive testing (unit, integration, E2E)
- Performance optimization
- Accessibility validation
- Final review and official launch

## 📊 Success Metrics
- All content successfully migrated and validated
- Search functionality achieves ≥90% relevance in test queries
- Accessibility compliance (WCAG 2.1 AA) verified
- Performance metrics meet targets (Lighthouse ≥90)
- 50% increase in documentation engagement

## 🎯 Definition of Done
- Complete content migration with validation
- All interactive features fully functional
- Search system operational with ≥90% relevance
- Accessibility compliance verified
- Performance targets achieved
- Analytics and feedback system implemented
- Comprehensive documentation completed

## 📝 Additional Context
This overhaul will create a professional documentation portal that improves user onboarding, feature discovery, and overall satisfaction while maintaining consistency with OmniRoute's brand and technical stack. The new site will serve as the primary resource for users, developers, and contributors.

title: feat: Comprehensive Documentation Site Overhaul


body:
# Manifest Routing Integration - Tier Resolution & Specificity Detection

## 🎯 Objective
Enhance OmniRoute's combo routing system by integrating Manifest's sophisticated tier resolution and specificity detection logic to create a more intelligent, context-aware routing engine that optimizes for both performance and cost.

## 📋 Problem Statement
The current combo routing system, while functional with 13 strategies, lacks:
- **Tier Resolution**: Provider classification based on performance, cost, and capabilities
- **Specificity Detection**: Content complexity analysis for optimal route selection
- **Adaptive Strategies**: Dynamic adjustment based on real-time metrics and query requirements

## ✨ Proposed Solution

### Core Components
1. **Tier Resolution System**
   - 3-level classification: static rules → heuristics → specificity-based
   - Dynamic tier assignment based on real-time provider metrics
   - Integration with existing provider health monitoring

2. **Specificity Detection**
   - Query complexity scoring (0-100 scale)
   - Content-type analysis for optimal provider matching
   - Historical performance data integration

3. **Adaptive Combo Strategies**
   - New auto-optimized strategy with dynamic adjustment
   - Tier-aware fallback logic
   - Cost-performance balancing algorithms

### Integration Points
- **PR #1918 Auto-Assessment**: Leverage existing health monitoring and performance data
- **Existing Combo System**: Maintain backward compatibility with current strategies
- **Metrics Pipeline**: Feed routing decisions into analytics for continuous improvement

## 📈 Expected Benefits
- **15-25%** improvement in routing success rates for complex queries
- **10-20%** reduction in API costs through optimal provider utilization
- **30% faster** routing decisions via optimized tier selection
- **Enhanced reliability** with smarter, context-aware fallback logic

## 🔧 Implementation Plan

### Phase 1: Foundation (2-3 weeks)
- Research Manifest's tier resolution algorithms
- Design system architecture with integration points
- Implement basic tier classification framework
- Set up test infrastructure and benchmarks

### Phase 2: Core Implementation (4-5 weeks)
- Implement 3-tier resolution system (static/heuristic/specificity)
- Develop specificity scoring algorithm
- Create adaptive combo strategies
- Integrate with PR #1918 auto-assessment system

### Phase 3: Optimization & Testing (3 weeks)
- Performance tuning and benchmarking
- Comprehensive test suite (unit, integration, e2e)
- Documentation and examples
- Gradual rollout and monitoring

## 📊 Success Metrics
- Routing success rate improvement (A/B testing)
- Cost reduction verified through usage analytics
- Performance benchmarks showing latency improvements
- User satisfaction surveys on routing reliability

## 🔍 Related Work
- PR #1918: Auto-Assessment and Self-Healing Combo Engine
- Manifest routing engine analysis
- Current combo strategies documentation

## 🎯 Definition of Done
- Tier resolution achieves ≥95% accuracy in classification
- Specificity detection shows ≥90% correlation with manual scoring
- Adaptive strategies demonstrate ≥15% improvement in benchmarks
- Integration with auto-assessment system verified
- All performance benchmarks meet targets
- Comprehensive documentation completed

## 📝 Additional Context
This enhancement builds upon PR #1918's auto-assessment capabilities, adding intelligent tier-based routing and query-specific optimization to create a sophisticated, cost-effective routing system that maintains OmniRoute's commitment to performance and reliability.

title: feat: Manifest Routing Integration - Tier Resolution & Specificity Detection


login: akatylutir

body:
### OmniRoute Version

3.7.8

### Installation Method

npm (global)

### Operating System

Windows

### OS Version

windows 11 pro, 24H2

### Node.js Version

v22.22.2

### Provider(s) Involved

_No response_

### Model(s) Involved

_No response_

### Client Tool

_No response_

### Description

Hi! I want to use OmniRoute, but red button not working. What can I do? Thi is log: https://pastebin.com/jKcS8CSy , and this is video: https://youtu.be/DB40dkfnGf4

### Steps to Reproduce

Hi! I want to use OmniRoute, but red button not working. What can I do? Thi is log: https://pastebin.com/jKcS8CSy , and this is video: https://youtu.be/DB40dkfnGf4

### Expected Behavior

Hi! I want to use OmniRoute, but red button not working. What can I do? Thi is log: https://pastebin.com/jKcS8CSy , and this is video: https://youtu.be/DB40dkfnGf4

### Actual Behavior

Hi! I want to use OmniRoute, but red button not working. What can I do? Thi is log: https://pastebin.com/jKcS8CSy , and this is video: https://youtu.be/DB40dkfnGf4

### Test Impact

Needs a new unit test

### Error Logs / Output

```shell
Hi! I want to use OmniRoute, but red button not working. What can I do? Thi is log: https://pastebin.com/jKcS8CSy , and this is video: https://youtu.be/DB40dkfnGf4
```

### Screenshots

Hi! I want to use OmniRoute, but red button not working. What can I do? Thi is log: https://pastebin.com/jKcS8CSy , and this is video: https://youtu.be/DB40dkfnGf4

### Additional Context

Hi! I want to use OmniRoute, but red button not working. What can I do? Thi is log: https://pastebin.com/jKcS8CSy , and this is video: https://youtu.be/DB40dkfnGf4

### Validation Plan

Hi! I want to use OmniRoute, but red button not working. What can I do? Thi is log: https://pastebin.com/jKcS8CSy , and this is video: https://youtu.be/DB40dkfnGf4

login: kilo-code-bot

body:
This issue appears to be a duplicate of https://github.com/diegosouzapw/OmniRoute/issues/1883.

> **\[BUG\] Onboarding button unresponsive after upgrade from 2.x to 3.x — CSP blocks eval** (#1883)

Similarity score: 90%

*This comment was generated by Kilo Auto-Triage.*

body: I solved the problem, install version 3.7.5

bug

description: Something isn't working

kilo-triaged

description: Auto-generated label by Kilo

kilo-duplicate

description: Auto-generated label by Kilo

title: [BUG] Button Start Onboarding not working


body:
### OmniRoute Version

3.7.8

### Installation Method

npm (global)

### Operating System

Windows

### OS Version

windows 10

### Node.js Version

v24.15.0

### Provider(s) Involved

all

### Model(s) Involved

all

### Client Tool

all

### Description

I launched omniroute in cmd, the website opens, but the button doesn't work. I tried changing ports, but that didn't help. I also tried using AI, but that didn't help either.

### Steps to Reproduce

a

### Expected Behavior

a

### Actual Behavior

a

### Test Impact

Needs a new unit test

### Error Logs / Output

```shell
a
```

### Screenshots

### Additional Context

a

### Validation Plan

a

body:
This issue appears to be a duplicate of https://github.com/diegosouzapw/OmniRoute/issues/1703.

> **\[BUG\]** (#1703)

Similarity score: 93%

*This comment was generated by Kilo Auto-Triage.*

body: node 22.22.2 not work

bug

description: Something isn't working

kilo-triaged

description: Auto-generated label by Kilo

description: Auto-generated label by Kilo

title: [BUG]


cloudy

login: uwuclxdy

body:
### Problem / Use Case

OmniRoute currently tries all accounts from lets say Codex provider, even though some of them have no more usage available.

### Proposed Solution

Make the already existing buttons "track 5-hour quota" and "track weekly quota" on `/dashboard/providers/codex` page would make OmniRoute check the quota of the account before attempting to send a query and skip it if on 0%. This could work for other providers like Claude Code in the same way.

### Alternatives Considered

_No response_

### Acceptance Criteria

Have accounts without any usage left skipped automatically when quota tracking is turned on.

### Area

Proxy / Routing

### Related Provider(s)

Codex, Claude Code...

### Additional Context

_No response_

### Expected Test Plan

_No response_

enhancement

description: New feature or request

title: [Feature] Skip (Codex) accounts that have the weekly or 5h quota exhausted


body:
### Problem / Use Case

Could please show how much quota on model like:
- Sesssion: x/y request remain
- Weekly: x/y request remain

### Proposed Solution

No

### Alternatives Considered

_No response_

### Acceptance Criteria

no

### Area

Analytics / Usage Tracking

### Related Provider(s)

_No response_

### Additional Context

_No response_

### Expected Test Plan

_No response_

description: New feature or request

title: [Feature] Show more detail about quota


body:
### Problem / Use Case

OmniRoute supports a very large provider ecosystem, but Devin AI is not currently available as a built-in provider.

This matters because Devin is a strong coding-focused agent for longer-running engineering tasks, and OmniRoute already positions itself as a universal gateway for coding agents and model providers. Right now, users who want to evaluate or route work to Devin cannot do that from the same OmniRoute endpoint or include Devin in combos/fallback chains.

## Why the current custom-provider path is not enough

As far as I understand, OmniRoute's generic custom provider support is for OpenAI-compatible and Anthropic-compatible endpoints.

Devin does expose an official API, but it is session-based and organization-scoped rather than a drop-in `/chat/completions`-compatible endpoint. Because of that, Devin likely needs a first-class provider adapter instead of a generic custom endpoint configuration.

## Use cases

- Route repo-level coding, debugging, and refactor tasks to Devin from the same OmniRoute setup used for Codex, Claude Code, Gemini CLI, etc.
- Use Devin as a higher-latency but higher-capability fallback for complex implementation tasks.
- Compare Devin against other coding-oriented providers inside the same OmniRoute combo/routing policy.
- Evaluate Devin inside OmniRoute without reconfiguring clients every time.

### Proposed Solution

## Proposed solution

Add Devin as a built-in provider with a custom executor.

High-level implementation sketch:

1. Register a new `devin` provider in `src/shared/constants/providers.ts`.
2. Add Devin provider/model metadata in `open-sse/config/providerRegistry.ts`.
3. Implement a custom executor in `open-sse/executors/` that:
   - authenticates with Devin service-user credentials
   - targets the organization API under `https://api.devin.ai/v3/organizations/{org_id}`
   - creates a new Devin session for a fresh OmniRoute request
   - sends follow-up messages to an existing Devin session when conversation continuity is available
   - polls session state and/or session messages until a stable assistant result is available
   - maps the final Devin output back into OmniRoute's OpenAI-compatible response shape
4. Add dashboard/provider settings for:
   - `DEVIN_API_KEY` (service-user credential)
   - `DEVIN_ORG_ID`
   - optional defaults such as session tags, repo selection, or ACU limits
5. Make the provider eligible for direct selection and combo routing.

### Alternatives Considered

_No response_

### Acceptance Criteria

## Acceptance criteria

- Devin appears in the Providers UI as a connectable provider.
- A user can store Devin credentials and validate the connection.
- OmniRoute can send a basic text request to Devin and return a usable assistant response through `/v1/chat/completions` and/or `/v1/responses`.
- Follow-up prompts can either reuse a Devin session or the limitation is explicitly documented for MVP behavior.
- Devin can be targeted directly in combos.
- Common Devin session states/errors (for example approval-needed, quota/usage exhaustion, or suspended sessions) are surfaced as clear OmniRoute errors.
- Documentation explains setup, limitations, and expected latency/behavior differences versus normal token-streaming LLM providers.

## Suggested MVP scope

MVP can be text-only and non-streaming/polling-based if needed.

Not required for the first version:
- embeddings
- image/audio endpoints
- tool-calling parity
- full real-time streaming parity with standard LLM providers

### Area

Provider Support

### Related Provider(s)

_No response_

### Additional Context

## Additional context

This would also be useful for users who want to evaluate Devin during onboarding or trial access without changing their entire client setup.

### Expected Test Plan

_No response_

description: New feature or request

title: [Feature] devin.ai


Johannes Rueschel

login: chbndrhnns

body:
### OmniRoute Version

3.7.8

### Installation Method

npm (global)

### Operating System

macOS

### OS Version

26.4.1

### Node.js Version

24.15.0

### Provider(s) Involved

-

### Model(s) Involved

-

### Client Tool

-

### Description

```
❯ pnpm upgrade -g omniroute
Downloading @ngrok/ngrok-darwin-universal@1.7.0: 7.97 MB/7.97 MB, done
Downloading @swc/core-darwin-arm64@1.15.33: 9.16 MB/9.16 MB, done
 WARN  2 deprecated subdependencies found: intersection-observer@0.12.2, prebuild-install@7.1.3
Downloading omniroute@3.7.8: 50.87 MB/50.87 MB, done
Packages: +29 -25
+++++++++++++++++++++++++++++-------------------------
Progress: resolved 988, reused 873, downloaded 27, added 29, done
 WARN  Issues with peer dependencies found
.
└─┬ @lobehub/ui 5.10.0
  └─┬ @emoji-mart/react 1.1.1
    └── ✕ unmet peer react@"^16.8 || ^17 || ^18": found 19.2.5

/Users/jo/Library/pnpm/global/5:
- omniroute 3.7.4
+ omniroute 3.7.8

╭ Warning ──────────────────────────────────────────────────────────────────────────────────────╮
│                                                                                │
│   Ignored build scripts: @swc/core@1.15.33, omniroute@3.7.8.                                  │
│   Run "pnpm approve-builds -g" to pick which dependencies should be allowed to run scripts.   │
│                                                                                │
╰───────────────────────────────────────────────────────────────────────────────────────────────╯
Done in 58.1s using pnpm v10.33.0
❯ pnpm approve-builds -g
✔ Choose which packages to build (Press <space> to select, <a> to toggle all, <i> to invert selection) · @swc/core, omniroute
✔ The next packages will now be built: @swc/core, omniroute.
Do you approve? (y/N) · true
.pnpm/@swc+core@1.15.33_@swc+helpers@0.5.21/node_modules/@swc/core: Running postinstall script, done in 45ms
.pnpm/omniroute@3.7.8_@lobehub+ui@5.10.0_@types+react@19.2.14_antd@6.3.7_react-dom@19.2.5_rea_81be994467029f641d72db51e6e26349/node_modules/omniroute: Running postinstall script...
.pnpm/omniroute@3.7.8_@lobehub+ui@5.10.0_@types+react@19.2.14_antd@6.3.7_react-dom@19.2.5_rea_81be994467029f641d72db51e6e26349/node_modules/omniroute: Running postinstall script, done in 772ms
❯
❯ omniroute

   ____                  _ ____              _
   / __ \\                (_) __ \\            | |
  | |  | |_ __ ___  _ __ _| |__) |___  _   _| |_ ___
  | |  | | '_ ` _ \\| '_ \\ |  _  // _ \\| | | | __/ _ \\
  | |__| | | | | | | | | | | | \\ \\ (_) | |_| | ||  __/
   \\____/|_| |_| |_|_| |_|_|_|  \\_\\___/ \\__,_|\\__\\___|

  ⏳ Starting server...

▲ Next.js 16.2.4
- Local:         http://localhost:20128
- Network:       http://0.0.0.0:20128
✓ Ready in 0ms

  ✔ OmniRoute is running!

    Dashboard:  http://localhost:20128
    API Base:   http://localhost:20128/v1

    Point your CLI tool (Cursor, Cline, Codex) to:
    http://localhost:20128/v1

    Press Ctrl+C to stop

[CREDENTIALS] No external credentials file found, using defaults.
[DB] Could not preserve critical DB state before recreation: Could not locate the bindings file. Tried:
 → /Users/jo/Library/pnpm/global/5/.pnpm/omniroute@3.7.8_@lobehub+ui@5.10.0_@types+react@19.2.14_antd@6.3.7_react-dom@19.2.5_rea_81be994467029f641d72db51e6e26349/node_modules/omniroute/app/node_modules/better-sqlite3/build/better_sqlite3.node
```

### Steps to Reproduce

1. `pnpm upgrade -g omniroute`
2. `pnpm approve-builds -g`
3. `omniroute`

### Expected Behavior

Can upgrade without manual installation procedure

### Actual Behavior

Need to go to /Users/jo/Library/pnpm/global/5/.pnpm/omniroute@3.7.8_@lobehub+ui@5.10.0_@types+react@19.2.14_antd@6.3.7_react-dom@19.2.5_rea_81be994467029f641d72db51e6e26349/node_modules/omniroute/app

Need to run `npm install wreq-js@2.3.0 better-sqlite3@12.6.2 --no-save`

### Test Impact

Needs a new e2e test

### Error Logs / Output

```shell

```

### Screenshots

_No response_

### Additional Context

_No response_

### Validation Plan

_No response_

bug

description: Something isn't working

title: [BUG] pnpm install still requires manual better-sqlite3 installation


body:
## Summary

OmniRoute v3.7.8 contains **two different encryption key derivation implementations** in the same package that produce incompatible ciphertexts. The health-check/token-refresh thread uses the old dynamic-salt derivation while the main API uses the new static-salt derivation, causing:

1. **Persistent decrypt failures** — tokens encrypted by the health-check thread cannot be decrypted by the main API
2. **Re-encryption loop** — the health-check thread continuously re-encrypts tokens with a dynamic salt, undoing any fix applied with the static salt
3. **CPU spike during crash-loop** — when tokens are encrypted with dynamic salt, the main API fails to decrypt them, causing a cascade of errors and 50% CPU usage

## Root Cause

Two different key derivation functions exist in the built package:

### Old code (chunk 42476) — Dynamic Salt
```javascript
function k() {
  if (null !== i) return i;
  let a = process.env.STORAGE_ENCRYPTION_KEY;
  let b = (0, f.createHash)("sha256").update(a).digest().slice(0, 16);
  //              ^^^^^^^^^^^^^ DYNAMIC — derived from the key itself
  try { i = (0, f.scryptSync)(a, b, 32); }
  // ...
}
```

### New code (chunk 56197) — Static Salt
```javascript
function l() {
  if (null !== j) return j;
  let a = process.env.STORAGE_ENCRYPTION_KEY;
  let b = "omniroute-field-encryption-v1";
  //              ^^^^^^^^^^^^^^^^^^^^^^^^^^^ STATIC — hardcoded string
  try { j = (0, g.scryptSync)(a, b, 32); }
  // ...
}
```

These produce **different derived keys** from the same `STORAGE_ENCRYPTION_KEY`, making ciphertexts from one undecryptable by the other.

The decrypt function in `42476.js` has a fallback that tries the static-salt key when the dynamic-salt key fails, but the **encrypt function** only uses the dynamic-salt key. So the health-check thread encrypts with dynamic salt, the main API tries to decrypt with the dynamic-salt key (different derivation → fails), then falls back to static salt (also fails for newly-encrypted tokens).

## Impact

- **Severity: HIGH** — Causes production outages when tokens become undecryptable
- **CPU**: 50% CPU usage during crash-loop (from repeated decrypt failures triggering health-check)
- **Data**: All encrypted tokens become unreadable until manually fixed
- **Recovery**: Requires manual database fix script to re-encrypt all tokens with static salt

## Reproduction

1. Set `STORAGE_ENCRYPTION_KEY` in server.env
2. Add OAuth providers — tokens get encrypted with static salt
3. Health-check thread runs — re-encrypts tokens with dynamic salt
4. Main API attempts to decrypt — fails (dynamic-salt ciphertext produces different derived key)
5. Error cascade: decrypt failures → health-check triggers → re-encrypts with dynamic salt → more failures
6. CPU spikes to 50%, API responses fail for encrypted fields

## Evidence

```bash
# Check encryption status of active tokens
node -e "
const db = require('better-sqlite3')('/home/openclaw/.omniroute/storage.sqlite');
const rows = db.prepare('SELECT id, access_token, refresh_token FROM provider_connections WHERE is_active = 1').all();
let static = 0, dynamic = 0;
for (const row of rows) {
  for (const col of ['access_token', 'refresh_token']) {
    const val = row[col];
    if (!val || val === 'revoked') continue;
    try {
      const buf = Buffer.from(val, 'base64');
      const saltLen = buf.readUInt8(0);
      const salt = buf.slice(1, 1 + saltLen).toString('utf8');
      if (salt === 'omniroute-field-encryption-v1') static++;
      else dynamic++;
    } catch(e) {}
  }
}
console.log('Static salt:', static, '| Dynamic salt:', dynamic);
db.close();
"

# Output after health-check thread runs:
# Static: 0 | Dynamic: 205  (= ALL tokens re-encrypted with dynamic salt)

# Output after running fix-encryption-static.cjs:
# Static: 539 | Dynamic: 0  (= ALL tokens fixed back to static salt)
```

## Workaround

We created a script (`fix-encryption-static.cjs`) that:
1. Reads all encrypted tokens from the database
2. Decrypts them using the static-salt key (falling back to dynamic-salt key if static fails)
3. Re-encrypts them with the static-salt key
4. Writes the updated tokens back to the database

This script runs via cron every 5 minutes to counteract the health-check thread re-encryption.

## Suggested Fix

1. **Unify key derivation**: Remove the old dynamic-salt code path and use only the static-salt derivation (`"omniroute-field-encryption-v1"`) everywhere
2. **Add migration**: On startup, scan for tokens encrypted with the dynamic salt and re-encrypt them with the static salt
3. **Remove the fallback**: The current fallback in the decrypt function (try dynamic, then try static) masks the issue. After migration, only the static salt key should exist.

## Environment

- OmniRoute v3.7.8
- Node v22.22.1
- Ubuntu 22.04
- 1,239 models configured
- 306 active provider connections
- STORAGE_ENCRYPTION_KEY set via server.env

login: soyelmismo

body: how can i disable the encryption its so annoying.

title: [BUG] Dual encryption key derivation (dynamic vs static salt) causes persistent decrypt failures and 50% CPU


Jan Leon

login: JxnLexn

body:
### OmniRoute Version

3.7.8

### Installation Method

Docker / Docker Compose

### Operating System

Linux

### OS Version

_No response_

### Node.js Version

_No response_

### Provider(s) Involved

Codex

### Model(s) Involved

GPT-5.5

### Client Tool

Visual Studio Code (Github Copilot Chat)

### Description

The costs and the analytics page show costs of $0.00 even though many tokens are being used and the prices per token are set. It was working before, but for the past few days it has stopped working. I am using a combo, but it has worked before using a combo.
On the costs page it also shows a fallback rate of 100%, even tough there was never a fallback to another model.

### Steps to Reproduce

1. Use a model/tokens
2. Go to cost or analytics
3. See $0.00 altough prices are set

### Expected Behavior

Show estimated costs

### Actual Behavior

Did not show estimated costs, instead $0.00

### Test Impact

Unsure

### Error Logs / Output

```shell

```

### Screenshots

**Costs:**

**Analytics:**

**Fallback Rate:**

**Provider Breakdown:**

**Model Breakdown:**

**Costs Pricing:**

### Additional Context

_No response_

### Validation Plan

_No response_

description: Something isn't working

title: [BUG] Est. Cost $0.00