> :robot: _This was written by an AI agent on behalf of @lussoluca._ ## Problem The AI module routes every provider call through `Drupal\ai\Plugin\ProviderProxy`, which dispatches `ai.pre_generate_response`, `ai.post_generate_response`, `ai.post_streaming_response` and `Drupal\ai\Event\AiExceptionEvent`. Webprofiler listens to none of them, so a request that talks to a model leaves no trace in the toolbar. Today the only way to see what happened is out of band: watchdog entries written by `ai_logging`, or OpenTelemetry spans exported by `ai_observability`. Both need extra setup and neither shows the call next to the database queries, the cache hits and the events of the same request. The facts a developer needs while building an AI feature are exactly the facts a data collector is good at holding: which provider answered, with which model, how long it took, how many tokens it burned, which guardrails ran and what they decided. ## Proposal Add an `AiDataCollector`, registered in `WebprofilerServiceProvider` only when the `ai` module is enabled. This is the same conditional registration already used for Blocks, Views, Monolog and Symfony Messenger, so webprofiler keeps no hard dependency on the AI module. The collector subscribes to the four AI events by name and reads their payload with duck typing, so no `Drupal\ai\*` class is referenced directly. Data to collect per call: - **Identity.** Provider, requested model, model that actually answered, operation type, request thread id. - **Timing and outcome.** Duration, streamed or not, status (completed, failed, recovered by a subscriber, answered without ever calling the provider). - **Cost.** Input, output, total, reasoning, cached, cache write and tool use tokens, plus the rate limit headers the provider returned. - **Request payload.** System prompt, messages with role, text and attached files, tools offered to the provider, structured output schema, provider configuration, request metadata, debug data and tags. - **Response payload.** Normalized text, tool calls the provider asked for, finish reasons, raw output and output metadata. - **Guardrails.** Every result recorded on the input, with its label, the mode it ran in, its type (pass, stop, rewrite), its score, its message and its context. - **Failures.** Exception class, message, code and origin, and whether a subscriber recovered the call with a replacement output. Three cases need explicit handling: - **Streaming.** A streamed response carries its token usage only after the iterator has been consumed, so the call must be closed on `ai.post_streaming_response` rather than on `ai.post_generate_response`. - **Nesting.** Agents and model backed guardrails issue their own calls and set a parent request id, so the panel should show the call tree, not a flat list. - **Short circuit.** A guardrail can force an output during the pre generate event, in which case the provider is never called and no post event fires. ## Panel The panel can follow the layout of the [Symfony AI profiler panel](https://github.com/symfony/ai/blob/main/src/ai-bundle/templates/data_collector.html.twig), which solves the same display problem for a different API: a metrics tab, then one section per call, then the guardrails and the tools. ## Related Collectors must survive `serialize()` at kernel terminate, so the collector cannot cache a `VarCloner` on itself. See project/webprofiler#3579661 for the same failure in `EventsDataCollector`.