Feature request: separate or lower-cost usage accounting for browser/computer use

[sdjaco]

Summary

Please provide separate or lower-cost usage accounting for Codex browser/computer-use actions so routine UI automation does not consume the limited Codex allowance intended for substantive coding and reasoning work.

Problem

Browser and computer use are genuinely useful. I want to use Codex to open the application, navigate screens, click controls, and verify the result after implementation.

The problem is that this automation appears to consume the same limited Codex usage available for the difficult work: understanding the repository, diagnosing defects, planning changes, editing code, and validating the implementation.

That creates a practical disincentive. A user may avoid browser/computer use entirely—not because it lacks value, but because spending limited Codex capacity on routine clicking and navigation leaves less available for the engineering work Codex is uniquely valuable for.

Example workflow

A typical task may involve:

1. analyze a defect;
2. implement and test the fix;
3. launch the application;
4. navigate to the affected screen;
5. perform a few clicks and confirm the behavior.

Steps 4–5 are useful, but they should not materially reduce the user's remaining capacity for steps 1–2.

Requested outcome

Provide a way for browser/computer-use activity to have different usage treatment from substantive model work. Possible solutions could include:

• a separate automation allowance;
• lower-cost metering for routine browser/computer actions;
• independently configurable limits;
• clear usage attribution showing what was consumed by model work versus UI automation;
• an option to stop browser automation when its allowance is reached while preserving the rest of the Codex task.

The exact implementation is less important than the user outcome: people should be able to use Codex's browser/computer capabilities without rapidly exhausting the capacity they depend on for coding and repository reasoning.

Scope

This request is about usage treatment and visibility, not about disabling safeguards or making browser automation unlimited. It is also not an assertion about OpenAI's internal billing architecture; it describes the user-visible tradeoff created by the current experience.

Related issues

Issues such as #30665 and #30639 discuss unexpectedly high or unclear usage around browser/computer-use and background execution. This request is broader: even with accurate accounting, users need browser/computer use to be economically practical relative to substantive engineering work.

[Keesan12]

Separate metering is useful, but attribution is the prerequisite. A run ledger should split reasoning, repository work, tool execution, browser actions, and verification, then allow caps by action class. That gives users a deterministic stop rule—for example, UI automation may spend X but cannot consume the reserve for diagnosis and code changes—even if pricing stays unchanged.

If you’re willing, run one browser-heavy workflow through MartinLoop and send the receipt so we can see whether the cost boundary is actionable: https://github.com/Keesan12/martin-loop