>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3604247. --> Reported by: [codeitwisely](https://www.drupal.org/user/1210320) >>> <h3>Problem/Motivation</h3> <p> When a user's cloud quota is exceeded and the fallback provider does not natively<br> support the requested operation type (for example, Ollama does not expose a<br> translate_text endpoint), <code>AiPreGenerateSubscriber</code><br> bypasses <code>ProviderProxy</code> entirely by reading its protected<br> <code>$plugin</code> property via ReflectionProperty: </p> <pre> $rawPlugin = (new \ReflectionProperty(ProviderProxy::class, 'plugin')) -&gt;getValue($provider); </pre><p> The bypass itself is intentional: calling the fallback through the proxy would<br> re-fire <code>PreGenerateResponseEvent</code> and<br> <code>PostGenerateResponseEvent</code>, confusing other subscribers unaware of<br> quota rerouting. Reflection is the problem, not the bypass. </p> <p> The approach is fragile in two ways. First, it couples ai_metering to a private<br> implementation detail of <code>ProviderProxy</code> that can change between<br> drupal/ai releases without a deprecation notice. Second, the manual<br> <code>logUsage()</code> call on this path records a character-count estimate<br> (<code>mb_strlen / 4</code>) instead of the real token counts, so the dashboard<br> and exports are wrong for every fallback call. </p> <h3>Investigation result</h3> <p> The original summary assumed drupal/ai 1.4.x ships a provider-selection event<br> that routes swaps through the normal event pipeline. It does not. The events<br> available in 1.4.x are <code>PreGenerateResponseEvent</code>,<br> <code>PostGenerateResponseEvent</code>, <code>PostStreamingResponseEvent</code>,<br> <code>AiExceptionEvent</code> and <code>ProviderDisabledEvent</code>.<br> <code>AiExceptionEvent</code> fires after a failed call, so it cannot serve a<br> preventive reroute that must run before the paid API is contacted. </p> <p> The current architecture (listen to <code>PreGenerateResponseEvent</code>, then<br> <code>setForcedOutputObject()</code>) is already the supported mechanism for<br> preventive rerouting. What 1.4.2 adds is<br> <code>ProviderProxy::getPlugin()</code>, a public typed accessor for the wrapped<br> plugin. That is the sanctioned replacement for the reflection hack. </p> <p> If a pre-call provider-swap event is desirable ecosystem-wide (other<br> quota/budget modules face the same need), that would be a drupal/ai core<br> feature request and a follow-up issue, not something this module can solve<br> alone. </p> <h3>Steps to reproduce</h3> <p>On ai_metering 1.0.0-beta1 or earlier:</p> <ol> <li>Configure ai_metering with Ollama as the fallback provider<br> (<code>quota.fallback_provider: ollama</code>,<br> <code>quota.fallback_model: llama3.2:3b</code>) and set a per-user monthly<br> budget low enough that the next call exceeds it.</li> <li>As that user, trigger a translate_text operation large enough to push the<br> lookahead estimate over budget (a few thousand characters).</li> <li>The reroute succeeds and one row is logged with provider<br> <code>ollama</code> and operation <code>translate_text_fallback</code>.</li> <li>Compare the logged <code>input_tokens</code> with<br> <code>ceil(prompt_length / 4)</code>: they match exactly, which shows the<br> value is the character estimate, not the count the Ollama tokenizer<br> reported. The real count differs by roughly 20% on typical English text.</li> </ol> <h3>Environment (bug reproduced)</h3> <ul> <li>ai_metering 1.0.0-alpha1 through 1.0.0-beta1</li> <li>drupal/ai 1.2 through 1.4.x (the reflection read works everywhere, which is exactly the coupling problem)</li> </ul> <h3>Proposed resolution</h3> <ul> <li>Replace the ReflectionProperty block with <code>$provider-&gt;getPlugin()</code>.</li> <li>Raise the drupal/ai dependency to <code>^1.4.2</code> in composer.json and <code>ai:ai (&gt;=1.4.2)</code> in the info file, since <code>getPlugin()</code> first appears in 1.4.2.</li> <li>Keep the proxy bypass and the manual <code>logUsage()</code> call: the provider populates <code>TokenUsageDto</code> inside <code>chat()</code> itself, so real token counts are available on the returned <code>ChatOutput</code> even without the event pipeline. Read them from <code>getTokenUsage()</code> and only fall back to the character estimate when the provider returns no usage data.</li> <li>Pass the real cached-token count instead of a hardcoded 0.</li> </ul> <h3>Verification done</h3> <ul> <li>Unit tests: real token counts (input 42 / output 17 / cached 5 from a mocked provider) reach <code>logUsage()</code> unchanged; the character estimate only applies when the returned <code>TokenUsageDto</code> is empty.</li> <li>Full module suite green (129 tests, 496 assertions), PHPCS (Drupal, DrupalPractice) and PHPStan clean on the changed files.</li> <li>End to end on a live site (Drupal 11.3.12, drupal/ai 1.4.3, PHP 8.4.17, ai_provider_anthropic as cloud provider, ai_provider_ollama llama3.2:3b as fallback): user at 2,248/3,000 tokens, a 4,640-char translate_text triggers the lookahead reroute. The usage log records provider ollama, operation translate_text_fallback, 944 input / 174 output tokens. Those are the real llama3.2:3b tokenizer counts; the character estimate would have logged roughly 1,209 input tokens, a 22% error on a single call.</li> <li>No duplicate rows: the outer wrapper call returns early on <code>setForcedOutputObject()</code> before any post event, and the inner raw-plugin call fires no events. Exactly one row per fallback call.</li> </ul> <h3>Remaining tasks</h3> <ul> <li>Open MR against 1.0.x</li> <li>Review</li> </ul> <h3>User interface changes</h3> <p>None. Reroute behavior is unchanged; token counts in the log become accurate for fallback calls.</p> <h3>API changes</h3> <p> Raises the drupal/ai dependency to ^1.4.2. No changes to ai_metering's own API. </p> <p> Release impact: this ships in the next release (1.0.0-beta2). Sites on older<br> drupal/ai are unaffected: Composer keeps them on beta1 until they update<br> drupal/ai to 1.4.2 or later. The beta2 release notes must state the raised<br> requirement. </p> <h3>Data model changes</h3> <p>None.</p> <h3>AI assistance</h3> <p>The investigation, patch and tests were produced with AI assistance, then verified end to end on a live site as described above.</p>