TemporalAgent drops openai_ reasoning effort

[leecjohnny]

Initial Checks

• I confirm that I'm using the latest version of Pydantic AI
• I confirm that I searched for my issue in https://github.com/pydantic/pydantic-ai/issues before opening this issue

Description

To reproduce:

1. run the example code
2. review the https request to OpenAI logged in logfire for the 2 runs

For temporal agent request body:

{
  "messages": [
    {
      "content": "You're an expert in geography.",
      "role": "system"
    },
    {
      "role": "user",
      "content": "What is the capital of Mexico?"
    }
  ],
  "model": "gpt-5-nano",
  "stream": false
}

For normal agent request body:

{
  "messages": [
    {
      "content": "You're an expert in geography.",
      "role": "system"
    },
    {
      "role": "user",
      "content": "What is the capital of Mexico?"
    }
  ],
  "model": "gpt-5-nano",
  "reasoning_effort": "high",
  "stream": false
}

Example Code

import asyncio
import uuid

import dotenv
import logfire
from pydantic_ai import Agent
from pydantic_ai.durable_exec.temporal import (
    AgentPlugin,
    PydanticAIPlugin,
    TemporalAgent,
)
from pydantic_ai.models.openai import OpenAIChatModelSettings
from temporalio import workflow
from temporalio.client import Client
from temporalio.worker import Worker

dotenv.load_dotenv()
logfire.configure(
    scrubbing=False,
)
logfire.instrument_openai(suppress_other_instrumentation=False)
logfire.instrument_pydantic_ai()
logfire.instrument_httpx(capture_all=True)

agent = Agent(
    "gpt-5-nano",
    instructions="You're an expert in geography.",
    name="geography",
    model_settings=OpenAIChatModelSettings(
        openai_reasoning_effort="high",
    ),
)

temporal_agent = TemporalAgent(agent, name="temporal_geography")


@workflow.defn
class GeographyWorkflow:
    @workflow.run
    async def run(self, prompt: str) -> str:
        result = await temporal_agent.run(prompt)
        return result.output


async def main():
    client = await Client.connect(
        "localhost:7233",
        plugins=[PydanticAIPlugin()],
    )

    async with Worker(
        client,
        task_queue="geography",
        workflows=[GeographyWorkflow],
        plugins=[AgentPlugin(temporal_agent)],
    ):
        output = await client.execute_workflow(
            GeographyWorkflow.run,
            args=["What is the capital of Mexico?"],
            id=f"geography-{uuid.uuid4()}",
            task_queue="geography",
        )
        print(output)
        # > Mexico City (Ciudad de México, CDMX)
    normal_output = await agent.run("What is the capital of Mexico?")
    print(normal_output.output)


if __name__ == "__main__":
    asyncio.run(main())

Python, Pydantic AI & LLM client version

python-version = "3.12"

name = "openai"
version = "1.107.3"

name = "pydantic-ai-slim"
version = "1.0.8"

name = "temporalio"
version = "1.17.0"

[DouweM]

@leecjohnny Thanks for the report Johnny, fixed in #2938!

[leecjohnny]

@leecjohnny Thanks for the report Johnny, fixed in #2938!

Thanks for the quick work!

[fortzi]

@DouweM Thanks for all your work!

Somewhat related to this issue, what would you say is the best way to type a Pydantic field meant to store model settings? The most straightforward way is ofc ModelSettings, but as this issue points out, parsing it would drop other fields that only exist in more specific settings e.g. OpenAIResponsesModelSettings.

Does supporting this use case require changing how ModelSettings itself is defined (maybe as a union type)?

[DouweM]

@fortzi I was going to recommend SerializeAsAny[ModelSettings] to prevent subclass instances from being serialized using the parent class's rules, but that's not working as expected currently: pydantic/pydantic#12264

[fortzi]

Interesting. As @davidhewitt mentions in his comment, parsing is its own issue.

I was thinking about something similar to how ModelMessage is defined - you can use it to type any message without knowing which specific type you have. Do you think this method can be applied here?

[DouweM]

@fortzi That works because ModelRequest and ModelResponse both have a kind field that we can use as a discriminator to create the right instance. But ModelSettings doesn't have a discriminator, and TypedDicts cannot be instantiated anyway, so it'll require a different solution.

[fortzi]

@DouweM Would it be a breaking change though? If it's something you're willing to consider, I'll be more than happy to help with implementation :)

[DouweM]

@fortzi Yeah unfortunately I don't see a way to change this without a breaking change. I suggest just treating the model settings as an arbitrary dict[str, Any]

[Viicos]

Not sure exactly how ModelSettings are being represented, but maybe using generics could work (usually it's either using discriminated unions, or generics).