Feat/OpenAI responses api 3209

[FrigaZzz]

TL;DR: Adds first-class ADK support for the OpenAI Responses API (including Azure OpenAI) via a new labs.openai_responses module. Fully additive, zero changes to existing core model APIs, 33/33 unit tests passing, plus a working Azure E2E sample.

Link to Issue or Description of Change

1. Link to an existing issue (if applicable):

• Closes: Support for OpenAI Responses API #3209

Problem

ADK has no built-in LLM implementation for the OpenAI Responses API. Anyone who wants to use OpenAI or Azure OpenAI Responses API models today has to hand-roll their own request conversion, response parsing, streaming handling, tool-call mapping, and usage-metadata handling.

Solution

This PR adds OpenAIResponsesLlm and AzureOpenAIResponsesLlm, giving ADK native, drop-in support for Responses API models:

• Request conversion — ADK LlmRequest → Responses API responses.create parameters, covering contents, system instructions, tools, tool responses, and generation config.
• Response parsing — Responses API output → ADK LlmResponse, including text, function calls, reasoning parts, finish reasons, interaction IDs, model versions, and usage metadata.
• Streaming — full event-stream handling, including partial text/reasoning deltas and final response aggregation.
• Azure support — Azure OpenAI-compatible client via the /openai/v1/ base URL.
• Metadata passthrough — optional raw OpenAI response metadata exposed on LlmResponse.custom_metadata via include_response_metadata.
• Sample — contributing/samples/models/hello_world_azure_openai_responses, a runnable Azure OpenAI Responses reference for manual E2E validation.

This lands under google.adk.labs.openai_responses — it's additive and opt-in, with no changes to any existing core model API.

Testing Plan

Unit Tests ✅

33/33 passing locally, covering request-shape conversion, typed and mapping-based response parsing, function calls, reasoning metadata, usage metadata, streaming aggregation, failed-stream handling, Azure base-URL construction, and the custom_metadata opt-out.

uv run pytest tests/unittests/labs/openai_responses/test_openai_responses_llm.py
# 33 passed, 4 warnings in 1.14s

Formatted with pyink:

uv run pyink src/google/adk/labs/openai_responses/_openai_responses_llm.py tests/unittests/labs/openai_responses/test_openai_responses_llm.py

Manual End-to-End (E2E) Tests ✅

Verified live against Azure OpenAI Responses using the included sample:

cd contributing/samples/models/hello_world_azure_openai_responses
python main.py
# ALL MANUAL E2E TESTS PASSED

Covers: basic text generation, function calling + function-response handling, multi-turn context preservation through the runner, and direct previous_response_id chaining.

Checklist

• I have read the [CONTRIBUTING.md](https://github.com/google/adk-python/blob/main/CONTRIBUTING.md) document.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have added tests that prove my fix is effective or that my feature works.
• New and existing unit tests pass locally with my changes.
• I have manually tested my changes end-to-end.
• Any dependent changes have been merged and published in downstream modules.

Additional Context

This lives under google.adk.labs.openai_responses — a labs integration rather than a stable core model API — so it can land and iterate quickly without being bound to core API-stability guarantees, while still being fully usable today.

The unit test suite targets the conversion and parsing logic directly (request shape, typed vs. mapping-based responses, function calls, reasoning metadata, usage metadata, streaming aggregation, failure paths, Azure URL construction, and metadata opt-out), so regressions in any of these areas should surface immediately.

The hello_world_azure_openai_responses sample doubles as living documentation: it shows the exact setup and commands needed to validate the integration against a real Azure OpenAI Responses deployment.