Skip to content

Perplexity Research Round 02 — OmniRoute Metadata

Record metadata

  • Date collected: 2026-08-01
  • Research tool: Perplexity
  • Topic: OmniRoute routing behavior, resolved provider/model metadata, and observability surfaces
  • 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, Knowledge-Base.md

Prompt sent to Perplexity — copied verbatim

Use the research already in this thread and focus only on the remaining gap: Claude Code + OmniRoute metadata passthrough.

I need you to determine, with sources:
1. exactly where the statusline model label becomes "auto"
2. whether OmniRoute can expose the resolved provider/model instead of "auto"
3. whether Claude Code’s statusline payload can consume that field directly
4. if not, whether a wrapper script or OmniRoute config can fix it
5. the best practical path to a clean provider-agnostic statusline

Do not repeat general background. Trace the data path, inspect source/config where needed, and give me the most likely fix plus any confirmed limitations.

Raw Perplexity response — copied verbatim

The data path is now clear: Claude Code’s statusline gets a JSON payload on stdin, and the model label it prints comes from `model.id` / `model.display_name`; if that payload contains `auto`, the statusline is only echoing what Claude Code thinks the model field is, not necessarily the actual routed backend. [code.claude](https://code.claude.com/docs/en/statusline)

## 1. Where “auto” appears

The “auto” label is most likely introduced upstream of the statusline script, at the point where Claude Code serializes session state and populates its `model` field. Claude Code docs show the script receives JSON and explicitly document `model.id` and `model.display_name`, but they do not document any separate “resolved provider” field for dynamic routing. [code.claude](https://code.claude.com/docs/it/statusline)
Community examples that parse `.model.display_name` will therefore show `auto` whenever Claude Code emits `auto` there, because the script is not resolving the backend itself. [alexop](https://alexop.dev/posts/customize_claude_code_status_line/)

## 2. Can OmniRoute expose the resolved model?

OmniRoute has explicit model-routing and model-mapping concepts, including provider-model mapping APIs and a live catalog used by its CLI setup commands, so it can represent the final routed model internally. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)
The evidence I found does **not** confirm that OmniRoute automatically forwards a “resolved backend model” field into Claude Code’s statusline payload today. What is confirmed is that OmniRoute can expose its own model catalog and route requests to provider-native models, but that is not the same as Claude Code receiving that metadata in its statusline JSON. [github](https://github.com/diegosouzapw/OmniRoute/blob/main/docs/guides/USER_GUIDE.md)

## 3. Can Claude Code consume a passthrough field directly?

Claude Code’s statusline documentation only confirms built-in fields such as `model.id`, `model.display_name`, `workspace.current_dir`, context usage, and rate-limit information. It does not document arbitrary passthrough fields or a plug-in mechanism for custom metadata keys. [code.claude](https://code.claude.com/docs/zh-TW/statusline)
So, unless a new undocumented field is already present in your runtime payload, the safe answer is no: Claude Code’s statusline consumer appears limited to the payload it already sends, and I found no confirmed mechanism for arbitrary OmniRoute metadata to be rendered directly. [andynu.github](https://andynu.github.io/claude-code/2026/04/02/claude-code-statusline.html)

## 4. What can fix it

If OmniRoute can be configured to emit the resolved provider/model into a header, response metadata, or a local side channel, then a wrapper script can read that source of truth and render the label itself. OmniRoute already exposes response headers like `X-OmniRoute-Session-Id`, `X-OmniRoute-Cache`, and other gateway metadata, which shows it is capable of attaching routing-related metadata to responses. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)
That means the most practical fix is usually a **wrapper statusline script**, not a pure Claude Code config change: the script can prefer OmniRoute-derived metadata if you can surface it locally, and fall back to `model.display_name` otherwise. [github](https://github.com/diegosouzapw/OmniRoute/wiki/CLI-Integrations)
I did not find confirmation that OmniRoute has a one-line config toggle that makes Claude Code’s statusline automatically replace `auto` with the final routed model. [github](https://github.com/diegosouzapw/OmniRoute/blob/main/docs/guides/USER_GUIDE.md)

## 5. Best practical path

The cleanest provider-agnostic path is:

1. Keep Claude Code’s official statusline mechanism. [code.claude](https://code.claude.com/docs/en/statusline)
2. Replace the autogenerated formatting with a thin wrapper script. [github](https://github.com/daniel3303/ClaudeCodeStatusLine)
3. Have that script render `model` from the best available source in this order: OmniRoute-resolved metadata if available, then Claude Code’s `model.display_name`, then `model.id`, then a small fallback such as `auto`. [github](https://github.com/diegosouzapw/OmniRoute/wiki/CLI-Integrations)
4. Keep the visible bar compact: `model · branch · ctx% · quota`, which matches the strongest community patterns. [didof](https://didof.dev/blog/claude-code-custom-statusline/)

## 6. Most likely fix for “auto”

The most likely fix is **not** inside the statusline formatter alone; it is to make OmniRoute expose the resolved route in a machine-readable place and then let the statusline script consume that field. If OmniRoute cannot surface that metadata cleanly, then the statusline cannot invent the real model and must continue showing `auto` or a user-defined alias. [code.claude](https://code.claude.com/docs/en/statusline)

## 7. Confirmed limitation

I could confirm the statusline payload shape and the existence of OmniRoute’s routing/model catalog APIs, but I could not confirm a documented bridge that passes OmniRoute’s final resolved backend model directly into Claude Code’s statusline JSON. That gap is the reason this problem is best solved with a wrapper script plus a gateway-side metadata source, rather than expecting Claude Code alone to infer the final provider. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)

Researcher notes

Record provenance and questions for local verification only. Claims about OmniRoute remain unverified until supported by local evidence or an authoritative source.

  • Notes: [OPTIONAL]
  • Candidate metadata fields or interfaces to verify: [OPTIONAL]
  • Follow-up required: [OPTIONAL]