usingModelPreference() with an unrecognized model id silently falls back to the provider default (cost risk)

[lezama]

Summary

Requesting a model id that the resolved provider doesn't expose does not error — the SDK silently generates with the provider's default model. A typo, a stale id, or a non-dated alias silently routes traffic to a potentially far more expensive model (e.g. Haiku → Opus, ~15×) with no signal to the caller.

Repro

Anthropic provider registered (its catalog exposes claude-haiku-4-5-20251001, not a bare claude-haiku-4-5):

$result = wp_ai_client_prompt( 'Reply with one word: ok' )
    ->using_model_preference( 'claude-haiku-4-5' )   // not an id the provider exposes
    ->generate_text_result();

$result->get_model_metadata()->get_id(); // => "claude-opus-4-8"  (the provider default)

No exception, no WP_Error, no warning — just a silent upgrade to the default (most capable / priciest) model. The same happens for any unrecognized id.

Impact

Surprise billing. Demo/bundled agents and any config typo silently run on the priciest model, and the substitution is invisible unless the caller inspects the resolved model id on every response. (Downstream, openclaWP shipped agents configured for claude-haiku-4-5 that were silently served by Opus.)

Expected (any of)

1. Throw / return WP_Error when a specific (non-auto) requested model id isn't available from the resolved provider.
2. Resolve documented non-dated aliases (claude-haiku-4-5 → latest matching dated model), mirroring the providers' own alias behavior.
3. At minimum, surface the substitution (warning / a flag on the result) so callers can detect "you asked for X, you got Y."

Notes

If the alias-resolution belongs in the individual provider plugins (e.g. ai-provider-for-anthropic) rather than the core client, happy to redirect — but the silent-fallback-to-default behavior on an unknown id looks like a core model-resolution concern. Reproduced on the php-ai-client bundled with WordPress 7.0.

[alewolf]

When a model preference is stated and can't be honored, then throwing an error is the most logical action that should be taken (instead of silently falling back to the most modern and expensive model).

Falling back to the least expensive model would be nice, but the providers usually don't expose the price in the model meta data. For now this is not a route that makes sense implementing.

[lezama]

When a model preference is stated and can't be honored, then throwing an error is the most logical action that should be taken (instead of silently falling back to the most modern and expensive model).

agreed!