What the 3.1 figure measures
On September 6, 2026, OpenAI published an internal snapshot of research acceleration. Its headline operational figure says that, as of mid-August 2026, total coding-agent runtime across the research organization equaled 3.1 standard eight-hour agent-workdays for every workday of human labor. That is a runtime ratio. It is not evidence that one researcher produced 3.1 researcher-days of accepted work, nor that research moved 3.1 times faster.
OpenAI draws that boundary itself. The company says overall research progress probably will not keep pace with the specific activity metrics because the process has multiple bottlenecks. People still choose priorities, judge which ideas and results to pursue, and decide whether to scale, pause, or deploy. Its appendix calls the measurements preliminary, defines “researcher” broadly across the research organization, and says the coding-agent data covers most but not all usage.
The useful lesson is therefore not “buy 3.1 times more runtime.” It is to give every number one job. Runtime describes utilized agent capacity. Concurrency describes how work overlaps. Completion describes throughput. Interventions describe human effort. Verification describes whether an output met its contract. Bottlenecks describe where elapsed time still accumulates. Keep those columns separate before changing your parallel-agent workflow.
Do not let utilization impersonate an outcome
Imagine two teams each log 80 agent-hours in a week. Team A completes 20 bounded tasks; 16 pass their declared checks and 12 are accepted without rework. Team B completes 40 tasks; 10 pass and 4 are accepted. The utilization headline is identical, while the outcome profile is not. Even “task completed” is ambiguous until completion means something observable, such as a pull request opened, a test suite passed, or a benchmark result reviewed.
OpenAI reports that experiments per active experimenter reached a high in August 2026 for its series beginning in January 2025. It also notes both correlation with Codex adoption and substantial growth in available compute. That combination is a reminder to avoid a causal shortcut: more experiments may be valuable throughput, but compute, staffing, task mix, model capability, and workflow changes can move alongside agent adoption.
Code volume has the same problem. OpenAI says it is comparatively easy to collect yet difficult to interpret because its relationship to research progress is uncertain. A deletion can be the best patch, while thousands of generated lines can increase review and maintenance cost. Record code change size as diagnostic context if it helps, but keep it out of the outcome column.
Use one card for six different signals
Create one card per team and measurement window. Freeze its definitions before collecting the first run so that a better-looking dashboard cannot quietly redefine success. The following example uses a seven-day window and a repository-scoped task ledger; adjust the thresholds, not the separation of signals.
| Field | Record | Interpretation boundary |
|---|---|---|
| Agent runtime | Active execution minutes by session; report 8-hour agent-workdays as minutes divided by 480 | Capacity used, not human time saved |
| Concurrent sessions | Peak and median active sessions; state whether subagents count | Overlap, not useful throughput |
| Completed tasks | Task IDs reaching the predeclared terminal state | Completion may still fail verification |
| Human interventions | Count and minutes by reason: clarification, correction, approval, recovery | Human cost; do not hide steering inside “autonomous” work |
| Verified outputs | Completed tasks passing the named automated gate and reviewer decision | Accepted evidence for this contract, not universal quality |
| Bottlenecks | Queue and wait minutes by stage: review, CI, environment, data, compute, decision | Constraint after or between agent actions |
Attach a coverage note: repositories included, agent clients included, missing telemetry, time zone, and whether paused or idle sessions accrue runtime. OpenAI's own coverage caveat shows why that line matters. A ratio without its denominator and collection boundary cannot be compared honestly across teams or weeks.
Define completion, intervention, and verification before the run
For a coding task, write a compact contract: “Update parser fixture P; do not change public API A; pass test command T; attach diff D; reviewer R decides accept or reject.” The completed timestamp is when the agent submits all artifacts, not when the session stops. The verified timestamp is when T and the reviewer decision are recorded. If the task is abandoned, timed out, or superseded, preserve that terminal state rather than deleting it from the denominator.
Define an intervention as a human action that changes the task's execution path after launch. A clarification, corrective prompt, manual edit, restart, permission change, or environment repair counts; opening a dashboard without acting does not. Record both event count and active minutes because one approval click and a 45-minute debugging rescue should not collapse into the same cost. In OpenAI's measurable subset, more than half of successful tasks estimated at four to eight human hours involved at least one intervention during the six-month period it describes. That figure supports tracking steering, not assuming your rate will match OpenAI's.
Verification must test the requested outcome. A green formatter cannot verify a requested authorization fix; a passing unit test cannot establish that an experiment result deserves adoption. Pair automated checks with the decision owner named in the task contract. This complements an evaluation discipline and keeps the measurement problem distinct from the recursive improvement loops discussed in Codex self-improving agents.
Track concurrency without rewarding fan-out
OpenAI describes highly concurrent workflows using four or more simultaneous agents as an example, and its daily peak counts both agents started by a person and downstream subagents. Your instrumentation needs an equally explicit rule. Give each root task a stable ID, link every child session to it, and calculate both raw active sessions and active root tasks. Otherwise one orchestrator spawning ten subagents looks like ten independent outcomes.
Use concurrency to find saturation. Compare peak session count with queue time, intervention minutes, verification delay, and acceptance rate. If sessions rise from 2 to 8 while review wait grows from 30 minutes to 6 hours, the review stage is the operational constraint. The corrective action may be fewer concurrent tasks, smaller task contracts, faster automated gates, or more review capacity—not more agent runtime.
Run a four-week comparison, not a victory lap
Start with one stable task class and retain weekly rows for at least four measurement windows. Report totals and rates together: 24 completed, 18 verified, 14 accepted without rework; 11 intervention events consuming 95 human minutes; 43 agent-hours; median verification wait 2.4 hours. Rates alone hide volume, while totals alone hide quality and cost.
Before expanding, inspect three questions. Did accepted output rise without a disproportionate increase in intervention or review time? Did the main bottleneck move, and can the next stage absorb more throughput? Did task mix, staffing, compute, model, test coverage, or acceptance rules change during the comparison? If any answer is unclear, label the result observational rather than causal.
The defensible headline is deliberately narrower than “productivity increased.” It might be: “For repository X during weeks 1–4, agent runtime rose 22%, verified tasks rose from 9 to 13, human intervention fell from 140 to 95 minutes, and median review wait grew from 1.1 to 2.4 hours under unchanged acceptance checks.” That sentence tells you what improved, what worsened, and what still requires a decision.
The metric is a map, not the destination
OpenAI's 3.1 ratio is useful because it makes the scale of concurrent machine activity visible. Its surrounding caveats are more useful for adopting the workflow responsibly. Measure runtime, but connect it to tasks. Count tasks, but preserve failures. Verify outputs against a declared contract. Charge interventions to the workflow. Follow the queue until you find the next bottleneck.
With that evidence in place, decide whether additional agents created more accepted work within your own engineering system. The goal is not to reproduce OpenAI's number. It is to produce a measurement record that prevents a capacity number from being mistaken for a productivity claim.