Support both dict and object for _process_response

[kalanyuz]

With @TomeHirata 's #8692 that adds support for ResponseAPI, we can already actually use OpenAI's native tools like web_search or interpreter by initiating dspy.LM as the following:

        lm = LM(
            'openai/gpt-5',
            max_tokens=100_000,
            temperature=1.0,
            api_key=os.getenv("OPENAI_API_KEY"),
            model_type="responses",
            cache=False,
            text={
                "verbosity": "low"
            },
            tools=[{"type": "web_search_preview"}, {"type": "code_interpreter", "container": {"type": "auto"}}],
        )

        dspy.configure(lm=lm)

However, the current version of dspy would always fail, saying the response doesn't have the property type.

Upon debugging further, I found out that this is because base_lm undergoes litellm's wrapper function that transform each item in output as object. However they haven't added support for web_search_call or interpreter yet, therefore returning a simple dictionary. This causes the dspy to fail despite having the capability to return results.

This pull request refactors the _process_response method in dspy/clients/base_lm.py to add dict support so that dspy does not have to wait for litellm to add support for those objects.

[Copilot]

Pull Request Overview

This PR enables _process_response to handle both object attributes and dictionary keys when processing OpenAI's native tools like web_search and interpreter. The change addresses a compatibility issue where litellm returns dictionaries for some tool responses instead of objects, causing DSPy to fail when accessing the type property.

• Adds a helper function to safely access both object attributes and dictionary keys
• Updates response processing logic to work with both object and dictionary formats
• Maintains backward compatibility with existing object-based responses

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[okhat]

Thanks so much @kalanyuz !! Any chance some of the things in this PR should be (or even have been already) fixed upstream in LiteLLM instead?

[kalanyuz]

@okhat I believe this issue is unique to dspy side due to its tight coupling with LiteLLM for it's usage tracking implementation. We can contribute to LiteLLM by adding more transformations but it'd probably be come a cat-and-mouse game where dspy would break every time a model provider decides to introduce a new object / features in the 'usage' object.

Would giving dspy the ability to fall back on basic dictionary make it more futureproof in this case?

[TomeHirata]

While I'd prefer to support this in litellm for the proper fix, I'm fine with the safely measure in dspy. Btw, should we convert the response into dict first so that we don't need to check the field and key every time?

[kalanyuz]

@TomeHirata is this better?

[TomeHirata]

can we do isinstance(obj, BaseModel) instead?

[TomeHirata]

What is if not k.startswith("_") for?