Apps in ChatGPT pricing: plans, provider costs, and API budgets

What you pay for when you use an app

“Apps in ChatGPT pricing” combines four separate costs or limits. Splitting them apart makes the buying decision clearer.

The published ChatGPT plans are not a price list for every connected service. For example, Canva's US price page lists Canva Free at $0/year for one person and Canva Pro at $180/year for one person. It also says taxes are extra and its AI Pass add-on costs extra. That is Canva's own product price, not an OpenAI app-installation fee. See Canva pricing for live terms.

ChatGPT plan prices: the current baseline

Here are the public US headline prices at the time of this update. This is the fee for the ChatGPT plan itself. It does not include an app provider's bill.

Sources: OpenAI's Go launch and US price, current Pro tiers, and Business seat prices. Confirm taxes, local currency, and the actual checkout before purchase.

OpenAI's plan comparison shows that app availability can differ by plan. It also changes by surface, region, model, and account eligibility. Treat the live plan comparison as the decision source when a feature is needed for a rollout.

A plugin install is not a bill, login, or permission grant

A plugin is a reusable package. It can contain skills, connectors, or both. Installing one makes those capabilities available for a new chat; it does not automatically connect the outside service.

If a plugin includes a connector, you may still need to sign in to the provider. OpenAI says that Sign in with ChatGPT shares basic profile details where available, but it does not grant access to provider data or approve actions. Review the requested permissions separately. The plugin guide also says to review and trust plugin hooks before enabling them.

For a managed workspace, the chain has more than one control:

1. An admin decides whether the plugin is available to the member or role.
2. The workspace enables the app or connector and sets allowed actions.
3. The member or shared connection authenticates with the provider.
4. The provider's service permissions decide which data and actions that identity can use.

The enterprise app controls are explicit: making an app or plugin available does not grant access to files, records, or actions in the connected service. Start with read actions. Before enabling writes, name an owner, review connector scopes and provider permissions, document the external effect, and keep a recovery path.

An action request in a chat is not a permission grant. The connected service, workspace policy, and approval settings still govern what can happen.

API costs are a different budget

Using ChatGPT with an app is not the same thing as building an app with OpenAI models. A ChatGPT subscription does not include API credits. The OpenAI API pricing page prices API usage separately by model and usage type.

For an API build, model usage is only one line item. The team also owns authentication, data boundaries, tool permissions, testing, logging, incident handling, model changes, and the people who maintain all of that. Do not turn a plan price into an API forecast. Estimate model usage for the proposed workflow, then add the cost of operating it safely.

That distinction matters when the use case is narrow. A support team that needs to answer routine tickets does not need a general ChatGPT integration plus a custom service around it. It needs a controlled workflow in the system where agents already work.

For Zendesk support, price the operating work

Compare the work around the model as well as the subscription: keeping knowledge current, deciding what the teammate may do, checking exceptions, and reviewing changes to its rules. These are operating requirements, not included API features.

eesel for Zendesk is built around that support workflow. It works in the existing queue, and a support owner can review instructions, connected knowledge, activity, and held approvals. The dashboard and CLI operate the same workspace, so a team does not have to reconcile two separate setups.

A controlled cost review with the eesel CLI

The eesel CLI gives a support owner, engineer, script, or coding agent such as Claude Code, Codex, or Cursor a repeatable way to inspect the same teammate as the dashboard. Commands return JSON, so the coding agent can compare the billing and activity records with the test plan. With Node.js 18.17 or newer, use npx @eesel/cli without a global installation. Sign in to the intended workspace and replace support-teammate below with the agent's actual ID or name.

Start with a read-only baseline. These commands do not create customer-facing work; eesel billing reads the workspace's live billing state.

npx @eesel/cli status --agent support-teammate
npx @eesel/cli billing --agent support-teammate
npx @eesel/cli instructions --agent support-teammate
npx @eesel/cli activity --agent support-teammate

Before testing, the owner checks enabled actions and downstream service permissions in the dashboard and Zendesk. A prompt is not an access control. Use an approved configuration that cannot carry out unwanted customer actions. Then start a fresh, named conversation and run one bounded fictional test with an explicit policy; it is not authorization to contact a customer, edit a ticket, or change an order.

npx @eesel/cli new --name delivery-status-review --agent support-teammate
npx @eesel/cli chat --agent support-teammate "Fictional evaluation only. Test policy: if a parcel is late and its tracking status is unknown, acknowledge the delay and explain that a support specialist must investigate. Do not invent an ETA. Customer: My parcel has not arrived. Order 41922. Tracking status: unknown. Draft only the reply. Do not look up this fictional order, edit records, contact anyone, or change configuration."

That chat is real billed work in the real workspace, even though the facts are fictional. Record the baseline billing state first, but do not claim that before-and-after figures prove the exact cost of this chat: concurrent workspace work can change them too.

If the test exposes a needed rule, the coding agent should propose the exact wording, affected agent, and expected result. The support owner approves that precise change. Before any write, the owner must confirm downstream service permissions in Zendesk and the eesel dashboard. A read-only CLI command cannot prove every permission in those services.

For a supported write, use --dry-run with the actual proposed write arguments to preview the server call; consult the command's --help for that syntax. Reading instructions alone is not a preview of an instruction update. After the owner approves the specific change, apply it through the supported command or dashboard flow. Start a fresh conversation so earlier test messages cannot supply the rule, then check whether the configured teammate follows it:

npx @eesel/cli new --name delivery-status-retest --agent support-teammate
npx @eesel/cli chat --agent support-teammate "Fictional evaluation only. Customer: My parcel has not arrived. Order 41922. Tracking status: unknown. Draft only the reply using the approved standing policy. Do not look up this fictional order, contact anyone, edit records, or change configuration."
npx @eesel/cli activity --agent support-teammate
npx @eesel/cli approvals list --agent support-teammate
npx @eesel/cli billing --agent support-teammate

Review the response, activity, and any held approval. Test a missing-order-number case separately, and verify ticket delivery and handoff in the native helpdesk before widening the rollout. A no-action prompt narrows the test; it is not a permission system. Held approvals cover actions actually held by the workspace, not every possible action.

Questions to ask before comparing prices

• Which capability is needed: search, research, a connected data source, an interactive app, or a write action?
• Is it available for this plan, user role, region, model, and ChatGPT surface?
• What does the provider charge, and what does its plan include or cap?
• Who owns the provider account, connector scopes, and future access reviews?
• If you are building, who owns API spend, testing, logs, outages, and model updates six months from now?
• If customers are involved, where will the response, escalation, and review record live?

The last question often decides the architecture. If the record belongs in Zendesk, start from the helpdesk workflow rather than forcing a general chat connection to become a support system.

Try eesel with Zendesk

Try eesel for free to review a narrowly scoped Zendesk teammate. Connect approved knowledge, set narrow rules, and inspect the same workspace from the dashboard or CLI. Budget for the real chat tests and review their outcomes before expanding the workflow.