Grok Bot Adds Reach; Subscriptions Still Do Not Stack • The Weighted Average

More initiative meets one usage grant

Grok Bot’s recent changelog adds a proactive primary Bot, expanding the case for delegating recurring work, but its subscription rules deserve equal attention. At current US monthly list prices, Cursor Pro’s $20 plus SuperGrok’s $30 totals $50, while the Bot billing guide says the included usage grants do not stack.

The arithmetic is simple: $20 + $30 = $50 billed across two subscriptions. It does not mean the products are interchangeable, or that the second subscription has no value. It means a buyer should not justify both payments on the assumption that connecting them combines Grok Bot allowances. Evaluate their other features separately. A developer may reasonably want Cursor and SuperGrok for different work, but that is a different purchase rationale from buying extra Bot capacity.

The new primary-Bot behavior is worth a controlled trial. The changelog says a starred primary Bot can identify work to offer to handle, with Grok Bot 0.59.0 or later required. The operational question is whether those offers identify useful work at the right moment. More initiative is not automatically more completed work. A team should distinguish helpful intervention from notifications that create another review queue for the person the assistant is supposed to help.

The product overview describes persistent cloud computers, retained context, and background work that continues after the local app closes. These features make the delegated task’s finish line more important. An overnight research request should specify what evidence to gather, where the result belongs, and which action requires review. Otherwise the user may return to an extensive activity history without the decision-ready result they needed.

This is the persistent-work counterpart to today’s GPT-6 interface analysis. A better interface can make an answer easier to inspect; a persistent Bot can keep working after the user leaves. Both are useful only if the user can distinguish a proposed action, an action in progress, and an action that the external service actually accepted. Design the handoff around that distinction before granting more applications or longer unattended runs.

Start with a repeated, reversible task such as assembling a briefing from approved sources. Compare accepted outputs over successive runs and record interventions. If the Bot repeatedly asks the same clarification, improve the task definition before adding another Bot. If the task requires new authorization each time, count that human work in the evaluation. Persistence should reduce repeated setup; it should not hide it behind a more personable interface.

The computer is shared even when the roles differ

The more consequential boundary is access. According to the computer-and-apps documentation, an account’s Bots share one cloud computer, including files and browser sessions. Separate names and roles do not create separate account-level data boundaries. A role assigned to one Bot is therefore not, by itself, evidence that another Bot cannot reach the same signed-in service or file.

That changes how a buyer should stage a pilot. Inventory the accounts signed into the shared computer and remove access that the selected task does not need. Use the service’s own authorization controls where possible. A user may want one Bot to prepare a sales briefing and another to organize personal material; the documentation is a reason to examine that arrangement carefully rather than assuming the visible separation is an isolation guarantee. The right boundary is the implemented access policy.

Entry points also have limits. The documentation for tagging @bot on X says the work starts in the main Bot, requires connected accounts, and is not available in every region. It also lists cases that do not produce a reply, including quoted content containing video or GIFs. Treat a missing acknowledgment as a task that may not have arrived. A reliable workflow needs a place to confirm receipt rather than relying on the social post as its sole record.

Spending has a similar distinction between the visible meter and the actual stopping behavior. The billing guide separates weekly included usage from on-demand spending. With on-demand enabled, work can continue after the included grant runs out, and an already-running task can finish beyond the monthly limit. A budget owner should understand that behavior before assigning unattended work. A displayed limit is not a promise to interrupt execution at the exact moment a balance crosses it.

The archive’s Grok Build quota analysis makes the adjacent economic point: an allowance is useful only when its boundary matches the planned workload. For Grok Bot, record subscription spend, additional usage, and human review against the accepted output. Do not compare plans by the number of named Bots alone. Parallel identities are a workflow feature; they do not establish a proportional increase in included compute or reliable throughput.

The strongest case against expanding a pilot is accumulated supervision. If each run creates more exceptions than it resolves, the persistent assistant becomes another system to operate. Conversely, repeated successful execution of a bounded task can justify broader use even when a person still reviews the result. The evidence should be the saved work and the manageable failure rate, not the ability to schedule a long list of tasks.

Existing Cursor or SuperGrok customers should first establish which single grant the account is using and test within it. Buy additional capacity through the documented route only after measured demand warrants it. Keep both subscriptions when their distinct benefits justify the bill; do not keep both merely to stack Bot usage. Then widen access and autonomy task by task, with the shared computer and the external service’s permissions treated as part of the purchase.