fix(ui): render Responses API request and response in the logs drawer

[yuneng-berri]

TLDR

Problem this solves:

• Logs drawer shows "No response data available" for /v1/responses calls
• Input card renders empty even though the spend log holds the prompt
• Also hits /v1/chat/completions callers routed over the Responses bridge

How it solves it:

• Parse the Responses input/output shape, not just messages/choices
• Branch on a tagged union instead of sniffing keys with ||
• Map output_text parts to content and function_call items to tool calls

Relevant issues

Fixes #23636

Linear ticket

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have added meaningful tests
• My PR passes all CI/CD checks (e.g., lint, format, unit tests)
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have received a Greptile Confidence Score of at least 4/5 before requesting a maintainer review (Greptile reviews automatically once the PR is opened; only comment @greptileai to re-request a review after pushing changes)

Delays in PR merge?

If you're seeing a delay in your PR being merged, ping the LiteLLM Team on Slack (#pr-review).

Screenshots / Proof of Fix

All runs below are real requests against a live proxy hitting real OpenAI and Anthropic APIs, costing real money. No mocks. The proxy ran on port 4071 against a local Postgres so the spend logs are real rows.

Before: commit 9d5984b358. After: commit 9c2c79f976.

The proxy config used:

model_list:
  - model_name: gpt-5.6
    litellm_params:
      model: openai/gpt-5.6
      api_key: os.environ/OPENAI_API_KEY
  - model_name: claude-sonnet-5
    litellm_params:
      model: anthropic/claude-sonnet-5
      api_key: os.environ/ANTHROPIC_API_KEY

general_settings:
  master_key: sk-1234
  store_model_in_db: true
  store_prompts_in_spend_logs: true
  proxy_batch_write_at: 1

1. Send a Responses API request

curl -s http://localhost:4071/v1/responses \
  -H "Authorization: Bearer sk-1234" -H 'Content-Type: application/json' \
  -d '{"model":"gpt-5.6","input":[{"role":"user","content":"Reply with exactly: hello from responses api"}],"max_output_tokens":64}'

{"id":"resp_4R_bHMirim6OPsVsXq1uOyEYIIDCEKoviMF...","model":"gpt-5.6","object":"response","output":[{"id":"msg_070989277645d4ae...","content":[{"annotations":[],"text":"hello from responses api","type":"output_text"}],"role":"assistant","status":"completed","type":"message"}],"status":"completed","usage":{"input_tokens":14,"output_tokens":8,"total_tokens":22}}

2. Read back what the drawer is given

curl -s -G "http://localhost:4071/spend/logs/ui/resp_4R_bHMirim6OPsVsXq1uOyEYIIDCEKoviMF..." \
  --data-urlencode "start_date=2026-08-02 21:20:18" \
  -H "Authorization: Bearer sk-1234" | jq '{call_type, messages, proxy_server_request, response}'

{
  "call_type": "aresponses",
  "messages": {},
  "proxy_server_request": {"input": [{"role": "user", "content": "Reply with exactly: hello from responses api"}], "model": "gpt-5.6", "max_output_tokens": 64},
  "response": {"id": "resp_4R_...", "output": [{"type": "message", "role": "assistant", "content": [{"type": "output_text", "text": "hello from responses api"}]}], "status": "completed"}
}

The prompt and the completion are both there. proxy_server_request uses input, and response uses output; neither key was understood by the drawer.

3. Before (9d5984b358) — the drawer renders nothing

Feeding that exact row through the drawer's own code path (LogDetailContent -> formatData -> parseMessages):

[FAIL] bug-1  POST /v1/responses
        InputCard  -> 0 message(s)  => renders EMPTY
        OutputCard -> "No response data available"
[FAIL] bug-2  POST /v1/responses          (tool call)
        InputCard  -> 0 message(s)  => renders EMPTY
        OutputCard -> "No response data available"
[FAIL] bug-3  POST /v1/chat/completions   (Responses bridge)
        InputCard  -> 1 message(s) roles=["user"] first="What is the weather in San Francisco? Use the tool."
        OutputCard -> "No response data available"
[PASS] adj-1  POST /v1/chat/completions
        InputCard  -> 1 message(s) roles=["user"] first="Reply with exactly: hello from chat completions"
        OutputCard -> content="hello from chat completions" toolCalls=[]
[PASS] adj-2  POST /v1/chat/completions   (multi-turn)
        InputCard  -> 4 message(s) roles=["system","user","assistant","user"] first="You are terse."
        OutputCard -> content="hello from multi turn" toolCalls=[]
[PASS] adj-3  POST /v1/chat/completions   (native tool call)
        InputCard  -> 1 message(s) roles=["user"] first="What is the weather in San Francisco? Use the tool."
        OutputCard -> content="" toolCalls=["get_weather"]

3 FAILING

4. After (9c2c79f976) — same six live calls, all rendering

[PASS] bug-1  POST /v1/responses
        InputCard  -> 1 message(s) roles=["user"] first="Reply with exactly: hello from responses api"
        OutputCard -> content="hello from responses api" toolCalls=[]
[PASS] bug-2  POST /v1/responses          (tool call)
        InputCard  -> 1 message(s) roles=["user"] first="What is the weather in San Francisco? Use the tool."
        OutputCard -> content="" toolCalls=["get_weather"]
[PASS] bug-3  POST /v1/chat/completions   (Responses bridge)
        InputCard  -> 1 message(s) roles=["user"] first="What is the weather in San Francisco? Use the tool."
        OutputCard -> content="" toolCalls=["get_weather"]
[PASS] adj-1  POST /v1/chat/completions
        InputCard  -> 1 message(s) roles=["user"] first="Reply with exactly: hello from chat completions"
        OutputCard -> content="hello from chat completions" toolCalls=[]
[PASS] adj-2  POST /v1/chat/completions   (multi-turn)
        InputCard  -> 4 message(s) roles=["system","user","assistant","user"] first="You are terse."
        OutputCard -> content="hello from multi turn" toolCalls=[]
[PASS] adj-3  POST /v1/chat/completions   (native tool call)
        InputCard  -> 1 message(s) roles=["user"] first="What is the weather in San Francisco? Use the tool."
        OutputCard -> content="" toolCalls=["get_weather"]

ALL GREEN

5. Reproduce the UI side by hand

1. Start a proxy with the config above; run the dashboard dev server with npm run dev in ui/litellm-dashboard
2. Send the two curls from steps 1 and 2 above, plus one /v1/chat/completions call for comparison
3. Open http://localhost:4000/ui/?page=logs
4. Click the /v1/chat/completions row, keep the "Pretty" toggle selected in the Request & Response panel; the Input and Output cards are populated on both main and this branch
5. Click the /v1/responses row. On main the Input card is blank and the Output card reads "No response data available"; on this branch both cards render the prompt and the completion
6. Toggle to "JSON" on the same row; the Request tab already showed the payload on both branches, which is what made the Pretty view look like missing data rather than a parsing gap

/v1/messages

Not applicable. This changes only how the Admin UI parses a stored spend-log row, and /v1/messages is not one of the two payload shapes involved. Its rows are unaffected either way.

Type

🐛 Bug Fix

Changes

parseMessages only ever understood the Chat Completions payload: it read request.messages and response.choices[0].message. A spend log stores whatever shape the call actually used, so a /v1/responses row arrives with input and output and neither key matched. The Input card got an empty array and the Output card got null, which is what prints "No response data available".

The empty messages column mentioned in the issue is a red herring. _get_messages_for_spend_logs_payload returns "{}" for every call type except _arealtime, so it is empty for chat completions too; those still render because LogDetailContent falls back to proxy_server_request, whose body happens to carry a messages key. For the Responses API that body carries input instead, so the fallback landed on a shape nothing downstream could read.

This is not limited to callers who use /v1/responses directly. One of the live cases above is a plain /v1/chat/completions request that litellm routed over the Responses bridge; the stored response came back with output and no choices, so the drawer went blank for a caller who never touched the Responses API. That is the likeliest explanation for the reports in the issue of the panel working one day and not the next.

Rather than adding another || chain to an any-typed function that had already grown one bespoke branch for realtime, parsing now classifies the payload into a tagged union (RequestPayload, ResponsePayload) and switches on it once. The Responses branch covers what the live payloads actually contain: input as a bare string, instructions as a leading system turn, input_text/output_text content parts, function_call and function_call_output items, and reasoning items which carry no user-facing text. Output items fold into a single assistant message so tool calls render the same way they do for chat completions.

Two smaller things came along with it, both consequences of typing the function rather than separate changes: role is now validated against the union instead of msg.role || "user", which maps developer onto system and the legacy function role onto tool instead of leaving a role the cards cannot style; and parseMessageContent returns "" rather than undefined for absent content, which is what the rest of the drawer already assumed.

The now-unused no-nested-ternary suppression for this file is pruned from eslint-suppressions.json.

Final Attestation

• The tests check the right things, including the edge cases, and regressions in the respective real-world customer use-cases are not possible after this PR

[greptile-apps]

Greptile Summary

The PR extends the logs drawer’s Pretty view to parse both Chat Completions and Responses API payloads while retaining realtime handling.

• Introduces tagged request and response payload types.
• Parses Responses API instructions, input items, output text, and function calls.
• Normalizes supported message roles and content-part types.
• Adds regression tests for Responses payloads, tool calls, follow-up turns, and empty output.
• Removes the obsolete nested-ternary ESLint suppression.

Confidence Score: 5/5

The PR appears safe to merge with no concrete changed-code failure identified.

The new parser defensively distinguishes supported payload shapes, preserves existing Chat Completions and realtime behavior, and covers the reported Responses API request, text-output, and tool-call paths with focused tests.

Important Files Changed

Filename	Overview
ui/litellm-dashboard/src/components/view_logs/LogDetailsDrawer/prettyMessagesUtils.ts	Adds defensive tagged-shape classification and parsing for Responses API requests, responses, content parts, and tool calls without an established regression.
ui/litellm-dashboard/src/components/view_logs/LogDetailsDrawer/prettyMessagesTypes.ts	Defines stricter message-role, payload, and tool-call types supporting the new parser.
ui/litellm-dashboard/src/components/view_logs/LogDetailsDrawer/PrettyMessagesView.test.tsx	Adds focused coverage for Responses API rendering and preserves existing Chat Completions and realtime cases.
ui/litellm-dashboard/eslint-suppressions.json	Removes the now-unused nested-ternary suppression for the refactored utility.

_{Reviews (1): Last reviewed commit: "fix(ui): render Responses API request an..." | Re-trigger Greptile}

[devin-ai-integration]

QA verdict: PASS

Independent QA of 9c2c79f976. Every scenario I ran passes, no blocking defects, no regressions in the Chat Completions and Anthropic paths. Two non-blocking UX nits and one environment observation are at the bottom

How I tested: Admin UI dev server (npm run dev, port 3000) running this branch, pointed at a live proxy on localhost:4000 backed by a local Postgres with store_prompts_in_spend_logs: true. Every row inspected is a real spend log from a real OpenAI or Anthropic call; no mocks, real money. Deployments were gpt-5.6, claude-sonnet-5 and a Responses-only gpt-5.3-codex (so a plain /v1/chat/completions call to it gets bridged onto the Responses API, which is the interesting regression case). "Before" captures are the same rows with the two changed source files checked out at 9d5984b358, so the only variable is this diff

Before and after, same row, same browser

/v1/responses row: no Input card and "No response data available" before, both cards populated after

Before (9d5984b358)	After (this PR)

Walkthrough

Annotated run through the happy path, the sad path and the edge cases in the drawer

The case a user is most likely to hit: a plain /v1/chat/completions call bridged onto the Responses API

gpt-5.3-codex only speaks the Responses API, so a chat request against it is bridged and the stored row is mixed shape: a messages request with an {"object": "response", "output": [...]} response. The JSON tab confirms the mixed shape, so this is genuinely the new parser handling it rather than a lucky match. Three such rows all render now; all three were blank on the output side before

Tool calls in both directions, including a streaming call

Follow-up turn: the request input carries the prior assistant function_call and its function_call_output, and both render in the history alongside the final answer

Output-side tool call on a single-shot Responses request

Also verified on a freshly made streaming /v1/responses call with tools, since streamed responses are reassembled before storage

Everything else that was checked

Passing on the Responses side: bare string input; instructions rendered as the pinned system turn ahead of the user turn; input_image parts rendered as [Image] with the model's answer in Output; a developer role rendered as a pinned system turn; a request input echoing back a real reasoning item (id plus encrypted_content) drops that item cleanly instead of emitting an empty turn

Sad path: a 400 from an unknown model still shows the Request Failed alert with the provider message, and the Input card now renders the prompt that failed while Output stays legitimately empty

Regression rows unchanged against the base captures: plain Chat Completions, multi-turn Chat Completions with a tool result, Anthropic /v1/messages, and an Anthropic model called through /v1/responses (a Responses-shaped request with a chat-shaped response)

Drawer mechanics still fine: Pretty and JSON round-trip on every row, the Request and Response JSON tabs show the raw bodies, the Input card copy button fires its toast, J and K still move between rows with the drawer open, and the panel stays scrollable in a small window. Console is clean apart from two pre-existing antd warnings (Card bordered is deprecated, antd v5 supports React 16~18) that also appear on base

Scoped frontend tests pass (308 in src/components/view_logs). I also mutation tested the new parser against the PR's own test file: 11 of 19 mutations killed. Four survivors are behavior this PR adds, so they are worth an assertion if you want the regression locked down: dropping the input_text content-part case, ignoring function_call items in the request input (the assistant tool-call turn silently disappears), removing the reasoning skip, and removing the developer to system mapping. I verified all four visually in the UI instead. The remaining survivors (chat tool_calls, tool_call_id, the [Image] label, tool-argument JSON parsing) are pre-existing untested behavior, not something this PR introduced

Non-blocking notes

A response with status: "incomplete" (truncated at max_output_tokens, so its only output item is a reasoning item) shows a Success badge and "No response data available", which is indistinguishable from a parse failure unless you open the JSON tab. Pre-existing and out of scope here, but now that Responses rows render, this is the remaining case where the Pretty view looks broken while nothing is wrong

The developer label is no longer visible in the Pretty view since it maps to system; deliberate, matches OpenAI semantics, and the JSON tab still shows the original role

Unrelated to this diff: three of the very long ?log_id=resp_... deep links (roughly 750 characters) loaded the logs page with the drawer closed, and clicking the row opened it fine. It reproduced on rows that have nothing to do with parsing, so I believe it is a pre-existing deep-link limitation with long ids; I did not confirm it against base

Not covered: Realtime rows, since RealtimePrettyView short-circuits before parseMessages and no realtime rows existed in my environment