When you enable request-response logging for Claude on Vertex AI and give it only a project, Vertex auto-creates a dataset (named logging_ENDPOINT_DISPLAY_NAME_ENDPOINT_ID) and a table named request_response_logging. Every sampled Claude call — made via rawPredict or streamRawPredict — becomes one row. The schema is worth learning before you write your first query, because several columns look redundant until you know which populate for partner models.
The columns
| Column | Type | What it contains |
|---|---|---|
endpoint | STRING | The endpoint that served the call — your filter when multiple endpoints log to one table. |
deployed_model_id | STRING | The deployed model identifier (most relevant for self-deployed/fine-tuned endpoints). |
logging_time | TIMESTAMP | When the row was logged — the natural partitioning and retention key. |
request_id | NUMERIC | A per-request identifier for correlating and deduplicating. |
request_payload / response_payload | STRING | The request and response content. Google notes these are "included for partner model logging" — for Claude, this is where your Messages API request JSON and Claude's response live, as strings. |
model / model_version | STRING | Which publisher model and version handled the call. |
api_method | STRING | One of generateContent, streamGenerateContent, rawPredict, streamRawPredict. Claude traffic shows the last two. |
full_request / full_response | JSON | The complete request/response as queryable JSON — use BigQuery's JSON functions to extract fields like usage token counts without string parsing. |
metadata | JSON | Call metadata, including the request latency — the column to aggregate for latency percentiles. |
otel_log | JSON | Present only when enableOtelLogging is on; the same event in OpenTelemetry schema format. See the otel_log deep dive. |
In practice, Claude-focused queries lean on four columns: logging_time for windows, model for slicing, full_request/full_response for structured extraction (input/output token counts from the embedded usage object, stop reasons, tool calls), and metadata for latency.
The 10 MB silent drop
Google documents one hard limit that behaves exactly the way you'd least want: request-response pairs larger than the BigQuery write API's 10 MB row limit are not recorded. Not truncated — absent. There is no error to your application (the Claude call itself succeeds normally) and no stub row in the table.
For most chat traffic 10 MB is generous. But Claude on Vertex supports very long contexts, and the pair that blows the limit is precisely the long agentic session, the request with several large documents inline, or the vision request with big base64-encoded images. Those are often the calls you most want records of. Mitigations are architectural rather than configurable: keep an application-side log of at least the metadata for oversized calls, or reconstruct volume gaps by comparing table row counts (scaled by sampling rate) against Cloud Monitoring request counts for the same window.
Sampling rate and what "complete" means
The table only ever contains the fraction of traffic your samplingRate selects — 0.1 means roughly one row per ten requests. Consequences for analysis:
- Aggregates need scaling. Token totals or request counts computed from the table represent the sample; divide by the sampling rate for fleet estimates, and treat them as estimates.
- Point lookups are probabilistic. "Find the exact request that produced this bad output" only works reliably at
samplingRate: 1.0. If the table serves incident forensics or compliance review, sample at 1.0 and control cost with retention instead. - Two subtraction effects stack. A missing row means either "not sampled" or "over 10 MB" — at partial sampling you cannot tell which, so size-related gaps hide inside sampling noise.
Where to go next
For the metrics-side view of the same traffic — rates, latencies, and errors without content — see the model observability dashboard; for exporting or joining logs elsewhere, log sink export patterns.