LLM calls | Merge

Logs → LLM calls has one row per model request an employee’s AI client sends through Gateway. You need the View logs permission, and the tab appears once LLM call logs are enabled for your organization.

Fields on an LLM call

When routing changed the model, the model cell shows the requested model, the model that answered, and whether intelligent routing or a fallback caused it.

Field	What it holds
Model and vendor	Requested model, model used, vendor, routing strategy
Project and endpoint	The scope and API surface
Routing policy	The policy applied, with any fallback or intelligent-routing note
Total response time	LLM time and Gateway overhead, with per-stage timings
Estimated cost and service tier	Including any web search charge
Tokens and caching	Input, output, cache type, hit rate, and read/write/miss split
Trace, span, and thread IDs	When the client sent them and tracing is enabled
Harness	The client, from its `X-Merge-Harness` header (not verified)

Filter LLM calls

Filter by date, status (success, error, rate limited, blocked), model, provider, and project, or search free text. Show shadow requests adds the mirrored calls a model migration makes.

Payload logging

Prompt and response bodies appear only when payload logging is on, under Settings → Organization. It controls what Merge stores, not what the model vendor keeps.

To send LLM calls to a SIEM, see Stream logs to a SIEM.