[FR]: Use span provider hint to order heuristics rather than only using fixed registry.ts order

[charles-dyfis-net]

Proposal summary

Opik allows spans to tag provider -- but this is never used to populate the formatHint field used during rendering in practice, so detection order is always fixed.

Motivation

Adding support for Anthropic is my primary relevant goal. In most cases, it's possible to disambiguate OpenAI and Anthropic wire formats -- but there are corner cases where neither detector can give an authoritative answer.

Honoring the metadata that's already collected at ingestion time to set a preference is a sensible resolution to this conundrum.

[github-actions]

Now I have enough context to write a comprehensive response. The Span type in types/traces.ts already has a provider?: string field. The issue is that this provider field isn't being used to influence formatHint ordering during span rendering. Let me write the response.

Hi, I'm Scout 🦉, the comet-ml/opik repository agent. Let me look into this.

Solution / Workaround

No existing solution or workaround found. The provider field on spans is ingested and stored, but no code currently wires it into the format-detection/formatHint pipeline.

Code Investigation

The relevant pieces are spread across the frontend codebase:

apps/opik-frontend/src/types/traces.ts — The Span interface already carries provider?: string (and model?: string):

export interface Span extends BaseTraceData {
  type: SPAN_TYPE;
  parent_span_id: string;
  trace_id: string;
  project_id: string;
  workspace_name?: string;
  model?: string;
  provider?: string;   // ← already collected at ingestion time
}

apps/opik-frontend/src/lib/provider.ts — Contains provider resolution helpers (getProviderFromModel, getProviderDisplayName, etc.), but none of these feed into any formatHint construction or detection-order logic.

apps/opik-frontend/src/v2/pages-shared/traces/TraceDetailsPanel/ — This is where span data is rendered (via TraceDataViewer/, TraceAIViewer/, etc.). The TraceAIViewer receives spans?: Span[] but does not extract provider from individual spans for hint purposes.

The reporter references a registry.ts that governs the order in which wire-format heuristics are tried. That file likely lives inside TraceDataViewer/ or a sibling directory (not yet fully explored within this budget), but the key observation holds: Span.provider is never read to prioritise or skip detectors before they run.

Test coverage: No tests for the formatHint/detection-order behaviour were found in src/lib/traces/ or the TraceDetailsPanel directories.

Next Steps

The fix involves two parts:

1. Map span.provider to a formatHint value. In apps/opik-frontend/src/lib/provider.ts (or a new formatHint.ts utility), add a function that converts the provider string (e.g., "anthropic", "openai") to the corresponding formatHint identifier expected by registry.ts.

2. Pass the hint into the detector/registry. Wherever registry.ts (likely inside TraceDataViewer/) iterates detectors in fixed order, accept an optional formatHint parameter. When provided, move the matching detector to the front of the iteration list rather than relying solely on registration order. This preserves full fallback behaviour — the preferred detector is tried first, but if it can't give an authoritative answer, the rest of the registry still runs.

Concretely:

// pseudocode in registry.ts / detector runner
function detectFormat(data: unknown, formatHint?: string) {
  const ordered = formatHint
    ? [registry.get(formatHint), ...registry.filter(d => d.id !== formatHint)]
    : [...registry];
  return ordered.find(d => d.detect(data));
}

And at the call site (the component rendering the span's I/O), pass span.provider as the hint:

detectFormat(span.input, span.provider ?? undefined);

This is a self-contained, additive change with no breaking API implications. Finding and modifying registry.ts precisely is the remaining step — it should be locatable within TraceDataViewer/ or a lib/traces/ subdirectory.

Feel free to open a pull request with this fix — the change is straightforward!

Was this helpful? React to this comment with 👍 or 👎 to rate my response.

---

View Scout trace in Opik

[yaodong-shen]

I would like to work on this.

On current main, detectLLMMessages already accepts an optional formatHint, but the trace/span rendering path never forwards data.provider: both the Messages-tab eligibility check and mapAndCombineMessages call use registry order only.

I plan to wire the provider hint through both paths, preserve the existing full fallback behavior for unknown or unsupported providers, and add regression coverage for ambiguous payloads where the hint must win. I will keep the change scoped to the frontend format-detection flow.