[Perf] Remove premature model.dump call on the hot path

[AlexsanderHamir]

Relevant issues

Previously, _extract_response_obj_and_hidden_params() called model_dump() on BaseModel objects immediately, converting them to dicts even when a dict wasn't needed. This caused:

• Unnecessary serialization overhead (identified as a bottleneck in profiling)

Pre-Submission checklist

Please complete all items before asking a LiteLLM maintainer to review your PR

• I have Added testing in the tests/litellm/ directory, Adding at least 1 test is a hard requirement - see details
• My PR passes all unit tests on make test-unit
• My PR's scope is as isolated as possible, it only solves 1 specific problem

CI (LiteLLM team)

CI status guideline:

• 50-55 passing tests: main is stable with minor issues.
• 45-49 passing tests: acceptable but needs attention
• <= 40 passing tests: unstable; be careful with your merges and assess the risk.

• Branch creation CI run
  Link: https://app.circleci.com/pipelines/github/BerriAI/litellm/54178/workflows/1985968c-1532-4f4c-9f40-aef08f52ad2d

• CI run for the last commit
  Link: https://app.circleci.com/pipelines/github/BerriAI/litellm/54285/workflows/692c5cc2-b257-4294-a613-a310573aaa7b

• Merge / cherry-pick CI run
  Links:

Type

🧹 Refactoring

Changes

Performance Optimization: Lazy BaseModel Serialization

Core Change:

• Removed early model_dump() call: _extract_response_obj_and_hidden_params() now returns Union[dict, BaseModel] instead of always converting BaseModel to dict
• Lazy serialization: model_dump() is now only called when a dict is actually required (in get_final_response_obj() for redaction/logging)

Implementation Details:

• Changed return type of _extract_response_obj_and_hidden_params() from Tuple[dict, Optional[dict]] to Tuple[Union[dict, BaseModel], Optional[dict]]
• Updated get_final_response_obj() to call _safe_model_dump() only when response_obj is a BaseModel
• Updated all downstream functions to handle both dict and BaseModel types

Defensive Helper Functions Added:

• _safe_model_dump(): Safely calls model_dump() with fallback strategies (__dict__, string conversion)
• _safe_get_attribute(): Safely extracts attributes from both dict and BaseModel objects
• _safe_extract_usage_from_obj(): Safely extracts usage from response objects
• _try_transform_response_api_usage(): Attempts ResponseAPIUsage transformation with error handling
• _try_create_usage_from_dict(): Attempts Usage creation from dict with error handling

Unit Test Results

• Failures seem to be unrelated.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Review	Updated (UTC)
litellm	Ready	Preview, Comment	Jan 14, 2026 8:36pm

To fix the problem, we need to stop logging potentially sensitive contents of the usage dict while still preserving enough information for debugging. The problematic line is the debug log in _try_create_usage_from_dict, which currently formats and logs the complete usage dict when constructing a Usage object fails.

The best fix with minimal behavior change is:

• Keep catching the exception and returning None as before.
• Change the log message to:
  • Omit the usage value.
  • Optionally log non-sensitive structural information, such as the keys present in usage and the type, which is sufficient for debugging schema mismatches.
• Ensure no additional sensitive fields are logged as raw values.

Concretely:

• In litellm/litellm_core_utils/litellm_logging.py, in _try_create_usage_from_dict, replace:

except (TypeError, ValueError) as e:
    verbose_logger.debug(f"Error creating Usage from dict: {e}, usage: {usage}")
    return None

with something like:

except (TypeError, ValueError) as e:
    try:
        usage_keys = list(usage.keys())
    except Exception:
        usage_keys = None
    verbose_logger.debug(
        "Error creating Usage from dict: %s, usage keys: %s, usage type: %s",
        e,
        usage_keys,
        type(usage),
    )
    return None

This preserves error context (exception and shape of the dict) while avoiding logging dict values.

No other files require changes for this specific alert, because the root issue is the sink (the logging of usage), and fixing that sink addresses all variants that flow into this location.

---