Claude Sonnet 4.5 and the Long-Running Agent

Thirty hours is the headline. Thursday afternoon is the use case.

Anthropic released Claude Sonnet 4.5 on September 29, 2025 and said it has observed the model maintaining focus for more than 30 hours on complex, multi-step tasks.¹ I do not run anything for 30 hours. What I care about is simpler: can I hand a real piece of work to an agent, leave, and come back to something I can use? (Clear SOPs written for agents are most of the answer.)

That question matters to me because there is no one else in my business to hand work to. Delegation is not a management style for me. It is how the week gets done.

What did Anthropic actually release with Sonnet 4.5?

The headline claims, straight from Anthropic's announcement:¹

• A model aimed at coding, computer use and long-running agents, at $3 for every million tokens sent in and $15 for every million generated.
• A score of 77.2% on SWE-bench Verified, a software engineering benchmark, and 61.4% on OSWorld, a computer-use benchmark. Sonnet 4 scored 42.2% on OSWorld four months earlier. Claude's computer use was the first version of that idea.
• New tools around the model: context editing and a memory tool in the API, checkpoints in Claude Code, and the Claude Agent SDK, which gives developers the infrastructure Anthropic uses for Claude Code.
• File creation and code execution in the Claude apps, so the model can produce spreadsheets, slides and documents.

Benchmarks are measured on Anthropic's setup, not yours. Treat them as direction, not forecast.

Anthropic's own engineers describe an agent in plain terms. In a Code w/ Claude talk posted on July 31, 2025, Cal Rueb, who works on Anthropic's applied AI team, put it this way:

I like how unglamorous that is. It also shows where your work sits: you write the instructions and you check the result, and the loop in between is the model's job.

Plays here, from YouTube

Why does a 30-hour claim matter if you never run 30 hours?

Because long runs are really about not falling apart in the middle. The common failure with agents is not that they cannot start. It is that step 14 forgets what step 3 decided, or the agent drifts into a different task, or it repeats itself.

Anthropic is careful with the wording. The 30-hour figure is something it "observed," not a benchmark result.¹ That distinction should shape how you plan. An agent that held focus in Anthropic's tests might still stumble on your messy folder of client files.

Longer runs reward better briefs, not looser supervision.

What changes for a one-person business

The honest answer is the size of the unit you can hand off. A model that holds a thread for longer lets you delegate a whole project: audit these 40 pages, compare them to this checklist, write up the gaps. Before, you handed off a paragraph.

What is context engineering, and why should operators care?

Anthropic published a companion piece the same day. It describes context engineering as the strategies for "curating and maintaining the optimal set of tokens" the model sees as it works.² Prompting is part of it, but the bigger job is deciding what is in the agent's working memory at each step.

The article names several techniques that translate cleanly to business use:²

• Compaction: summarize a long conversation and restart with the summary so the agent keeps the thread without carrying every old detail.
• Structured note-taking: the agent writes notes outside its context window and reads them back later, the way you would keep a project log.
• Sub-agents: specialized helpers do focused work in a clean context and hand back a short summary (see multi-agent systems).
• Just-in-time retrieval: keep lightweight pointers, like file paths, and load details only when needed instead of stuffing everything into the prompt.
• Context rot: accuracy tends to fall as the window fills, so more context is not always better.

You do not need to build these yourself. You need to know they exist, because they explain why a tidy, labeled project folder beats a giant pasted document every time.

What should you hand to a long-running agent first?

Use a simple test: finish line, check, undo.

If you are new to this, Claude Code for non-developers is a gentle place to start. Good first projects: research briefs, data cleanup, page audits, first drafts of long documents, internal reports. Keep sending, posting and spending behind your approval.

A quick example of a good first brief

Say you want a competitor page audit. The brief names the pages to read, the five things to extract from each, the format of the comparison table, and one rule: if a page cannot be loaded, list it and move on instead of guessing. You ask for a decision log. When the run finishes you scan the table, spot check three rows against the live pages, and you have a result you can trust in ten minutes.

That is the loop. It works for a human assistant and it works for an agent, and the difference is that the agent will not ask a clarifying question unless you tell it to. So tell it to: "If anything in this brief is unclear, list your assumptions at the top before you start."

What can still go wrong?

Plenty. Agents can misread an instruction, lose track of a constraint or confidently build the wrong thing. A 61.4% score on OSWorld is real progress, and it is also not 100%.¹ Treat that gap as the size of the supervision job.

The shift that matters

For a year the skill was prompting. Now the skill is managing: scoping the work, preparing clean inputs, writing the checks, and reading the log. That is a more familiar skill to anyone who has run a team. It is also a skill you can practice this week.

Pick one project with a clear finish line. The brief, the check and the undo are the whole discipline. Write the brief. Let the agent run. Then check the work like you would check a new hire's first deliverable. You will learn more in that one loop than in a month of reading announcements. It is the same discipline behind my client build work.

Keep building.Ekai