Observability, Usage & Analytics

Setting Up Vertex AI Request-Response Logging for Claude: REST-Only, Regional-Only

Vertex AI can log samples of your Claude requests and responses straight into BigQuery — but for Anthropic models the configuration path is narrower than the docs' happy path suggests. Two constraints trip up most first attempts.

Claude 3P 101 · Updated July 2026 · Unofficial guide

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:

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.)

Propagation delay: configuration changes can take a few minutes to take effect. Don't judge success by firing one test request immediately after the 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.

Sources