Require instrumentation before you approve expansion. That is the operating rule, because the temptation to skip it arrives right after you read OpenAI's usage numbers—and those numbers are striking.
By mid-August, the median researcher ranked by agent usage used more than $600 per day in inference valued at API prices, while the ninetieth-percentile researcher used more than $7,000 of tokens per day. Before June 2026, total agent runtime across OpenAI's research organization stayed below total human labor. By mid-August, OpenAI reported 3.1 agent-workdays of effort per human workday, counting on a standard eight-hour day. [1]
These figures come from OpenAI itself. They are vendor-reported and self-measured, not independently verified. Before you hand your team a larger inference budget because a frontier AI lab is running agents hard, understand what the ratio tells you—and what it does not.
What the Ratio Is Not
The agent-workdays figure measures runtime, not output. A long session increases the ratio whether or not it produces anything worth keeping. OpenAI says easy-to-gather activity measures can be hard to interpret as actual research progress, because bottlenecks can shift. Runtime can climb while useful output stays flat. [1]
The ratio is also specific to OpenAI's research operation, where people set priorities, judge which ideas and results to pursue, and decide whether to scale, pause, or deploy systems. OpenAI defines the category of automated work it calls a “research intern” as a system that carries out well-defined tasks under human direction, including tasks that would take a skilled researcher a few days. [1]
Applying a frontier research lab's internal ratio to a legacy systems team is like benchmarking warehouse throughput against a Formula One pit crew. The work structure differs enough that the number misleads.
Four Metrics Answer Different Questions
Before you give a team wider tool access, a larger inference budget, or reduced review, pin down four measurements.
Tokens and dollar-equivalent inference per engineer per day. This is cost made concrete. You need a baseline before expansion so you can tell “we are spending more because agents are doing more” from “we are spending more because the pipeline leaks.” The dollar-equivalent framing matters because your finance team works in dollars, not tokens.
Agent-workdays per human workday. The ratio belongs in your measurement set, but only after you have anchored it to cost and accepted output. A rising ratio on its own is ambiguous. Paired with those measures, it tells you whether you are buying leverage or buying activity. Establish a baseline before expansion so the ratio has a reference point worth comparing against.
Human interventions per successful long-running task. Agents fail, get stuck, or produce output that needs rework. Counting interventions per completed task tells you how autonomous your operation actually is. A dashboard that reports sessions rather than outcomes cannot answer that question.
OpenAI's monitoring design escalates suspected critical-boundary violations and expects a pause if a highest-priority flag cannot be cleared as a false positive within thirty minutes. That is a human in the loop at a critical juncture. Know where your own critical junctures are, define which events count as interventions, and count those touches consistently. [2]
Success rate by task-difficulty bucket. Aggregate success rates hide whether your team is delegating easy work or improving at difficult work. Segment by difficulty—simple retrieval, multi-step reasoning, or system changes with side effects—and track success separately. Otherwise, a high result on routine tasks can hide poor performance on the work that matters.
Put Controls on the Same Ledger
OpenAI estimates monitoring overhead at roughly twenty percent of the inference compute being monitored, with substantial variation across workloads. This is vendor-reported guidance from OpenAI's environment, not a budget ratio to copy into yours. [2]
It is also not overhead to hide. It belongs on the same ledger as inference usage because monitoring is part of the system required to operate the workload. OpenAI describes monitoring, alignment, and security measures as three distinct safeguards. One cannot silently substitute for another. [2]
The same logic applies to human review time. If reduced review is part of how you plan to scale, put the current review cost in your baseline. Otherwise, you cannot measure what you are trading away. Monitoring and review consume compute and human attention because they are operating costs, not extras to add after deployment.
Build the Operating Model
Establish the baseline before you expand. Run a fixed pilot window long enough to cover the workflows and difficulty buckets you intend to delegate. When the window closes, ask whether accepted outcomes improved and whether inference, intervention, and control costs stayed within their written thresholds. If the answer is yes, expand authority. If the answer is unclear, extend the pilot rather than guessing.
The transferable artifact is the measurement system. OpenAI's internal ratio belongs to OpenAI's operation; your baseline belongs to yours. A team that can show its intervention rate falling as task difficulty rises has earned a different conversation from a team that can only show sessions are up.
Put the baseline requirement in writing before you sign off on any agent expansion.