10,000 Agents, 36 Hours, No Babysitter: What Actually Holds

By Lazar Milicevic · Published October 16, 2026 · 8 min read

You have a job that eats a full day of your month: reconciling invoices against bank lines, auditing a year of customer emails, cleaning a contact database nobody has touched in years. You've tried handing it to a chatbot, and it forgets the thread or confidently invents something around minute ten. OpenAI just published a case study about an agent setup that runs for 36-48 hours at a stretch, and the useful parts of it have nothing to do with scale.

I build AI automations that ship, so let me show you what transfers to a team of one and what's noise.

What Third Moment Research actually reported

According to OpenAI's case study, Third Moment Research runs up to 10,000 agents at once on investigations lasting 36-48 hours. The models and tools listed are Codex, GPT-6 Astra, GPT-6 Sol and GPT-6.1 Sol. They also use OpenAI's Daybreak cybersecurity platform to test the environments agents run in before simulations launch.

Three corrections to the coverage you'll see:

• 10,000 is concurrency, not one 36-hour job. Many agents run in parallel, each on its own investigation.
• It's a customer story OpenAI published itself, on October 14, 2026. Treat every number as the company's own reporting, not an independent benchmark.
• "Gets better the longer it runs" is not what the page shows. The described loop is that recurring failures become synthetic scenarios, and the agents are improved over time. The system improves across runs, not mid-run.

The domain is quantitative finance, where success is measurable by backtests. That matters for transfer: it works there because the answer is checkable. No returns, failure rates or total compute cost are published (the one usage figure on the page is 1 trillion tokens consumed in a single day), so I won't make claims about reliability or cost per run.

Ignore the agent count. Nobody with a ten-person company has 10,000 parallel tasks. What's worth stealing is how the work is structured so one agent can stay on task for days.

The scoreboard is wrong: duration is the real shift

For two years, most people used AI in a ten-minute loop: ask, answer, fix, ask again. A long-running agent is a different job description. It's closer to a contractor who takes a ticket Friday afternoon and hands you finished work Monday morning.

The tasks that fit are big, boring and checkable:

• Reconciling a quarter of invoices against bank export lines
• Auditing a year of customer email for unanswered leads
• Cleaning a contact database that's years stale
• Re-categorizing a backlog of expenses against a rules list

"Checkable" is the filter. If you can state a rule that proves the result is right, an agent can grind on it for hours. If you can't, a long run is just a slower way to be wrong. A ten-minute chat that goes sideways, you see immediately. A long run that drifts early can burn most of its duration producing confident garbage.

The three boring pieces that matter more than the model

Every long-running system I've built has the same three components. Third Moment's design echoes the same instincts: per a detailed write-up, they wrap Codex in an outer harness that inspects an agent's trajectory and picks one of three paths: retry, terminate, or escalate to a human.

Here's the small-team version.

1. Checkpoints

The agent writes progress to a plain file every chunk: what's done, what's next, what it decided and why. A crash at hour 20 resumes from the last checkpoint, not from zero.

import json, pathlib, datetime

CKPT = pathlib.Path("state/checkpoint.json")

def load_state():
    if CKPT.exists():
        return json.loads(CKPT.read_text())
    return {"done_ids": [], "decisions": [], "next_batch": 0}

def save_state(state):
    state["updated"] = datetime.datetime.utcnow().isoformat()
    tmp = CKPT.with_suffix(".tmp")
    tmp.write_text(json.dumps(state, indent=2))
    tmp.replace(CKPT)  # atomic swap: never a half-written checkpoint

state = load_state()
for batch in batches(start=state["next_batch"]):
    results = agent_process(batch, notes=state["decisions"][-20:])
    state["done_ids"] += [r["id"] for r in results]
    state["decisions"] += [r["why"] for r in results]
    state["next_batch"] += 1
    save_state(state)

Note the atomic write. A checkpoint file corrupted mid-write is worse than no checkpoint.

2. A verifier that isn't the agent

A separate pass checks the output against a rule you can state in one sentence. Examples:

• Invoice totals match the bank export to the cent
• Every record has a client ID
• No email in the "unanswered" list has a reply later in the thread

If the check fails, the work is flagged, not shipped. The verifier should be plain code wherever possible. Don't ask the same model that made the mistake whether it made a mistake.

def verify(rows, bank_total):
    errors = []
    if round(sum(r["amount"] for r in rows), 2) != round(bank_total, 2):
        errors.append("sum mismatch vs bank export")
    errors += [f"missing client_id: {r['id']}" for r in rows if not r.get("client_id")]
    return errors

3. A human approval point

Anything that touches money, customers or deletion gets proposed by the agent and approved by a person. That isn't a limitation. It's what makes it safe to leave running overnight. Third Moment keeps a human review step in its own design too.

Waiting is the hidden cost: kill the polling

One detail from the case study transfers more directly than anything else. Remio's analysis says the waste came from agents repeatedly polling a slow three-hour job. Those status checks burned tokens and filled the context window with low-value information.

Per daily.dev's summary, Codex then found a caching optimization and a memory-packing technique that cut a backtest from about 3 hours to about 3-5 minutes, a reduction OpenAI's page headlines as 97%. Two caveats: it's one reported case, not an average gain, with no published benchmark protocol or independent reproduction. And per the same sources, that optimization used GPT-5.6, not GPT-6.

The lesson isn't "AI makes things 97% faster." It's that an agent sitting in a loop asking "done yet?" is spending your money to learn nothing. In your own pipelines:

# Bad: the agent polls inside its own context
while not job_done():          # every iteration costs tokens
    agent.run("check job status")

# Better: the agent starts the job and stops; plain code waits
job_id = start_export()
wait_for_completion(job_id, poll_seconds=60)   # no model calls here
agent.run(f"Export {job_id} is ready at {path}. Continue with step 3.")

Waiting belongs to your scheduler, not your model. The agent's context should hold decisions and results, not a transcript of "still running."

Making it improve with use, without a research lab

"Improves with use" gets abused. It doesn't mean the model gets smarter on its own. In every long-running setup I've built, the improvement lives in the scaffolding. Third Moment's version, per the OpenAI page, turns recurring failures into synthetic scenarios. Yours can be a text file.

The loop:

1. The verifier catches an error (or you catch one in review).
2. You add one line to rules.md: the rule, plus a short bad/good example.
3. Every run starts by reading rules.md.

# rules.md  (the agent reads this first, every run)
- Amounts in the bank export are in cents; convert before comparing.
- "ACME GmbH" and "Acme Gmbh" are the same client. Match case-insensitively.
- Never mark an email "unanswered" if a sent message exists later in the thread.
  BAD: flagged thread 4412 (we replied Tuesday). GOOD: skip when a later sent item exists.

After a month, that file is the actual product of your automation. It's also model-agnostic: when you swap models, the rules come along.

Which model, and what it costs

Model choice matters less than the scaffolding above, but cost shapes how long you can afford to let a run go. Here's what I can say with confidence.

Per TechCrunch: OpenAI launched GPT-6.1 Sol on September 29, 2026, saying it delivers nearly the same intelligence as GPT-6 Astra for agentic coding, computer use and professional work, at one-fifth of Astra's standard input and output token prices. OpenAI's docs position it for repeated, long-running work, and in ChatGPT it's available in Work and Codex, not Chat.

For exact per-million-token prices, including cached-input rates, check OpenAI's official pricing page before budgeting. Third-party trackers such as BenchLM also list them, but prices change, so treat any tracker as a convenience, not the source of truth.

What I'd do with that: run the cheaper Sol-class model for bulk work, because a long job is mostly many small steps, and reserve a pricier model for the few steps where a verifier keeps failing. Third Moment itself reportedly mixes models rather than using one. Also check the long-context pricing and your plan's access limits before you build around a specific model.

Run a pilot on a slice (say 5% of the data), read the token usage, and extrapolate. That's real numbers instead of estimates.

The one thing to do this week

No new tools required:

1. Pick one job that eats a full day of your month and passes the checkable test.
2. Write the verification rule first, before touching any AI. One sentence: "totals match the bank export," "every row has a client ID."
3. Chunk the job. Give the agent 50-100 items at a time, not the whole pile.
4. Log progress to a plain text file after each chunk.
5. Run your rule as a separate pass over the output.
6. Append every caught error to rules.md, and have the agent read it at the start of the next run.

That is the pattern Third Moment runs at scale, shrunk to a Tuesday afternoon. The scoreboard the industry will push for the next year is agent counts and run lengths. It's the wrong one. A 36-hour agent with no verifier is a slower way to be wrong. The people who win with this will be the ones who can prove what the agent did. If you can't audit it, don't leave it running overnight, no matter which model is on the invoice.

Why bizflowai.io helps with this

I'm a senior engineer who builds AI automations for small teams, and you can find my work at bizflowai.io. The pattern in this post is the one I care about: the agent does the grinding, a check that isn't the model verifies the output, and a human approves anything that touches money or customers.

Want more like this?

I publish practical AI automation content on YouTube under the channel name BizFlowAI.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milicevic, senior engineer building practical AI automation.

Visit bizflowai.io for practical AI automation for solopreneurs and small teams.