[QUESTION] Is it necessary to include inputItems when creating CreateResponseOptions?

[The-Mojoo]

How can we help?

old inputItems
new inputItems

As shown in the two hyperlinks above, there are two methods.
After I updated to 2.8, I need to repeatedly create the CreateResponseOptions object in a do-while loop, even though the only thing I change is the inputItems parameter.
The contents inside CreateResponseOptions do not need to change, and repeatedly creating it feels very inelegant.

I don’t quite understand why this change is necessary.

[rodriciru]

Why do you set InputItems to only get and not set? (The comment on top of the property says it can be set):

    // CUSTOM: Renamed.
    /// <summary>
    /// Gets or sets the input items to be processed for the response. This corresponds to the "input" property in the JSON representation.
    /// </summary>
    [CodeGenMember("Input")]
    public IList<ResponseItem> InputItems { get; }

With set() I just can do creationOptions.InputItems = inputItems; no need to fancy code (as a BinaryContent) or creationOptions.InputItems.Add() if later on i will need to add some text content

[jsquire]

Hi @The-Mojoo. Thanks for reaching out and for your inquiry. The change was made as part of a design shift intended to move the .NET types into more alignment with the REST API shape for the OpenAI service. The Responses feature is the first application, but this will be a direction that all features are moving.

In the case of option types, there are two key goals:

• Ensure concurrency safety: The previous implementation used the same options pattern to form the payload for the service operation. However, it did transformations as part of the call that mutated the options to unify with the input items and client model, which initially caused non-obvious issues when trying to make calls concurrently using the same options instance. While this was worked around for responses, the workaround itself has some unfortunate trade-offs. In moving to a more REST-aligned set of types, we'll be able to serialize without mutation.

• Avoid hidden performance costs: The work-around for avoiding the race condition with mutations involves the client cloning the options for each call, so that the mutation takes place safely. This unfortunately means that every operation has hidden allocations beyond serialization and HTTP calls putting pressure on applications. Given that some options instances can be large, this is not always a trivial cost. In addition, the clone is shallow to try and control the cost which adds risk for object hierarchies which may be assumed as safe to mutate but may not be.

The contents inside CreateResponseOptions do not need to change, and repeatedly creating it feels very inelegant.

There should be no need to recreate the options if all you're looking to do is manipulate the input items. The set can be mutated on the existing options instance, for example, a common pattern of building conversation history would look something like:

var client = new ResponsesClient("gpt-5.1", "<< YOUR API KEY >>");

var options = new CreateResponseOptions([ResponseItem.CreateUserMessageItem("What is 2+2?")])
{
    Instructions = "You are Terry Crews and you've had 12 cans of Red Bull so far today.  You are PUMPED and eager to help!"
};

ResponseResult response;
var sum = 3;

while (true)
{
    response = await client.CreateResponseAsync(options);
    
    // Extract the response and preserve it in the conversation history.
    var assistantResponse = response.GetOutputText();
    options.InputItems.Add(ResponseItem.CreateAssistantMessageItem(assistantResponse));

    // If we have iterations remaining, ask a new question.
    if (++sum < 5)
    {
        options.InputItems.Add(ResponseItem.CreateUserMessageItem($"What is {sum} + {sum}?"));
    }
    else
    {
        break;
    }
}

// Do Something with results.

[jsquire]

@rodriciru: Pre-created read-only collection type are an intentional convention across types in the library. As you mentioned, their value can be set by mutating the existing collection. More context around why this pattern exists can be found in the discussion thread for #470.