Repository navigation
Python: [Feature]: Foundry Hosting - Support conversation branching #8578
Description
Description
Feature request to support conversation branching when using Foundry Hosting. When having a conversation using the conversation parameter, users should be able to branch from an earlier response in the conversation by supplying previous_response_id from a previous response. This isn't currently possible, because state is stored by response ID or conversation ID, but not both.
This was previously raised in #7524, however it was closed as it was thought that the issue was due to not re-using the same session, however this is not the case.
Code Sample
from azure.ai.projects import AIProjectClient
from azure.identity import DefaultAzureCredential
endpoint = "https://<RESOURCE>.services.ai.azure.com/api/projects/<PROJECT>"
agent_name = "<AGENT>"
with (
DefaultAzureCredential() as credential,
AIProjectClient(
endpoint=endpoint,
credential=credential,
) as project_client,
):
openai_client = project_client.get_openai_client(agent_name=agent_name)
conversation = openai_client.conversations.create()
response = openai_client.responses.create(
input="What is 2+2?",
conversation=conversation.id,
)
agent_session_id = response.model_extra["agent_session_id"]
print(f"Response 1: {response.output_text}")
response2 = openai_client.responses.create(
input="Double it.",
previous_response_id=response.id,
extra_body={"agent_session_id": agent_session_id},
)
print(f"Response 2: {response2.output_text}")
print(f"Error: {response2.error}")Language/SDK
Python
Metadata
Metadata
Labels
Type
Projects
- Status
Activity
[-][Feature]: Foundry Hosting - Support conversation branching[/-][+]Python: [Feature]: Foundry Hosting - Support conversation branching[/+]Python: Foundry Hosting - support conversation branching (fixes micro…
eavanvalkenburg commentedon Sep 22, 2026
I am unsure if we should do this, the OpenAI Responses API explicitly does not allow the combined params (see here), so there is a good chance that some tools will also reject it even though it can be done here. Of course this being a open source SDK, there is nothing stopping you from implementing this behavior yourself, but building this in I don't think is a good idea at this time. CC westey (@westey-m)
cecheta commentedon Sep 22, 2026
Hi Eduard van Valkenburg (@eavanvalkenburg) ,
The linked PR is incorrect, the user should not supply both the conversation ID and the previous response ID.
By branching, I mean that a user starts by using a conversation ID, then when they want to branch, they supply the previous response ID from where they want to fork and use this ID instead of the conversation ID, such as in the example code in the issue. The OpenAI Responses API does support this.
Shivani767 commentedon Sep 22, 2026
Thanks Chinedum Echeta (@cecheta) for clarifying. I understand the intended flow now.
The branch request should not provide both
conversationandprevious_response_id. The expected flow is:conversation=conversation.id.previous_response_idfrom the response they want to fork from, instead of providing the conversation ID.My PR description currently describes this incorrectly as passing both parameters, so I'll correct that wording and make sure the implementation matches this API behavior.
Thanks for pointing this out.
eavanvalkenburg commentedon Nov 3, 2026
Darren Cohen (@dargilco) We can fold the clarified conversation-branching request into the current Foundry Hosting work. The intended flow is to start with
conversation, then branch on a later request using onlyprevious_response_id, not both fields together. Please coordinate that scope with the current history-source and provider continuation constraints before selecting an implementation. #7524 provides the earlier context; #8578 remains the live follow-up. This assignment is for coordination and design, not an implementation-ready decision or a promise of timing.