Google Vertex AI's request-response logging saves samples of the requests you send to a model and the responses it returns into a BigQuery table you own. For Claude — a supported partner model, covering calls made via rawPredict and streamRawPredict — this is the platform's primary mechanism for capturing actual prompt and completion content, the raw material for quality review, debugging, and misuse investigation. The feature is in Preview (Google's Pre-GA terms apply), which is worth flagging to your platform team before you build compliance processes on it.
The two constraints
Constraint one: REST only. For Anthropic models, only the REST API can configure logging — you set the publisher to anthropic in the request path. There is no console toggle documented for this path and no gRPC route; your infrastructure-as-code or setup script calls the REST endpoint directly.
Constraint two: regional endpoints only. Google is explicit that the global endpoint and multi-regional endpoints don't support this feature. That matters because many Claude-on-Vertex deployments default to the global endpoint (it is the cheaper option and the one the AnthropicVertex(region="global") client examples use). If capturing request-response logs is a requirement, it becomes an input to your endpoint-strategy decision — you need traffic on a regional endpoint for the logging configuration to apply to it.
The setPublisherModelConfig call
Configuration is one REST call against the regional endpoint:
POST https://REGION-aiplatform.googleapis.com/v1beta1/projects/PROJECT
/locations/REGION/publishers/anthropic/models/MODEL
:setPublisherModelConfig
{
"publisherModelConfig": {
"loggingConfig": {
"enabled": true,
"samplingRate": 0.1,
"bigqueryDestination": {"outputUri": "bq://PROJECT.DATASET.TABLE"},
"enableOtelLogging": false
}
}
}
The fields:
enabled— turns logging on or off for that publisher model in that region.samplingRate— a fraction between 0 and 1 of requests to log;0.1logs 10%. Sampling exists to control BigQuery storage costs on high-volume workloads, but remember the flip side: anything below 1.0 means the table is a statistical sample, not an audit trail. A specific problematic request has only asamplingRatechance of being present.bigqueryDestination.outputUri— where rows land, inbq://PROJECT.DATASET.TABLEform. If you supply only a project, Vertex auto-creates a dataset namedlogging_ENDPOINT_DISPLAY_NAME_ENDPOINT_IDand a table namedrequest_response_logging.enableOtelLogging— adds an OpenTelemetry-format log column alongside the standard ones; see the otel_log column guide.
To verify what is currently configured, call :fetchPublisherModelConfig on the same model path. (For fine-tuned models deployed to your own endpoints, logging is configured differently — via predictRequestResponseLoggingConfig on the Endpoint resource — and applies to all models deployed under that endpoint.)
POST — wait, send traffic, then query the BigQuery table. The same delay applies when you disable logging: assume a short tail of rows after you turn it off.Governance before you enable
Rows in that table contain full prompts and responses — potentially customer data, contract text, whatever your application sends Claude. Treat the dataset like production PII: restrict it with BigQuery IAM, set a table expiration or partition-expiry policy that matches your retention rules (retention is entirely yours to configure — the logging feature itself imposes none), and document who may query it. Anthropic separately recommends keeping activity logs on roughly a 30-day rolling basis for misuse investigation, which a partition-expiry setting implements neatly. And note this BigQuery logging is distinct from Vertex's tamper-proof log sharing with Anthropic and from Cloud Audit Logs, which record who called the API but not what was said.
Where to go next
Once rows are flowing, the field-by-field schema guide explains every column — including the 10 MB row limit that silently drops your largest conversations.