litellm - 💡(How to fix) Fix Spend logs silently dropped when provider returns non-unique response IDs (Ollama Cloud)

Bug Description

LiteLLM_SpendLogs uses the provider's response id field as the primary key (request_id). Ollama Cloud returns globally sequential IDs like chatcmpl-213, chatcmpl-808, etc. — these are shared across all users and models on Ollama's infrastructure, so they collide with previously logged requests. The INSERT silently fails on the PK constraint and the spend log is never written.

This means all Ollama Cloud requests are invisible in the spend logs / request log UI once the sequential counter wraps around or reuses an ID that was already recorded from a different model or session.

Steps to Reproduce

1. Configure an Ollama Cloud model (api_base: https://ollama.com/v1) as an openai/ provider
2. Send a few requests — they may or may not log depending on whether the returned chatcmpl-NNN ID already exists in the table
3. Query LiteLLM_SpendLogs — the Ollama requests are missing
4. Enable LITELLM_LOG=DEBUG — you can see db_spend_update_writer.py:723 - Writing spend log to db fires, but the row never appears

Root Cause

get_spend_logs_id() in spend_tracking_utils.py prefers response_obj.get("id") over kwargs.get("litellm_call_id"). For providers that return unique UUIDs (OpenAI, Anthropic, OpenRouter, etc.) this works fine. But Ollama Cloud returns short sequential IDs that are not globally unique, causing silent PK collisions.

Confirmed by querying the DB:

SELECT request_id, model, model_group, "startTime"
FROM "LiteLLM_SpendLogs"
WHERE request_id IN ('chatcmpl-213', 'chatcmpl-808', 'chatcmpl-920');

  request_id  |                model                |  model_group   |        startTime
--------------+-------------------------------------+----------------+-------------------------
 chatcmpl-213 | openai/glm-5.1:cloud                | glm-5.1        | 2026-05-16 05:30:01.453
 chatcmpl-808 | openai/glm-5.1:cloud                | glm-5.1        | 2026-04-19 18:24:35.292
 chatcmpl-920 | openai/gemini-3-flash-preview:cloud | gemini-3-flash | 2026-04-26 05:31:20.946

New kimi-k2.6 requests returning chatcmpl-213 etc. collide with these existing rows.

Suggested Fix

Always use litellm_call_id (the proxy-generated UUID) as the request_id PK in LiteLLM_SpendLogs, and store the provider's response id in a separate field. The proxy already generates a unique litellm_call_id for every request — it just isn't used as the PK.

Alternatively, fall back to litellm_call_id when the provider's id is not UUID-shaped, or use ON CONFLICT to detect and handle collisions.

Related

• #13280 — "Missing spend logs" — likely the same root cause for some reporters
• #25952 — PR documenting the get_spend_logs_id() code path

Environment

• LiteLLM version: v1.83.3-stable (ghcr.io/berriai/litellm-database)
• Provider: Ollama Cloud (https://ollama.com/v1) via openai/ custom provider
• DB: Postgres 16