>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3615561. --> Reported by: [camoa](https://www.drupal.org/user/2448054) Related to !54 >>> <h3>Problem/Motivation</h3> <p><code>TokenEstimator::selectModel()</code> (<code>src/Service/TokenEstimator.php:52-67</code>) has no caller. A module-wide search for <code>selectModel</code> &mdash; including <code>.module</code>, <code>.install</code>, <code>.inc</code>, Drush commands, Twig, JS, YAML and the test suite &mdash; returns exactly one line: its own definition. There is no production caller and no unit test.</p> <p>No dynamic dispatch can reach it either. The module's only dynamic call sites are <code>method_exists()</code> probes on AI response objects (<code>AiPostGenerateSubscriber.php:243-333</code>) and <code>$provider-&amp;gt;{$camelMethod}()</code> on a ProviderProxy (<code>AiPreGenerateSubscriber.php:276</code>); neither can dispatch to this method.</p> <p>Four of the five <code>model_routing</code> config keys &mdash; <code>small_threshold</code>, <code>large_model</code>, <code>small_label</code>, <code>large_label</code> &mdash; are read only by <code>selectModel()</code>, so they drive nothing. The fifth, <code>small_model</code>, has one other reader elsewhere in <code>TokenEstimator</code>.</p> <p><strong>Why this matters beyond dead code:</strong> <code>README.md:16</code> advertises "Two-tier model routing" as a feature. The settings form at <code>/admin/config/ai/ai-metering/settings</code> exposes no fields for it, so an operator who wants it must set the config via <code>drush config:set</code> or a config import. Having done so, nothing happens &mdash; every AI call still uses whatever model the <code>ai</code> module's provider default or the calling feature selects. The module documents a cost-control capability it does not perform, and the operator has no feedback indicating that.</p> <p>Note this is distinct from the pre-generate reroute to a local fallback provider in <code>AiPreGenerateSubscriber</code>, which is a separate mechanism and is wired up. Only the <code>selectModel()</code> two-tier routing path is dead.</p> <h3>Steps to reproduce</h3> <ol> <li>Set the <code>model_routing</code> keys in <code>ai_metering.settings</code> via <code>drush config:set</code> (they cannot be set through the UI), giving <code>small_model</code> and <code>large_model</code> two distinct, clearly identifiable models and a <code>small_threshold</code> that the next prompt will fall below.</li> <li>Issue an AI call whose prompt is below the threshold, then inspect which model was actually used &mdash; via the usage log at <code>/admin/reports/ai-metering</code> or the provider's own logs. The configured small model is not selected; routing never occurs.</li> </ol> <h3>Environment</h3> <ul> <li>Drupal version: n/a &mdash; not reproduced on a running site, see AI assistance note</li> <li>ai_metering version: 1.0.x at commit a39fea9</li> <li>AI provider module + version: provider-independent</li> <li>AI feature module tested: none &mdash; found by code inspection</li> </ul> <h3>Proposed resolution</h3> <p>Decide whether two-tier routing is a feature this module should own, then make code and documentation agree. Either:</p> <ul> <li><strong>Implement it</strong> &mdash; call <code>selectModel()</code> from the pre-generate path, expose the <code>model_routing</code> keys in the settings form, and cover it with tests; or</li> <li><strong>Remove it</strong> &mdash; delete <code>selectModel()</code>, the four unused config keys and their config schema, and the README claim, with an update hook to clean stale config from existing sites.</li> </ul> <p>Removal is the smaller change and fits a metering module's scope; implementing it means owning model-selection policy, which arguably belongs to the <code>ai</code> module or the calling feature. Worth a maintainer decision rather than a default.</p> <h3>Remaining tasks</h3> <ul> <li>Maintainer decision: implement or remove.</li> <li>If removing, add an update hook to delete the orphaned config keys and update <code>README.md:16</code> and any docs that mention routing.</li> <li>If implementing, expose the keys in <code>MeteringSettingsForm</code> &mdash; config-only features with no UI are effectively undiscoverable.</li> <li>Either way, add a test so the dead-code state cannot recur silently.</li> </ul> <h3>User interface changes</h3> <p>If implemented, new fields in the settings form. If removed, the README feature claim goes away. No change to existing screens either way.</p> <h3>API changes</h3> <p><code>TokenEstimator::selectModel()</code> is a public method on a public service. It has no in-module callers, but removing it is still an API change for any site or contrib module calling it directly &mdash; worth a deprecation cycle rather than an outright delete.</p> <h3>Data model changes</h3> <p>None. Config-only: the <code>model_routing</code> keys and their schema entries.</p> <h3>AI assistance</h3> <p>AI-Generated: Yes (Claude Code &mdash; multi-agent code analysis found the unreferenced method, and a follow-up pass verified the absence of any caller including dynamic dispatch; this issue text was drafted with AI assistance). No module code was generated. Every claim is code-cited and was reviewed before filing; the searches behind the absence claim can be re-run against the referenced paths.</p>