View sessions and usage

Sessions describe complete conversations, while Usage describes requests and aggregates. They come from different sources: one session may contain many requests, or it may be found in local history without gateway-level latency.

Browse sessions

Open Sessions to scan history written by supported local CLIs.

1. Filter by app.
2. Choose Today, Last 7 days, Last 30 days, or a custom range.
3. Select View to open a full conversation.
4. Use Expand details for long tool or system messages.
5. Return to the list to reset filters or refresh the scan.

Session cards summarize total messages, user and assistant messages, tool or system messages, and the conversation span.

Understand the Usage summary

The top of Usage shows four aggregates:

• Total cost: input, output, and cache cost under current pricing and multipliers.
• Total requests: request count and success rate in the current filter.
• Actual tokens: input, output, cache creation, and cache reads.
• Cache hit rate: the share of repeated input served from cache.

The trend view plots tokens, cost, and request count by time bucket. It needs at least two buckets.

Filter and drill down

1. Choose a time range.
2. Narrow by status, provider, or model.
3. Select a Provider statistics row to filter the whole page to that provider.
4. Select a model row to narrow it again.
5. Open a request log entry to inspect request model, pricing model, tokens, cache, cost, time to first token, and total latency.
6. Use Reset to return to the full range.

Data sources

OcHub can combine:

• Model provider requests
• Claude sessions
• Codex database or session files
• OpenCode sessions
• Gemini sessions
• Legacy local requests
• Manually synchronized sessions

Only requests that pass through the local gateway consistently include gateway-level status, latency, and request IDs. Session-file imports are limited to fields the individual CLI recorded.

Configure model pricing

Under Model pricing:

1. Review the bundled offline LiteLLM catalog, its update time, and revision.
2. Use Sync now to check LiteLLM main; a conditional check also runs daily in the background.
3. Choose request-model or response-model pricing.
4. Set default multipliers and pricing-model sources for Claude and Codex.
5. Add a manual per-million-token override only when the catalog is missing a model, provider or region prices are ambiguous, or your settled rate differs.
6. Save, refresh, and confirm the pricing model and cost on a request detail.

Manual overrides always win and are never changed by catalog sync. The model ID must match the logs. When aliases or gateway mappings are common, response-model pricing is often a better default. Missing models are grouped into one notice instead of producing repeated dialogs.

For historical cost backfill, cache-token semantics, and bill reconciliation, continue to Model pricing and cost calibration.