Apigee’s AI and tool views help locate the wait

You ask an assistant to search the logs, then wait. Is the model composing an answer, or has the search itself stalled? Google Cloud’s September 30, 2026 release notes introduced separate Apigee API insights views for AI performance and MCP tool performance. For calls passing through Apigee, that split gives the investigation a more useful starting point than “the assistant is slow.”

The answer may be less dramatic than a broken component. Perhaps people are asking more questions that need large searches. A slower model, a slower tool and a change in the work requested can produce a similar wait at the chat window. The charts help only if those possibilities remain distinguishable.

Which calls are making the person wait?

The AI view covers model latency, errors and token use, the pieces of text processed or generated. The Tool view covers traffic, throughput, payload sizes and latency for tools connected through Model Context Protocol, or MCP. Both sit under API hub → API insights, with filters including the tool and deployment. The reference notes that latency percentiles combine calls unless you select the particular model or tool.

Imagine an assistant with two tools: get_deployment retrieves one record; search_logs retrieves a larger collection of events. Neither changes speed, but today people ask many more log-search questions. The combined timings move. On another day, enough quick deployment lookups could hide how long searches take.

A percentile locates a point among the selected calls. At p95, roughly 95% finished at or below that time. Put more searches into the selection and that point can move even when neither tool slows down. Selecting log searches brings the chart closer to the experience of the person still waiting for logs.

Carry that tool selection and the complaint’s time window into its backing logs or traces. Switching to an all-day mixture halfway through would answer a different question, even if the next chart looks reassuring.

An empty field may be missing measurement detail

Now suppose token totals appear, but the assistant’s application has no breakdown. It may still have called the model. Google requires VerifyAPIKey, PromptTokenLimit and LLMTokenQuota on the model-facing proxy for every AI chart and filter to populate. Without API-key verification, totals can appear while the application breakdown stays empty. A blank field can describe missing measurement detail rather than missing work.

Adding that detail should not accidentally reject the next person’s search. The token-policy tutorial distinguishes CountOnly, which records usage, from EnforceOnly, which can reject requests. Explicit JSON paths select the prompt and response fields to measure. Use a supported setup for the serving deployment: this tutorial covers Apigee, not Apigee hybrid.

Even the clock labels need a look. API insights places a measurement at the end of its collection interval; Apigee API Analytics places it at the start. Two matching labels can therefore describe different minutes. Align the boundaries before comparing them. The dashboard reference covers Apigee and Apigee hybrid, but that does not expand the token-policy tutorial’s narrower scope.

Follow one recognizable model request and log-search call through the filters. Do the application, model, tool and interval still match the source records? If not, resolve that mismatch before reading a difference between bars as a difference in performance. The broader dashboard guide develops this same connection between a view and the work it represents.

An empty gateway chart cannot explain a call that bypassed the gateway; follow application traces for that work. For calls the gateway did see, the two views can narrow the original question. The person waiting for logs does not need a prettier chart. They need you to find where their request is waiting.