ChatGPT Can Build the Interface. Your App Still Has to Own the State

ChatGPT can now answer with an interface instead of another paragraph. A chart you can adjust. A diagram with parts you can select. A small calculator built around the question you just asked.

That is useful. It also changes what an answer appears to promise.

A paragraph looks like advice. A form with a button looks like software. Once a model produces controls, the builder has to ask a different question: what, exactly, does interacting with this thing change?

The interface can be generated. The contract around data, calculations, saved progress, and external actions should not be left to a guess.

What OpenAI actually launched

OpenAI announced GPT-6 and Intelligent UI on October 7, 2026. The company says ChatGPT can compose answers from text, graphics, tappable buttons, forms, charts, and interactive experiences. Its examples include a savings calculator, a bill splitter, and explanations that let you explore a diagram.

This is not a claim that every answer becomes an app. OpenAI says the model chooses a format based on the question and can still use plain text when that is more useful.

The implementation detail worth reading is the component library. OpenAI says it built native, streamable components and a compiler that processes the interface while the model generates it. The response can appear progressively rather than waiting for the whole interface to finish.

That is different from merely asking a model to write a page of HTML. A shared component library gives the model a design foundation. It does not, by itself, prove that every generated calculation or label is right.

Independent coverage gives a better feel for the experience than a feature list. TechCrunch describes a demonstration with adjustable graphs and task-specific calculators. WIRED's brief hands-on describes an apartment-affordability calculator with sliders and an airplane-seat explorer. Those are the reporters' experiences, not my own tests.

The interesting unit is no longer just the answer. It is the answer plus the interaction.

Check the product boundary before trying it

The announcement says the rollout began on October 7 for Plus, Pro, Business, and Enterprise, with Free and Go expansion starting October 8. A rollout date is not proof that a particular account already has access. Enterprise access also depends on workplace settings.

OpenAI's Help Center adds important distinctions:

• Intelligent UI is available with supported GPT-6 settings from Instant through Extra High, not at Pro effort.
• A Pro subscription and Pro effort are different things. The plan can have access while that effort setting does not support the feature.
• The capabilities are rolling out on the web and supported updated apps. Older macOS and Windows desktop apps do not support them; the guidance points those users to the web.
• There is no separate Intelligent UI usage quota. Existing model, tool, and plan allowances still apply.
• The web setting for Layout and visuals reduces visual elements. It does not guarantee a classic, text-only experience.

The release applies to ChatGPT's Chat experience. OpenAI says the models powering Work and Codex are not changing as part of this release. Do not read a ChatGPT product announcement as a promise that the same component system is available through your API integration.

TechRepublic and MacRumors corroborate the rollout and the component-based design. For actual access and controls, the provider's current help page is the better source.

Three kinds of interaction, three different promises

For builders borrowing this idea, I would divide generated interfaces by what they do. This is a design framework, not a description of OpenAI's internal architecture.

Interaction	Example	Contract to make explicit
Explore	Select a part of a diagram	What information is being shown, and where it came from
Calculate	Change inputs in a cost estimate	Formula, units, assumptions, and valid input range
Commit	Submit a change to an external system	Destination, exact effect, permission, and confirmed result

The first two can often live inside an answer. The third crosses a boundary.

A button that filters a chart is not equivalent to a button that changes a customer record. They may look identical. The application should make their effects impossible to confuse.

The more polished the interface, the more important that distinction becomes. Visual confidence is not evidence of correctness.

A calculator needs a formula, not just sliders

Consider a hypothetical tool for comparing delivery costs. It asks for parcel count, a per-parcel fee, and a fixed monthly charge. The formula is simple: parcel count times the per-parcel fee, plus the fixed charge.

A generated chart can make the comparison much easier to explore. But before treating it as a usable business tool, check what the chart actually computes:

• Are the inputs monthly or annual?
• Does the price include tax?
• Is the fixed charge applied once or once per parcel?
• Are empty and negative values rejected or handled clearly?
• Does the displayed total match a separate calculation for known inputs?

The numbers and provider terms should come from verified data. The formula should have tests. The model can choose a useful presentation without becoming the authority for every value behind it.

This is where the component approach has a useful lesson. Constrain the pieces. Let the model arrange an approved number input, a comparison table, and a chart. Keep the calculation function and validation rules outside the generated explanation.

That recommendation is for your own application. The launch announcement does not establish which execution or validation mechanisms ChatGPT uses for every generated tool.

A checked box is not a durable record

A checklist inside a chat can look like a workflow system. That does not settle where its state lives.

If you build a generated checklist into your product, define its persistence contract before it becomes something users rely on. Does a checked item survive a page refresh? A new browser? A second device? A new conversation? Can another authorized person see the change?

These are questions to test, not assumptions to make from the appearance of a control. The sources reviewed here do not establish a universal persistence guarantee for every Intelligent UI experience.

For a low-stakes scratchpad, temporary state may be enough. For a work tracker, store progress in the application's durable record and render from that record. The model should not be asked to remember which boxes were checked from the prose around them.

Separate three states in the design:

1. The user changed a control locally.

2. The application is saving the change.

3. The destination confirmed the saved value.

Showing "saved" at the first step makes the interface lie even if the model's text is perfect.

A generated action still needs a receipt

Suppose a hypothetical interface helps adjust support-ticket assignments. Selecting a teammate is local interaction. Submitting that assignment changes a shared system and affects another person's work.

Before submission, show the actual ticket, destination, and new assignee from current application data. After submission, show the stored result or a clear failure. If the request times out, check the destination before offering a retry that could duplicate the change.

The model can help assemble the view. It should not silently invent the recipient, infer permission from a label, or turn an optimistic animation into proof that the write landed.

That is the distinction I would keep fixed: generated presentation, deterministic commitment.

Test the interface like software

An output-quality check is still useful, but a generated interface needs more than a grader saying the answer looks good.

Test the controls with known cases. Check the formula separately. Reload after changing state. Simulate a failed save. Use the keyboard. Try a narrow screen and large text. Make sure a chart's important information is also available without relying only on color or hover.

Those are recommended tests, not reported failures in Intelligent UI. The point is to define the bar before adopting the pattern.

A plain-text fallback is part of that bar. Interactivity should help the user finish, not become the only way to read an answer. A comparison that works as a table may not need a slider at all.

OpenAI's announcement makes the direction clear: software can adapt its presentation around a person's question. The builder's responsibility stays familiar. Know where the data came from, know what the control changes, and know whether the result was actually saved.

Frequently asked questions

What is ChatGPT Intelligent UI?

A GPT-6 capability that combines text with visuals and interactive components inside an answer. OpenAI lists graphics, forms, charts, buttons, and small task-specific tools as possible outputs.

Does every answer use an interactive interface?

No. OpenAI says ChatGPT chooses the format based on the question and can still give a plain-text answer.

Does a Pro subscription guarantee Intelligent UI at Pro effort?

No. The subscription plan and thinking-effort setting are separate. The Help Center says Intelligent UI is supported from Instant through Extra High, but not at Pro effort.

Is there a separate usage quota?

OpenAI says there is no separate Intelligent UI quota. Existing model, tool, and plan allowances still apply.

Can I turn all visuals off?

The documented web setting reduces visual elements. OpenAI says some may still appear, so it is not a guaranteed text-only mode.

Does an interactive calculator guarantee correct results?

No such guarantee follows from the launch announcement. Check inputs, formulas, units, assumptions, and outputs before relying on a calculation, especially for business or financial decisions.

What should builders copy from this approach?

Use a constrained component library to make answers easier to explore. Keep verified data, calculation rules, durable state, and external-action confirmation under explicit application contracts.

Sources

• OpenAI launch announcement, October 7: features, component library, streaming compiler, rollout, and product scope.
• OpenAI Help Center: effort settings, supported apps, quota, and layout controls.
• TechCrunch, October 7: reporter-observed demonstration and interactive examples.
• WIRED, October 7: brief hands-on, including calculator and seat-map examples.
• TechRepublic, October 8: rollout, availability limits, and the need to check calculations.
• MacRumors, October 7: component architecture and Chat versus Work and Codex distinction.