fix(h2o): require both a configured ceiling and an Azure route, not either

Whether an Azure deployment wants max_tokens or max_completion_tokens is a
function of its api_version, not of it being Azure, and the same model name
can differ between deployments. An entry can state it explicitly:
use_max_completion_tokens: false, which is how an older api_version
deployment is expressed, generates max_tokens as the ceiling with NO
max_completion_tokens and NO drop. Treating the Azure route alone as
sufficient renamed the caller's value on exactly those deployments,
overriding a deliberate operator choice.

The predicate now fires on the drop list, or on a configured
max_completion_tokens AND an Azure route. Both of the latter are needed:
the ceiling alone is set for every reasoning model, Azure or not, and
firing on a non-Azure provider strips max_tokens from one that needs it;
the route alone hits the case above. Requiring both also keeps reasoning
Azure entries covered, which carry a ceiling but are exempt from the drop.

Verified against the actual output of convert_model_to_litellm_config for
four deployment shapes rather than hand-written kwargs: azure
non-reasoning renames, azure reasoning renames, azure with
use_max_completion_tokens=false does not, bedrock does not.

Tests: 24. The two new ones fail on the previous head.

Reported by jon: deployments differ by api_version + model name, not by
provider alone.

Author: achraf-mer

litellm/integrations/h2o/litellm_max_tokens_rename_hook.py

@@ -48,17 +48,26 @@
 
   * the call is a chat completion, and
   * the request carries a positive integer `max_tokens`, and
-  * the selected deployment is one that discards or rejects `max_tokens`,
-    i.e. it lists `max_tokens` in `additional_drop_params`, or it is an Azure
-    route.
-
-A configured `max_completion_tokens` is deliberately NOT a trigger on its own.
-`convert_model_to_litellm_config` sets it for every reasoning model, Azure or
-not (`use_completion_tokens = is_reasoning_model or is_azure_provider`), and
-only the Azure branch adds the drop. Treating it as a trigger would strip
-`max_tokens` from non-Azure providers that need it, leaving those requests with
-no ceiling at all, which is worse than the bug being fixed. It also cannot be
-distinguished from a caller-supplied value once kwargs are merged.
+  * the selected deployment lists `max_tokens` in `additional_drop_params`,
+    OR it has a configured `max_completion_tokens` AND is an Azure route.
+
+Neither of those last two signals is sufficient alone, and they fail in
+opposite directions.
+
+`max_completion_tokens` alone is too broad: `convert_model_to_litellm_config`
+sets it for every reasoning model, Azure or not
+(`use_completion_tokens = is_reasoning_model or is_azure_provider`), and only
+the Azure branch adds the drop. Firing on a non-Azure provider would strip
+`max_tokens` from one that needs it, leaving the request with no ceiling at
+all, which is worse than the bug being fixed.
+
+An Azure route alone is also too broad: whether an Azure deployment wants
+`max_tokens` or `max_completion_tokens` depends on its api_version, not merely
+on being Azure, and the same model name can differ between deployments. An
+entry can say so explicitly, and `use_max_completion_tokens: false` (how an
+older api_version deployment is expressed) generates `max_tokens` as the
+ceiling with NO `max_completion_tokens` and NO drop. Renaming there would
+override a deliberate operator choice.
 
 Deployments that natively accept `max_tokens` (Anthropic, Bedrock, vLLM,
 non-2025 Azure) are left untouched, including when they share a model group
@@ -150,15 +159,38 @@ def _deployment_discards_max_tokens(kwargs: Dict[str, Any]) -> bool:
         Read straight off the merged kwargs rather than the router, so a mixed
         model group is judged per selected deployment instead of per group.
         """
+        # The explicit signal: convert_model_to_litellm_config decided this
+        # deployment discards max_tokens, so the caller's value can only
+        # survive as max_completion_tokens.
         drop = kwargs.get("additional_drop_params") or []
         if isinstance(drop, (list, tuple)) and "max_tokens" in drop:
             return True
-        # Azure 2025+ rejects max_tokens outright. Reasoning Azure entries are
-        # exempt from the drop above but still need the rename, so recognise
-        # the route itself. custom_llm_provider is not always populated at this
-        # point, so the prefixed model string is the primary signal.
+
+        # Otherwise require BOTH signals: a configured max_completion_tokens
+        # AND an Azure route. Either one alone is too broad, in opposite
+        # directions:
+        #
+        #   max_completion_tokens alone -- convert_model_to_litellm_config sets
+        #   it for every reasoning model, Azure or not, and only the Azure
+        #   branch adds the drop. Firing on a non-Azure provider would strip
+        #   max_tokens from one that needs it, leaving no ceiling at all.
+        #
+        #   Azure route alone -- whether an Azure deployment wants max_tokens
+        #   or max_completion_tokens depends on its api_version, not just on
+        #   being Azure, and the entry can say so explicitly. An entry with
+        #   `use_max_completion_tokens: false` (how an older api_version
+        #   deployment is expressed) generates max_tokens as the ceiling, NO
+        #   max_completion_tokens and NO drop. Renaming there would override a
+        #   deliberate operator choice.
+        #
+        # Requiring both leaves that case alone while still covering reasoning
+        # Azure entries, which carry a ceiling but are exempt from the drop.
+        if kwargs.get("max_completion_tokens") is None:
+            return False
         if kwargs.get("custom_llm_provider") == "azure":
             return True
+        # custom_llm_provider is not always populated at this point, so the
+        # prefixed model string is the primary Azure signal.
         model = kwargs.get("model")
         return isinstance(model, str) and model.startswith("azure/")
 

tests/test_litellm/integrations/h2o/test_max_tokens_rename_hook.py

@@ -138,15 +138,35 @@ async def test_malformed_drop_params_never_propagates(hook):
 
 
 @pytest.mark.asyncio
-async def test_azure_route_alone_triggers_the_rename(hook):
+async def test_azure_route_with_a_ceiling_triggers_the_rename(hook):
     """Reasoning Azure entries get max_completion_tokens but are exempt from
-    the drop, so the route itself has to be recognised."""
+    the drop, so route + ceiling has to be recognised without one."""
     out = await _run(hook, {"model": "azure/gpt-5-mini", "max_tokens": 50,
                             "max_completion_tokens": 16384})
     assert out["max_completion_tokens"] == 50
     assert "max_tokens" not in out
 
 
+@pytest.mark.asyncio
+async def test_azure_deployment_that_wants_max_tokens_is_untouched(hook):
+    """An Azure entry with `use_max_completion_tokens: false`, which is how an
+    older api_version deployment is expressed, generates max_tokens as the
+    ceiling with no max_completion_tokens and no drop. Whether Azure wants
+    max_tokens or max_completion_tokens is a function of api_version, not of
+    being Azure, so treating the route alone as sufficient would override a
+    deliberate operator choice on exactly these deployments."""
+    out = await _run(hook, {"model": "azure/gpt-4o-mini", "max_tokens": 50,
+                            "api_version": "2024-02-01"})
+    assert out is None
+
+
+@pytest.mark.asyncio
+async def test_azure_route_without_a_ceiling_or_drop_is_untouched(hook):
+    """Same rule stated directly on the predicate: route alone is not enough."""
+    out = await _run(hook, {"model": "azure/gpt-4o-mini", "max_tokens": 50})
+    assert out is None
+
+
 @pytest.mark.asyncio
 async def test_non_azure_ceiling_alone_does_not_trigger_the_rename(hook):
     """convert_model_to_litellm_config sets max_completion_tokens for EVERY