Skip to content

Perplexity Research Round 03 — Source Code Investigation

Record metadata

  • Date collected: 2026-08-01
  • Research tool: Perplexity
  • Topic: Public source-code investigation of OmniRoute routing components and request flow
  • Prompt used: Exact follow-up prompt copied from the referenced ChatGPT conversation below
  • Response source/export: Original Perplexity thread URL was not preserved; citations from the response are retained verbatim
  • Related files: Architecture.md, Roadmap.md

Prompt sent to Perplexity — copied verbatim

Excellent. Now I want to move from documentation-based research to implementation-level verification.

Do not summarize previous findings.

Instead, inspect the OmniRoute repository, source code, issues, discussions, commit history, and maintainer comments to answer the following with evidence.

1. Does OmniRoute already know the final resolved provider/model after routing?
   - Where in the code does routing occur?
   - Which files/functions determine the final provider/model?

2. After routing, where is that information stored?
   - request object
   - response object
   - context
   - session
   - logs
   - cache
   - metadata

3. Is there already an API, endpoint, CLI command, websocket, environment variable, response header, or local file that exposes the resolved provider/model?

4. If not, how difficult would it be to expose it?
   - Is the information already available internally?
   - Would it require only exposing existing metadata, or would it require architectural changes?

5. Search GitHub Issues, Discussions, Reddit, Discord, blogs, and maintainer comments to determine whether anyone has already requested or solved this problem.

6. If you were contributing to OmniRoute itself, what would be the cleanest implementation to expose the resolved provider/model for tools like Claude Code statuslines?

For every conclusion, cite the exact source, file path, issue number, discussion, commit, or maintainer comment.

Do not speculate.
If you cannot verify something, explicitly state that it could not be verified.

Raw Perplexity response — copied verbatim

OmniRoute already knows the final routed provider/model during request processing, and the strongest implementation evidence points to the auto-routing chain in `open-sse/services/autoCombo/virtualFactory.ts` plus `src/sse/handlers/chat.ts`, where the request is converted into a virtual combo and then scored to pick a provider/model. [github](https://github.com/diegosouzapw/OmniRoute/wiki/Auto-Combo)
The repo docs explicitly say the virtual combo is built from active connections, each tuple `(provider, model, connection)` is created, and `connection.defaultModel` or the provider’s first model is chosen as the dispatch target. [github](https://github.com/diegosouzapw/OmniRoute/wiki/Auto-Combo)

## 1. Where routing occurs

For `auto` / `auto/*`, routing occurs in `src/sse/handlers/chat.ts`, which short-circuits the request when the prefix is detected. [github](https://github.com/diegosouzapw/OmniRoute/wiki/Auto-Combo)
That handler calls the virtual auto-combo factory in `open-sse/services/autoCombo/virtualFactory.ts`, which builds the candidate pool from active provider connections and model registry data. [github](https://github.com/diegosouzapw/OmniRoute/wiki/Auto-Combo)
The selection itself is then done by the auto-combo engine, with scoring logic in `open-sse/services/autoCombo/scoring.ts`, routing strategy logic in `open-sse/services/autoCombo/engine.ts`, and variant selection in `open-sse/services/autoCombo/autoPrefix.ts`. [github](https://github.com/diegosouzapw/OmniRoute/wiki/Auto-Combo)

## 2. What stores the resolved info

The verified source says the virtual combo is **in-memory** and “never persisted to DB,” so the resolved route exists at least in request-local runtime state rather than a database record. [github](https://github.com/diegosouzapw/OmniRoute/wiki/Auto-Combo)
The API reference confirms related state is also captured in request logs, usage logs, and analytics endpoints such as `/api/usage/request-logs`, `/api/usage/logs`, `/api/sessions`, and `/api/analytics/auto-routing`, which implies the resolved route can be observed after the fact there. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)
However, I could not verify from the fetched sources the exact in-memory object names or whether the final choice is stored on the request object, response object, session object, cache, or context under a specific property. That part remains unverified. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)

## 3. Existing exposure points

OmniRoute already exposes several routes that are relevant to resolved-provider visibility, but not all of them are guaranteed to expose the final routed model directly. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)
The clearest confirmed exposure points are `/api/usage/request-logs`, `/api/usage/logs`, `/api/sessions`, `/api/analytics/auto-routing`, and `/api/cloud/model/resolve`, plus response headers like `X-OmniRoute-Session-Id` and `X-OmniRoute-Cache`. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)
I could not verify a dedicated public API, CLI command, websocket message, environment variable, or local file that explicitly returns “final resolved provider/model” for every routed request. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)

## 4. How hard it would be to expose

The repository evidence suggests the information is already available internally at routing time, because the system must choose a concrete candidate before forwarding the request upstream. [github](https://github.com/diegosouzapw/OmniRoute/wiki/Auto-Combo)
Because the virtual auto-combo is built in-memory and the engine already returns a chosen provider/model, exposing that choice should likely be a **small plumbing change** rather than an architectural rewrite, provided the code already has a request-scoped result object. [github](https://github.com/diegosouzapw/OmniRoute/wiki/Auto-Combo)
What I could not verify is whether the chosen provider/model is already serialized into request logs or session records today; if it is not, then adding it to those existing records would still be a low-risk extension, not a redesign. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)

## 5. Requests from the community

I found one issue that appears related in spirit: issue `#3368` discusses auto-routing with web-session and no-auth flows, which shows people are actively thinking about routing behavior and credentials discovery. [github](https://github.com/diegosouzapw/OmniRoute/issues/3368)
I also found a discussion thread about consolidating elements into a single window, but I could not verify that it specifically requests resolved-model passthrough for statuslines. [github](https://github.com/diegosouzapw/OmniRoute/discussions/7487)
I could not verify any public issue, discussion, Reddit post, blog, or maintainer comment in the sources I fetched that explicitly asks for “expose the final routed provider/model for tools like Claude Code statuslines.” [github](https://github.com/diegosouzapw/OmniRoute/issues/3368)

## 6. Cleanest implementation

The cleanest contribution would be to attach a normalized routing result to the request lifecycle and then surface it through an existing observability endpoint and response header. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)
Concretely, the best shape would be: `{ requestedModel, resolvedProvider, resolvedModel, routingStrategy, candidateCount, sessionId }`, with the chosen value written once at routing time and reused by request logs, auto-routing analytics, and any CLI integration. This matches OmniRoute’s current architecture because it already has request logs, analytics, sessions, and provider/model routing primitives. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)
For Claude Code statuslines, the most practical consumer would then be a thin wrapper script that reads that field from a local OmniRoute endpoint or header-backed sidecar and falls back to Claude Code’s `model.display_name` when the route is not available. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)

## 7. Verified limitation

I can verify that OmniRoute performs real routing and already has multiple observability surfaces, but I could not verify the exact internal storage location of the resolved provider/model from the sources fetched here. [github](https://github.com/diegosouzapw/OmniRoute/wiki/Auto-Combo)
I also could not verify a current, documented “resolved model passthrough” API that Claude Code statuslines can consume directly today. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)
If you want, the next step would be a code-path-level audit of `src/sse/handlers/chat.ts`, `open-sse/services/autoCombo/*`, and the request-log persistence layer to pin down the exact property names and the easiest patch point.

Researcher notes

Treat referenced file names and source-code descriptions as research leads until they are confirmed against the authoritative source or local installation.

  • Notes: [OPTIONAL]
  • Source paths or symbols to verify: [OPTIONAL]
  • Follow-up required: [OPTIONAL]