Google Makes Inference Request Metadata Logging GA Without Logging Prompts or Responses

In its October 30, 2026 release notes, Google Cloud marked inference request metadata logging for Gemini Enterprise Agent Platform as generally available. Once enabled, the service can write a structured Cloud Logging entry for each supported inference request served by a project, including the model, region, token counts, Provisioned Throughput use, latency and error code, while excluding prompts and response text. General availability describes the feature's release stage; it does not mean logging is enabled by default in every project or that every model and API method is covered. This site's issue date is November 2.

The method boundary matters before any setup guide. The announcement lists Gemini calls through `generateContent` and `streamGenerateContent` and Claude calls through `rawPredict` and `streamRawPredict`. The supporting documentation says other partner models are not logged by this mechanism. Both pay-as-you-go and Provisioned Throughput traffic can be covered, but an operator still has to verify which methods its application actually uses. Mixing unsupported traffic into a report without marking the gap could make a missing log look like zero usage. These structured entries are operating and usage metadata, not a full archive of a request and its answer. Google points readers who need content to a separate request-response logging product with different privacy implications.

Configuration is possible in the Google Cloud console from the Provisioned Throughput page or through the REST API. It can target a whole project or a model in a particular region, and changes can take several minutes to take effect. A deployment record should therefore include the time the setting was changed and a known test request sent afterward. The guide names IAM permissions needed to change publisher model configuration and manage the log bucket. It also says SQL queries in Observability Analytics and detailed console metrics require an upgrade of the `_Default` log bucket. That upgrade cannot be undone, and entries written before it cannot later be queried with SQL. Enabling logging, upgrading storage, and granting analysts access are separate changes, each requiring its own review.

Logging also has a measurable cost and retention boundary. Google states that Cloud Logging ingestion and storage are billed, while queries through Observability Analytics are billed as Cloud Monitoring usage. The default bucket retention period is 30 days. More custom labels can increase entry size, so a high-volume agent application that logs every supported request can accumulate material logging charges. The guide suggests measuring one representative day of log volume and projecting a monthly cost. Keeping prompt and response text out of these entries narrows the collected data, but custom labels can still expose identifiers if clients put sensitive values into them. Label design, bucket access, retention and alerts deserve review.

A practical use is attributing consumption to a team, application or tenant. Clients can send headers with the `x-goog-agent-platform-observability-label-` prefix and then query those labels in Observability Analytics. The same entries can help examine tokens by model and region, errors, latency, and whether requests used or spilled over Provisioned Throughput. Business attribution is not created automatically. If a client omits the header or services use inconsistent labels, a query cannot represent all usage. Comparing entries with a bill also requires care about token types, cached tokens and the distinction between usage metadata and an actual charge.

A bounded validation sequence starts with a test project. Confirm IAM and bucket choices, explicitly enable the setting, allow it to propagate, then send recognizable calls using a supported Gemini method and a supported Claude method. Check the entries in Logs Explorer or an already prepared analytics bucket, including model, region, token and error fields. Exercise an unsupported method as well so the team understands that "no entry" does not always mean "no request." Record how to reverse the configuration and how existing logs remain governed by retention and access policy. The feature affects cost and information access, so reading this article should not be taken as authorization to enable it in production.

The release supplies finer evidence for inference operations and cost attribution, subject to method coverage, explicit configuration, permissions and log quality. Teams should reconcile entries against actual calls before relying on a dashboard; metadata logging is not a complete prompt audit.