OpenAI turns general-purpose models into tools for work and applications

OpenAI develops AI models and provides the applications and developer interfaces through which people use them. ChatGPT and Codex give users working environments; the API platform lets developers add model capabilities to their own products. Those are related offerings with different buying and implementation decisions. This blueprint explains the current model family, the main integration choices and a concrete document-intake example, using public primary sources checked on 15 September 2026. It does not claim independent benchmark or hands-on test results.

01 / ProductWhat OpenAI offers today

The current model catalog¹ positions GPT-6 Astra for demanding reasoning and coding, GPT-5.6 Sol for professional work, Terra for a balance of capability and cost, and Luna for high-volume tasks where cost matters. The catalog also includes dedicated image, voice and transcription models. Model choice should follow the required behavior and input type, rather than assuming the most prominent model is the right default for every operation.

For developers, OpenAI recommends the Responses API² for new projects. It combines model output with built-in tools and supports text and image inputs. An application can supply its own functions and decide how to execute them. This is a useful starting point for a bounded extraction, classification or retrieval workflow where the product team owns the user interface and business logic.

The Agents API³ offers a different level of management: OpenAI operates a Codex-based agent runtime, including sessions, orchestration, context management and recovery. Configured agents can work with tools, files and execution environments. The practical distinction is how much of the ongoing task lifecycle the provider manages. A short document extraction and a long investigation that produces files do not necessarily need the same architecture.

OpenAI's business offering⁷ packages ChatGPT, ChatGPT Work and Codex capabilities in a managed workspace with administration and seat options. That route is suitable when people can work directly in the product. Building through the API is a separate choice when AI needs to sit inside a customer experience or an existing operational process.

02 / AudienceWho should consider OpenAI

OpenAI belongs on the shortlist when a team needs broad language understanding, reasoning, multimodal input or tool use without operating the underlying model infrastructure. The fit can range from an employee reviewing research to an application processing recurring requests. What those uses share is a need to define what a good result looks like and how mistakes will be corrected.

A ready-to-use workspace is often the simpler starting point for exploratory work. A person can provide context, inspect the result and refine the task. An API becomes more compelling when the same process repeats: inputs arrive from a system, outputs must conform to a contract, and the business wants to measure cost and quality across many runs.

Teams whose primary requirement is a specific deployment arrangement should compare providers early. Mistral AI is a relevant comparison for its model, tooling and deployment options. Cohere is useful when enterprise retrieval, embeddings and ranking are central to the application. These are workload and architecture comparisons, not a claim that one vendor wins every task.

03 / WorkflowA worked document-intake application

Consider a service business receiving customer onboarding packs containing forms, certificates and correspondence. Staff currently read each pack, identify missing information and prepare a follow-up draft. A useful first AI workflow would assemble a structured review sheet with source references, flag contradictions and suggest a draft message. The system would leave the account approval and the actual communication to the responsible employee.

Define the result before choosing a model

Begin with the required fields: organization name, requested service, supplied document types, expiry dates, missing items and the location of supporting evidence. Permit an explicit unknown value. A form without an expiry date should not produce a plausible invented date simply because the output schema requires a string.

Structured Outputs⁴ lets developers constrain responses to a supported JSON schema. That makes the result easier to turn into a review screen or pass to another program. It addresses structure, not factual accuracy: a date can fit the schema and still be copied from the wrong document. Applications also need to handle incomplete responses and refusals instead of assuming that every request produces a complete parsed object.

Keep each extracted claim linked to the relevant file and page or passage. The review screen should display the original evidence beside the proposed value. When two documents disagree on a company name or date, return the conflict as a review item. This is more useful than asking the model to silently select whichever value sounds more likely.

Connect current business rules through narrow tools

The model needs the onboarding requirements for the requested service. Supply those through a versioned policy record or a narrow read-only lookup. OpenAI's function-calling documentation⁵ describes the cycle: the model requests a tool, the application runs it and returns the result, and the model continues. The same documentation notes that GPT-6 Astra requires Responses for tool calling, an important compatibility detail when adapting older examples.

In the proposed application, a requirements lookup should accept a service identifier and return the approved checklist with its version. It should not offer unrestricted database access merely because the task concerns customer records. The application can verify the user's identity and the record they are permitted to inspect before providing any document content.

The final output combines extracted values, checklist comparison and a follow-up draft. Treat the draft as a separate artifact with its own approval status. A complete checklist does not mean an account has been approved, and producing an email does not mean it has been sent. Those distinctions make the workflow legible to the employee who is accountable for the customer outcome.

Evaluate the steps independently

Build a reviewed sample containing legible packs, scans, missing pages, expired documents, conflicting versions and packs that do not match a supported service. Measure extraction accuracy, missing-item detection and the factual accuracy of the draft separately. Also record how often a reviewer must reopen the original files and how long correction takes.

OpenAI's evaluation guidance¹⁰ recommends task-specific tests and human calibration of automated scoring. Apply that principle using a maintained test set in the team's chosen evaluation system. Compare candidate models on the same packs, and rerun the comparison after changing the prompt, schema or requirements source. The purpose is to establish a reliable workflow, not to produce a flattering aggregate score.

04 / PricingCurrent pricing and how to estimate a workflow

API usage is metered, while business workspaces have seat pricing. The following API examples come from the current developer rate card⁶. They are Standard, short-context rates; long-context requests and other processing modes use different prices. Tool calls, storage and execution can add cost. GPT-5.6 Sol's listed promotional rates are stated to remain available at least through 21 November 2026.

As a deliberately simplified example, 10,000 text-only runs using 2,000 uncached input tokens and 500 billed output tokens each total 20 million input and five million output tokens. At Terra's table rates, that is $40 plus $60, or $100 for those tokens. It excludes tools, additional turns, retries and other services. Real document packs vary in length and image processing, so measure the actual billed usage before treating the example as a budget.

For managed workspaces, the business pricing page⁷ lists Standard seats at US$20 per user per month billed annually or $25 billed monthly, and Premium seats at $100 annually billed monthly-equivalent or $125 on monthly billing. Enterprise pricing is custom. A seat budget and an API application budget should be evaluated against the specific work each purchases.

Cost per accepted result is the more useful operational measure. A cheaper model can become expensive if staff correct many errors or the application retries repeatedly. Conversely, a capable general model may be unnecessary for a narrow field classification that a smaller model performs reliably. Include review time in the comparison and keep difficult cases visible rather than averaging them away.

05 / DistinctionsWhat stands out about the platform

OpenAI's breadth can reduce the number of separate model integrations a team needs to evaluate. Language, images, speech and tool use can be combined in applications, while the work products offer a direct place for employees to use related capabilities. That is useful when the problem spans several input types, but the right first release can still be deliberately small.

The choice between a direct model interface and a managed agent runtime is another important distinction. In the onboarding example, an explicit sequence of extraction and checklist comparison may be sufficient. A more open-ended research task, involving multiple files and tools, may benefit from managed sessions and recovery. More autonomy is justified when the task requires it and the product can show what happened.

Our assessment is that the durable value lies in fitting the model into an inspectable workflow. Source-linked fields, explicit unknowns and a clear approval state make the output usable regardless of which model configuration is selected. A product built around those contracts can absorb model improvements more easily than one built around a single persuasive demonstration.

06 / QuestionsData controls and product changes to understand

OpenAI states that it does not train on business and API data by default in its business data commitments⁸. That statement should be distinguished from retention. The API data-controls guide⁹ describes endpoint-specific abuse-monitoring and application-state behavior, including default storage for Responses and separate handling for files and conversations. Zero Data Retention is an eligibility-based configuration with feature limitations, not a blanket property of every integration.

The current Agents API documentation says it supports data residency only in the United States and does not support Zero Data Retention; choosing a self-hosted sandbox does not change that. This is material when choosing an architecture for document packs. Confirm the actual endpoint, execution environment and storage lifecycle before using production data, rather than relying on a general description of the model provider.

Existing tutorials also need a date check. OpenAI's deprecations page¹¹ records the Assistants API shutdown date as 26 August 2026. It schedules the Evals platform to become read-only on 31 October and shut down on 30 November 2026, alongside other product transitions. New work should follow current integration documentation and retain portable evaluation data and application instructions.

07 / DecisionThe decision

OpenAI is a strong candidate when broad model capability and accessible applications or APIs match the work. Choose the product surface first: a managed workspace for people, a bounded model integration for a repeatable application, or a managed agent session for a longer task. Then compare models using real inputs and price the accepted outcome. The onboarding example succeeds when staff can review evidence and resolve missing information more effectively, not merely when the system generates fluent text.