Extensions

The Open Responses specification lets an implementer add fields under a namespaced prefix without changing any enum, union, or required field. This API’s prefix is helpingio:. A client that does not know the prefix can strip every helpingio: key and still parse the result. A client that does know it gets a strict superset.

What you may see in output

Responses, output items and function calls may carry helpingio: keys, or names under the prefix. Ignore any you do not recognize: they never change the shape of the object they sit on, so stripping the prefix always leaves a result your client can parse.

Four output names are documented:

• helpingio:error sits on a function_call_output that reports a call this API refused or a tool that failed, and carries a code and a message. See When this API refuses a call.
• helpingio:unreadable sits on a list of conversation items. It names each item on the page that is stored but could not be read, with its id, the code item_unreadable and a message. The other items are returned as usual, and the key is absent when every item was read. See List items.
• helpingio:tool_calls_dropped sits on a response that runs under a max_tool_calls. It is the number of tool calls cut from that response, past your max_tool_calls or past your organization’s limit for one turn, which were neither returned nor run. The key is absent when nothing was cut. See Compatibility and versioning.
• helpingio:warnings sits on a response that accepted a request field and did not apply it, or applied it in place of another. It is a list; each entry has a type (unsupported or compatibility), the param it is about, and a message for a person to read. Switch on type and param. The key is absent when there is nothing to report. The shape follows the call warnings of the Vercel AI SDK.

The helpingio: names that are public today:

• helpingio:error
• helpingio:tool_calls_dropped
• helpingio:unreadable
• helpingio:warnings

How extensions evolve

New extensions are added under the helpingio: prefix and nowhere else. A new field is a compatible change; renaming or removing one is a breaking change and would require a new API prefix. The full policy is on Compatibility and versioning.