allow reasoning details to pass through

[xzrderek]

Note

Surfaces provider_specific_fields (including reasoning_details) from LiteLLM responses and preserves reasoning_details in conversation history; adds a unit test.

• Policy:
  • LiteLLMPolicy._make_llm_call: Return provider_specific_fields on the message; simplify tool_calls extraction via a single message_obj.
  • Message cleaning: Allow reasoning_details in _clean_messages_for_api.
  • Conversation history: In LLMBasePolicy, propagate provider_specific_fields.reasoning_details into assistant message as reasoning_details.
• Tests:
  • Add tests/test_litellm_policy_provider_fields.py to verify provider_specific_fields (incl. reasoning_details and other fields) are preserved.

^{Written by Cursor Bugbot for commit 16ffbac. This will update automatically on new commits. Configure here.}

[cursor]

Bug: Field name mismatch: reasoning_details vs reasoning_content

The new code uses reasoning_details as the field name, but the rest of the codebase (including the Message model in eval_protocol/models.py and the langchain adapter) uses reasoning_content. LiteLLM's documentation also uses reasoning_content. If LiteLLM returns the reasoning in a field called reasoning_content via provider_specific_fields, checking for message.get("reasoning_details") would return None and the reasoning content wouldn't be captured. Similarly, adding reasoning_details to allowed_fields wouldn't preserve the actual reasoning_content field.

Additional Locations (1)

• eval_protocol/mcp/execution/policy.py#L148-L149