For successive Astra turns through CometAPI, I would choose application-managed history when portability is a requirement—and treat stored-response references as a separate feature to validate, not an automatic consequence of endpoint compatibility.
The distinction comes from CometAPI’s September 9 GPT-6 Astra developer guide. It describes an OpenAI-compatible /v1/responses route, but its “How to Maintain Stateful Conversations” section gives the two approaches different levels of support: an explicit replay example using gpt-6-astra, versus a conditional mention of previous_response_id. This is a reading of that guide, not a report of tested gateway behavior.
What the replay example actually carries
The guide recommends resending “the user inputs and the model output items required by the next turn.” Its example extends history from response.output, serializing each item with model_dump(exclude={"id"}, exclude_none=True), then appends the follow-up user message and submits that history.
That is more specific than saving the text shown in a chat bubble. The function-calling section illustrates why: it preserves the model’s output items, then adds a function_call_output carrying the original call_id before requesting the next response.
The engineering implication is that a display transcript is not a substitute for the demonstrated tool conversation. If the application saves only assistant text, it has not preserved the output items and call associations shown in this example. Excluding an item’s id during serialization should not be confused with discarding the tool’s call_id.
For an application-managed implementation, my checklist would be:
- Keep the user inputs corresponding to the response being replayed; do not pair an output with a reconstructed but different prompt.
- Preserve the output items required for continuation, rather than rebuilding history from
output_textalone. - Keep each tool result associated with its original
call_id. - Validate both a plain follow-up and a tool-result continuation on the intended CometAPI Astra route before depending on the implementation.
These are design recommendations based on the guide’s examples, not a guarantee that the same history object will work unchanged across providers.
What the stored-reference sentence does not establish
The guide says: “Where supported by the provider, previous_response_id can reference a stored response instead.” It does not provide a request example exercising that path through CometAPI.
That leaves a concrete prerequisite: confirm stored-response continuation on the exact CometAPI route your application will use. I would include a tool interaction in that acceptance check, rather than accepting a successful one-turn request as evidence of conversation continuity.
Separately, establish the retention and deletion behavior your application needs, and decide how it should respond when a reference is unavailable. The guide does not specify those policies. Nor does it establish that identifiers transfer between providers, or that stored references improve billing, latency, or reliability. Missing documentation here is not proof that the feature is absent; it is a reason not to build on an assumed contract.
Decision: use explicit history as the documented starting point for a portable CometAPI Astra integration. Adopt stored references only after their support and lifecycle fit are established for your route. Either way, conversation state should preserve the interaction needed for the next turn—not merely the answer the user saw.