Skip to content

Perplexity Research Round 04 — Endpoint Investigation

Record metadata

  • Date collected: 2026-08-01
  • Research tool: Perplexity
  • Topic: Candidate OmniRoute endpoints, logs, APIs, events, and statusline integration options
  • 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, Roadmap.md

Prompt sent to Perplexity — copied verbatim

Inspect every OmniRoute endpoint you identified.

I am NOT asking whether the endpoint exists.

I want the response schema.

For each endpoint:

- example request

- example response

- response JSON schema

- authentication requirements

- whether it contains

    resolved provider

    resolved model

    requested model

    routing strategy

    session id

    latency

    token usage

    cost

- whether it can be queried locally without affecting routing performance.

Then rank every endpoint from best to worst for powering a Claude Code statusline.

If none contain the resolved provider/model, identify the smallest code change required to expose it.

Raw Perplexity response — copied verbatim

I can’t fully satisfy the “inspect every endpoint” requirement with hard verification from the sources I was able to retrieve, because the API reference content I could access is incomplete and several endpoint schemas are only described at a high level. What I *can* verify is enough to identify which endpoints are promising for a Claude Code statusline and what the documented metadata exposure looks like. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)

## Endpoint findings

### 1) `/v1/chat/completions`

Example request is documented as an OpenAI-style POST with `Authorization: Bearer your-api-key`, JSON body including `model`, `messages`, and `stream`. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)
Example response schema was **not fully retrievable** from the source I accessed, so I cannot quote a verified full JSON schema here. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)
Confirmed contents: requested model, token usage is implied by OpenAI-style responses but not explicitly verified in the snippet I retrieved; resolved provider/model, routing strategy, session id, latency, and cost were **not verified** in the retrieved schema text. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)
This endpoint is routable online and therefore may affect routing performance if queried repeatedly against the live gateway. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)

### 2) `/v1/models`

The docs say `GET /v1/models` returns all chat, embedding, and image models plus combos in OpenAI format. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)
Example request: `GET /v1/models` with Bearer auth. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)
Example response schema was not fully retrievable, but the endpoint is explicitly for model listing and the separate changelog note says `/v1beta/models` returns only public metadata such as `name`, `strategy`, `model ids`, `providerId`, and `description`, with internal routing details stripped. [github](https://github.com/diegosouzapw/OmniRoute/blob/main/CHANGELOG.md)
This is useful for static catalog lookup, not for live resolved-provider statusline display, and it does not appear to be the right endpoint for session-specific routing data. [github](https://github.com/diegosouzapw/OmniRoute/blob/main/CHANGELOG.md)

### 3) `/api/usage/history`

The API reference lists this as a usage-history endpoint, but I could not retrieve a verified request/response example or schema. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)
It likely contains aggregate usage information, but I could not verify whether it includes resolved provider/model, requested model, latency, token usage, or cost. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)
Authentication requirements were not fully retrievable from the source snippet. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)
Because it is a usage API, it should be queryable locally, but I could not verify any stated performance impact. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)

### 4) `/api/usage/logs`

The API reference lists this as usage logs, and the logging docs say request logs are stored in SQLite `call_logs` and detailed logs are captured as JSON artifacts in a ring buffer. [deepwiki](https://deepwiki.com/diegosouzapw/OmniRoute/9.4-logs-and-audit)
Example request/response schema was not fully retrievable. [deepwiki](https://deepwiki.com/diegosouzapw/OmniRoute/9.4-logs-and-audit)
This is the strongest candidate for statusline data because logs are the most likely place to contain requested model, resolved provider/model, latency, tokens, and cost, but I could not verify the exact fields from the fetched schema. [deepwiki](https://deepwiki.com/diegosouzapw/OmniRoute/9.4-logs-and-audit)
It should be locally queryable and likely low-impact compared with live routing, since it reads stored logs rather than forcing a route. [deepwiki](https://deepwiki.com/diegosouzapw/OmniRoute/9.4-logs-and-audit)

### 5) `/api/usage/request-logs`

The API reference lists request-level logs. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)
The logging docs confirm “Request Logs” are stored in SQLite `call_logs` and are meant for API endpoint access and routing flow. [deepwiki](https://deepwiki.com/diegosouzapw/OmniRoute/9.4-logs-and-audit)
That makes this the best *likely* source for resolved provider/model, routing strategy, session id, latency, token usage, and cost, but I could not verify the exact response fields or JSON shape from the retrieved content. [deepwiki](https://deepwiki.com/diegosouzapw/OmniRoute/9.4-logs-and-audit)
It should be safely queryable locally and should not materially affect routing performance because it reads persisted logs. [deepwiki](https://deepwiki.com/diegosouzapw/OmniRoute/9.4-logs-and-audit)

### 6) `/api/sessions`

The API reference lists `/api/sessions` and the logs/audit docs say detailed pipeline data is retained for observability. [deepwiki](https://deepwiki.com/diegosouzapw/OmniRoute/9.4-logs-and-audit)
I could not retrieve a schema or confirm whether it includes session id, routing strategy, resolved provider/model, or latency. [deepwiki](https://deepwiki.com/diegosouzapw/OmniRoute/9.4-logs-and-audit)
Authentication requirements were not verified in the retrieved text. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)
This is likely locally queryable and low-impact if it is session metadata only. [deepwiki](https://deepwiki.com/diegosouzapw/OmniRoute/9.4-logs-and-audit)

### 7) `/api/analytics/auto-routing`

The API reference explicitly says this endpoint returns aggregate auto-routing stats such as total calls, strategy distribution, tier distribution, and top providers. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)
That confirms routing strategy and top providers at an aggregate level, but not per-request resolved provider/model. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)
I could not verify token usage, cost, latency, or session id in the response. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)
This is probably safe to query locally and should not affect routing performance because it is analytics over stored data. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)

### 8) `/api/cloud/model/resolve`

The API reference says this resolves a logical model id to a concrete provider/model using the local routing table. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)
That is the only endpoint I found that directly targets the resolved provider/model concept. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)
However, I could not retrieve an example request/response body or confirm whether it returns routing strategy, session id, latency, token usage, or cost. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)
It should be locally queryable, and because it uses routing tables rather than live inference, it likely has minimal performance impact. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)

## Rank for Claude Code statusline

1. `/api/usage/request-logs` — best likelihood of per-request resolved provider/model, routing strategy, session id, latency, token usage, and cost, based on the logs architecture. [deepwiki](https://deepwiki.com/diegosouzapw/OmniRoute/9.4-logs-and-audit)
2. `/api/usage/logs` — also strong for observability and likely similar data, but less specifically tied to routing flow than request logs. [deepwiki](https://deepwiki.com/diegosouzapw/OmniRoute/9.4-logs-and-audit)
3. `/api/sessions` — potentially useful for session id and summary metadata, but unverified. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)
4. `/api/analytics/auto-routing` — great for aggregate routing intelligence, not per-session statusline truth. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)
5. `/api/cloud/model/resolve` — best for resolving a requested model to a concrete provider/model, but not a live session telemetry source. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)
6. `/v1/models` — good for catalog display only. [github](https://github.com/diegosouzapw/OmniRoute/blob/main/CHANGELOG.md)
7. `/v1/chat/completions` — necessary for inference, but not a clean statusline metadata source. [github](https://github.com/diegosouzapw/OmniRoute/wiki/API-Reference)

## Smallest code change

If none of these endpoints currently contain the resolved provider/model in a way the statusline can consume, the smallest change is to extend the existing request-log record and response metadata at routing time with a normalized routing result object such as `resolvedProvider`, `resolvedModel`, `requestedModel`, `routingStrategy`, `sessionId`, `latencyMs`, `tokens`, and `cost`. [deepwiki](https://deepwiki.com/diegosouzapw/OmniRoute/9.4-logs-and-audit)
That is smaller than inventing a new endpoint because the logs system already exists and is explicitly designed for routing-flow observability. [deepwiki](https://deepwiki.com/diegosouzapw/OmniRoute/9.4-logs-and-audit)
The most practical implementation is to write the resolved route into `call_logs` and expose it through `/api/usage/request-logs`, then let the Claude Code statusline wrapper read from that endpoint. [deepwiki](https://deepwiki.com/diegosouzapw/OmniRoute/9.4-logs-and-audit)

If you want, I can next turn this into a concrete endpoint-by-endpoint statusline integration plan, but I won’t ask you to fetch more docs unless needed.

Researcher notes

Candidate endpoints and integration options must be checked for local availability, authentication, stability, latency, and privacy before they influence the architecture.

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