Summary

litellm.utils._remove_strict_from_schema (litellm/utils.py L3449 on main) is intended to strip OpenAI's tools-API strict: bool keyword from JSON Schemas before sending to providers that don't accept it (e.g. Gemini). The implementation recursively visits every dict in the schema tree and deletes any key literally named "strict", which conflates two different things:

1. The OpenAI tools-API keyword strict at the function-declaration root (should be stripped — intended behavior).
2. A user-defined property name "strict" inside a properties block (should not be touched — accidental over-strip).

The over-strip also doesn't update the schema's required array, so the property gets deleted but its name stays in required, producing a schema that references a property that doesn't exist.

When the resulting schema reaches Vertex AI's cachedContents endpoint (via litellm/llms/vertex_ai/context_caching/vertex_ai_context_caching.py), Vertex returns 400:

CreateCachedContentRequest.cached_content.tools[0]
  .function_declarations[N].parameters
  .properties[...].required[N]: property is not defined

Minimal reproduction (pure Python — no provider call needed)

from litellm.utils import _remove_strict_from_schema

schema = {
    "type": "object",
    "properties": {
        "strict": {"type": "boolean", "description": "User-defined property literally named 'strict'"},
        "field":  {"type": "string"},
    },
    "required": ["strict", "field"],
}

_remove_strict_from_schema(schema)
print(schema)

Expected: schema unchanged (no top-level strict keyword to strip).

Actual:

{
    "type": "object",
    "properties": {
        "field": {"type": "string"}      # strict deleted
    },
    "required": ["strict", "field"]      # but still listed as required → references missing property
}

End-to-end reproduction (real provider call)

Send an Anthropic-format request via the proxy with a tool whose parameters contain a property named strict, and route to a Vertex-AI Gemini model:

curl -sS "$LITELLM/v1/messages" \
  -H "x-api-key: $KEY" -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "<gemini-routed alias>",
    "max_tokens": 64,
    "messages": [{"role":"user","content":"hi"}],
    "tools": [{
      "name": "demo",
      "description": "demo",
      "input_schema": {
        "type": "object",
        "properties": {
          "strict": {"type":"boolean"},
          "field":  {"type":"string"}
        },
        "required": ["strict","field"]
      }
    }]
  }'

Result: 400 from Vertex with required[N]: property is not defined (context caching is the default path for tool-heavy requests in 1.81.x).

Affected versions

• Verified on v1.81.3-stable.
• Same code present on main (commit at time of filing).
• The function has had this shape since the originally-referenced issues (#6136, #6088).

Suggested fix

The intent is to strip the OpenAI keyword wherever it appears as a schema field. Property names inside a properties block aren't schema fields — they're user-defined identifiers. Recurse into properties values without treating the keys as schema dictionaries:

def _remove_strict_from_schema(schema):
    if isinstance(schema, dict):
        schema.pop("strict", None)
        for key, value in schema.items():
            if key == "properties" and isinstance(value, dict):
                # property names are user-defined identifiers, not schema keywords
                for prop_schema in value.values():
                    _remove_strict_from_schema(prop_schema)
            else:
                _remove_strict_from_schema(value)
    elif isinstance(schema, list):
        for item in schema:
            _remove_strict_from_schema(item)
    return schema

Defense-in-depth follow-up: reconcile required[] against properties after the strip (drops dangling references to keys that were removed for any reason). The per-key recursion fix above is the minimal correctness fix.

How we hit this

A canopy-runtime plugin in our internal hosted-LLM gateway had a Zod schema with a user-defined property strict: z.boolean(). We sent it via POST /v1/messages to a model alias routed to Vertex Gemini. The cron-driven failure ran every ~25 min on prod for several hours before being noticed; we patched on our side by renaming the user-facing property (strict → strictMode). Filing upstream so the next caller doesn't lose the same time.

Happy to send a PR with the fix + a unit test if it'd be useful.