OpenAI Dots Put Persistent Work to the Buying Test • The Weighted Average

OpenAI’s Dots move ChatGPT toward persistent work: agents use cloud computers, keep progressing between conversations, and return outputs for review. The buying decision is whether a specific responsibility benefits from that continuity. With a $400 monthly subscription gap between Pro 100 and Pro 500, proving the workflow should come before upgrading its capacity.

Give the persistent agent a finish condition

OpenAI describes Dots as agents that can take responsibility for ongoing projects, using connected tools and the context available to them. Its product page presents examples such as preparing document changes, tracking dependencies, and turning feedback into proposed improvements. These are vendor-described uses. They establish what the product is intended to support, rather than a measured completion rate for a customer’s work.

The consequential change is where the assignment ends. In a chat, an answer can be reviewed immediately against the question. An ongoing responsibility may involve new information, several intermediate outputs, and a decision that arrives after the original conversation. The owner needs a finish condition that survives those changes. Otherwise, activity and useful progress become difficult to distinguish.

Consider a pilot that keeps a project document aligned with an approved source. The assignment should name the authoritative source, the document to update, and the changes that require review. Ask for a proposed revision, the evidence behind each material change, and a clear statement of anything unresolved. That is a proposed evaluation design, not a claim that the product has passed it. It gives an operator something concrete to accept or reject.

Start by measuring the work already being done. Which changes does the owner currently miss? Which drafts require substantial correction? Where does a handoff wait for someone to gather context? A persistent agent is most promising when continuity addresses a known gap. Giving it a broad responsibility before identifying that gap makes the pilot harder to assess and the resulting subscription harder to justify.

Permissions are part of the design. OpenAI’s stated controls let users choose connected applications and set rules for actions that are allowed, blocked, or require approval. For an initial pilot, preparing an update and sending it externally can have different acceptance conditions. The first can earn a broader role through a record of correct drafts; the second needs the owner to decide who may receive what information and when.

That boundary also makes failures informative. An output based on an outdated source calls for better source selection. A correct proposal that never reaches its destination reveals an incomplete handoff. A change made beyond the assignment exposes a scope problem. Buying more capacity will not necessarily repair any of those. Record them separately so the next adjustment addresses the failure that actually occurred.

Our Claude Projects parallelism analysis reached a related conclusion: delegated workers still converge on a reviewed outcome. Persistence adds another dimension to that problem. A responsibility can continue after the owner steps away, but its latest state still needs to be understandable when the owner returns. Keep a visible record of what changed, what was accepted, and what decision remains outstanding.

Buy the premium for a demonstrated bottleneck

The current Pro tier documentation lists $100 per month for Pro 100 and $500 for Pro 500. The higher tier includes Ultrafast and the highest included usage of the listed personal Pro plans. Meanwhile, OpenAI’s Dots access description makes Dots available across Pro in eligible markets. Combining the access boundary with the prices gives an incremental purchasing budget: $500 − $100 = $400 per month, while $500 ÷ $100 = 5x the subscription price. That premium buys a different usage tier; it is not the minimum price of trying persistent assistance.

The calculation supplies a decision boundary, not an ROI forecast. It contains no assumed hourly wage, invented time saving, or promised increase in completed tasks. An operator can compare the extra monthly commitment with an actual record of useful outputs and the bottlenecks preventing more of them. Without that record, the price ratio is precise while the value argument remains speculative.

OpenAI’s plan comparison places Dots within Pro, alongside other capabilities. The value of a subscription can therefore extend beyond this single workflow. Keep those benefits separate in the evaluation: a user who needs additional coding capacity may have a different reason to upgrade from someone piloting document maintenance. The same invoice can support different purchasing decisions; it should not be credited with savings that were never measured.

The case for upgrading becomes stronger when an already useful assignment repeatedly reaches an allowance boundary or waits on generation that blocks the next valuable step. Preserve the blocked task and its intended result. After an upgrade, check whether that particular constraint changed. A smoother experience is welcome, but the more useful evidence is that work previously left incomplete now reaches the same acceptance standard.

The counterargument deserves weight. Review time, source gathering, or unclear ownership may be the real constraint. Faster generation can simply bring more unaccepted drafts to the same overloaded reviewer. A broader assignment can consume additional usage while revisiting decisions that no one has resolved. In those situations, narrow the responsibility or repair the handoff before changing the plan.

The archive’s Spark token-mix analysis showed why a tariff needs a workload to become meaningful. Here the denominator is accepted work. Record rejected attempts and correction time alongside completed outputs, and keep the source and review conditions consistent. Our verdict is to pilot a bounded persistent responsibility first, then pay for capacity when the evidence identifies a capacity problem. Reliable completion with less supervision would justify expansion; additional correction or unresolved external actions would narrow it.