A long-running task is a job with many steps, spread over more time than a single quick reply.

The simple definition

A normal chat turn is like asking a friend a quick question across the table. A long-running task is like asking the friend to plan your whole trip, which involves research, comparing options, making choices, and writing it all down. The friend will need time, will make many small decisions, and may need to check things along the way. The same is true for Claude when you give it a large goal.

What makes a task long

Length is not only about the clock. A task can be long because it has many steps, because it handles a large amount of material, because it waits on slow systems, or because it must repeat on a schedule. Often it is a mix of all four.

Why people use them

The attraction is simple: you spend a few minutes describing the goal and receive hours of work in return. A long-running task turns your attention from doing to directing. You become the person who sets the aim, checks the quality, and makes the final decisions, while Claude does the steady work in between.

Short tasks and long tasks compared

The table shows that the skills are different. For a short task, the quality of your question matters most. For a long task, the quality of your setup matters most, because you will not be there to rescue every misunderstanding.

Three pressures build up as a task grows: a limited working memory, mistakes that compound, and the need for you to trust work you cannot watch.

Pressure one: limited working memory

Claude reads and writes within a space called the context window. It is the amount of text Claude can hold in view at one time, including your instructions, the conversation so far, the files it has read, and the results of its tools. The space is large but not infinite. On a long task, material piles up, and eventually something has to give.

Pressure two: compounding errors

In a short task, one small mistake is easy to spot. In a long task, a small early mistake can carry through every later step, like a wrong turn at the start of a long drive. A misread number in step three becomes the foundation of the chart in step thirty. The longer the chain, the more important it becomes to check as you go.

Pressure three: trust without watching

When you are not watching, you cannot catch a problem the moment it happens. You rely on the task being set up well, on progress being visible afterward, and on the result being checkable. Good long-task practice is largely the art of making unattended work trustworthy.

flowchart TD
  A["A long task begins"] --> B["Material piles up in working memory"]
  A --> C["Each step builds on earlier steps"]
  A --> D["You are not watching every step"]
  B --> E["Solution: notes, files, and summaries"]
  C --> F["Solution: checks along the way"]
  D --> G["Solution: clear brief, visible progress, final review"]
  E --> H["A trustworthy result"]
  F --> H
  G --> H
    

The diagram pairs each pressure with its remedy. Limited memory is answered with notes and summaries. Compounding errors are answered with checks along the way. Unwatched work is answered with a clear brief, visible progress, and a final review. The rest of this guide expands each of these answers.

A concrete example of compounding

Suppose you ask for a summary of a hundred customer reviews, and in step two a few reviews are read in the wrong language and mislabeled as negative. The sentiment totals in step four are slightly off. The chart in step six shows the wrong trend. The recommendation in step eight leans in the wrong direction. Nobody made a dramatic mistake, yet the final advice is unreliable. A simple check after step two, such as sampling ten reviews and comparing the labels, would have caught it. This is why checking early is worth more than checking late.

Good long tasks follow a simple rhythm: understand, plan, work, check, and deliver.

Why gathering comes before building

A common beginner mistake, for people and assistants alike, is to start writing before the facts are in. The result looks polished but thin. A better rhythm is to collect the material first and shape it afterward, so that every part of the final work rests on something real. This is especially important for researched reports and comparisons.

Questions before starting

For small tasks, Claude should simply begin. For big ones that are expensive to redo, a few questions up front can save hours. Good questions are few, specific, and easy to answer, such as who the audience is, which format you want, and which sources are allowed. If you will not be around to answer, Claude should state its assumptions and continue. You can control this by saying, in your request, whether you prefer to be asked first or to have defaults chosen and listed.

A visible task list is the easiest way to see where a long job stands, even when you have been away.

In many Claude products, the work is shown as a list of tasks with a status for each one: not started, in progress, or finished. The list sits beside the conversation. Claude updates it as it works, so when you return, you can see at a glance what has been done and what remains, without reading a long transcript.

What a good task list looks like

The list as a shared agreement

The task list is also a quiet contract. It tells you what Claude intends to do, and it lets you object early. If you see a step you do not want, or a missing step you expected, you can say so before effort is wasted. When a plan changes midway, such as when a source turns out to be unusable, a good assistant updates the list and tells you.

Keeping the list honest

A task list is only useful if it is truthful. A step should be marked finished only when its result exists and has been looked at, not merely when work on it began. If a step fails or is skipped, the list should say so, with a short reason. Ask Claude to keep the list truthful, and when you return, check one or two finished items by opening what they produced. Honest lists build the trust that lets you delegate more over time.

When a long job fills Claude’s working memory, the older material is condensed so the work can continue.

The working memory limit

Everything Claude considers in one session sits in its context window. Your messages, its replies, the contents of files it read, and the results of every tool call all take up room. On a short task, there is plenty of space. On a long one, especially one that reads many files or produces large outputs, the window can fill up.

What happens when it fills

Some products handle this by compaction. The earlier part of the work is summarized into a shorter account, and the work continues from that summary together with the most recent material. The summary keeps the essentials: what you asked for, what has been decided, what has been done, and what comes next. Details that are not captured in the summary may no longer be directly in view, which is why important facts should also be saved somewhere durable.

flowchart LR
  A["Early work: read files, make decisions"] --> B["Working memory fills up"]
  B --> C["Earlier material is summarized"]
  C --> D["Work continues from the summary plus recent steps"]
  D --> E["Important facts also saved in files"]
  E --> F["Later steps can re-read the files if needed"]
    

The picture shows two layers of memory. The summary carries the story forward in short form. The files hold the detail in full. If a later step needs an exact figure that the summary dropped, Claude can open the file again. This is why long tasks work best when results are written down as they are produced.

What this means for you

Fresh start with a handover

Sometimes the best answer to a crowded working memory is a fresh session. Ask Claude to write a handover note that includes the goal, the files created, the decisions made, the current state, and the next three steps. Open a new chat, attach or point to the note, and continue. The new session starts with a clear, uncluttered view and only the information it needs. This is often better than pushing a very long conversation further, and it also gives you a natural moment to review.

Where Claude can work with files, the file system becomes a notebook that survives long after the conversation moves on.

In products where Claude has a workspace, it can create, read, and edit files. This is not just for the final deliverable. It is also a way of remembering. Intermediate results, collected facts, progress notes, and partly finished drafts can all be saved. Files do not shrink when the conversation is summarized, and they remain available across the steps of a long job.

What to save along the way

Originals stay safe

A good habit for long jobs is to work on copies and keep your originals untouched. If the job is interrupted or goes wrong, your source material is still intact. Results are written next to the sources as new files, and changes to existing files are made only when you ask for them.

The handover note

For very long jobs, it helps to keep a short note that someone could read to take over. It states the goal, the current state, the key decisions, the open questions, and the next step. If the session ends, or you start a new one, you can point Claude to this note and continue almost seamlessly.

Naming and organizing files

When many files are created, names matter. Use clear names with dates or numbers that show the order, keep sources, working files, and results in separate folders, and avoid overwriting earlier versions when the older one might be useful. A tidy folder lets you open it after a break and understand it in a minute. It also helps Claude find the right file when it needs to reread something.

Big work is safer when it moves in stages, with a pause point after each one.

A checkpoint is a moment where the work is saved, summarized, and, if useful, shown to you. Instead of one giant leap from request to final product, the job moves in steps, and each step ends in something concrete: an outline, a data file, a first draft, a reviewed version. Checkpoints make long tasks easier to follow, to correct, and to resume.

Why stages beat one long leap

Where to put checkpoints

Choosing the size of a stage

Stages that are too big hide problems, and stages that are too small waste time on paperwork. A useful rule is that a stage should be small enough to review in a few minutes, and meaningful enough to produce something you can name. “Collect the sources” and “draft the first three sections” are good stages. “Think about the topic” is too vague, and “fix one comma” is too small. Adjust as you learn how you like to work.

Some big jobs can be split into independent pieces that are worked on at the same time.

When a task has parts that do not depend on each other, such as researching five separate topics, it can be faster to work on them in parallel. In some Claude products, the main Claude can start helper agents, sometimes called subagents. Each helper gets a piece of the job, works on it separately, and reports back. The main Claude then combines the reports.

flowchart TD
  A["Main Claude: understands the goal and makes the plan"] --> B["Helper 1: topic A"]
  A --> C["Helper 2: topic B"]
  A --> D["Helper 3: topic C"]
  B --> E["Reports back"]
  C --> E
  D --> E
  E --> F["Main Claude: combines, checks, and delivers"]
    

When it helps, and when it does not

The cost of splitting

Helpers start with a fresh view. They do not know what the main Claude knows unless they are told. So the instructions given to each helper must be complete, including the goal, the constraints, and the format of the report. Helpers also use their own working room and effort, so splitting a job costs more in total, even if it finishes sooner. Use it when the speed or independence is worth it.

Writing instructions for a helper

A helper agent knows nothing except what you tell it. A good instruction states the goal in a sentence, gives the background it needs, lists what to use and what to avoid, describes the format of the report, and says how long it should be. Think of writing a note to a very capable stranger. If you would need to ask a clarifying question to understand your own note, the helper will need to guess, and guesses multiply across helpers.

Merging results carefully

The main Claude must combine the reports with care. Helpers may use different terms, overlap, or disagree. A good merge removes duplicates, resolves conflicts openly, and checks that nothing from the original plan was missed. Treat the merged result as a draft until it has been verified, as with any other work.

The most valuable long tasks run without you watching, which changes how Claude should behave.

Why unattended work is different

When you are present, Claude can ask a question and wait for your answer. When you are away, a question has nobody to answer it, and the whole job stalls. A well-behaved assistant therefore changes its approach when you are not there. It takes the most reasonable reading of your request, tells you which reading it chose, and carries on. It reserves a full stop for decisions that cannot be undone and could reasonably go either way.

The unattended rules

Telling Claude how to behave when you are away

You can set this up in your brief. A single sentence is enough: “If something is unclear, make a sensible choice and list your assumptions at the end; do not wait for me.” Or, for sensitive work: “Do not send or delete anything without my approval; prepare it and wait.” Stating your preference removes guesswork and makes the result match your comfort level.

Reading the result when you return

When you come back to an unattended task, read in a sensible order. Start with the summary at the top, which should say what was done and which reading of your request was taken. Then scan the task list for anything unfinished. Next, read the assumptions and open issues. Only then open the main deliverable. This order lets you spot a wrong interpretation in seconds, before you spend time reading a long result built on it.

Some work is not long because it is big, but because it repeats on a timetable.

A scheduled task runs at a set time or on a repeating pattern: every weekday morning, every Monday, or once at a chosen moment in the future. Where this feature exists, you describe what should happen and when, and Claude carries it out without you starting it each time. Examples include a daily briefing, a weekly report, a regular check of a website or data source, or a reminder to follow up on something.

How a scheduled run behaves

Each run usually starts fresh, with no memory of earlier conversations. This is an important point. The instruction you save must therefore be complete by itself, naming the goal, the sources, the format, and what to do if something is missing. A scheduled task that says “do the usual report” will fail, because on the day nobody remembers what “usual” means.

Choosing a sensible schedule

More often is not better. A report that nobody reads every hour is just noise and cost. Choose a rhythm that matches how fast the information changes and how fast you can act on it. Avoid setting several tasks to run at the very same moment, and avoid busy hours when delays are more likely. Review recurring tasks now and then, and switch off those that no longer serve a purpose.

Handling failures in scheduled runs

A scheduled task that fails silently is worse than none, because you trust a report that never arrived. Include in the instruction what should happen when something goes wrong: a short message that says what failed, a partial result with the gaps marked, or a stop with no output. Also decide how you want to be told, such as a notification, a file in a known place, or both. Then, when a Monday brief is missing, you will know within minutes whether it was a failure or a quiet week.

A good brief is the single best investment you can make in a long task.

For a short question, a loose request is fine. For a long task, ambiguity is expensive, because a wrong guess early on is built upon for hours. A good brief takes a few minutes to write and prevents rework. It does not need to be long, but it must be clear.

The ingredients of a good brief

A weak brief and a strong brief

Say what to do about doubt

One of the most useful lines in any brief is the one that describes how to handle uncertainty. “If a fact cannot be confirmed, say so instead of guessing.” “If two sources disagree, show both.” “If the data is incomplete, continue with what is there and list the gaps.” These lines turn silent problems into visible ones.

Updating the brief as you learn

A brief is not carved in stone. As the work begins and early results appear, you will learn what you really want. Update the brief, tell Claude what changed, and ask for it to be saved in the notes file. A short message such as “change of plan: the audience is beginners, so simplify the vocabulary” is enough. Updating early costs little. Updating after the task is nearly finished costs a lot.

The more freedom you give Claude, the more important it is to decide what it may do alone.

Autonomy is a dial, not a switch. At one end, Claude suggests and you do everything. At the other, Claude acts on its own across many steps. Most people want somewhere in between, and the right setting depends on the task. Hosts such as the Claude apps let you set or answer approvals, so you stay in control of the actions that matter.

Rules of thumb for granting freedom

Trust that grows with evidence

A practical way to decide how much freedom to give is to start tight and loosen gradually. Run a task with approvals on every outward action. If it behaves well several times, allow the routine parts to run freely and keep approvals only for the sensitive ones. If something surprising happens, tighten again. This is the same way people build trust with new colleagues, and it keeps your confidence based on evidence, not on hope.

When work runs for a long time without you, a few dangers deserve special attention.

Irreversible actions

The first danger is an action that cannot be taken back. Deleting files, sending an email to a customer list, publishing a page, or changing access rights are hard or impossible to undo. In an unattended run, such actions should be prepared but not executed unless you have explicitly allowed them. Preparing means doing all the work up to the final step and presenting it, so that your single approval completes the job.

Untrusted content

A long task often reads a lot of outside material: web pages, emails, documents from other people. Some of this content may contain text meant to trick an AI into doing something else, which is called prompt injection. Claude is designed to treat such content as information to read, not as orders. Still, in long tasks where many sources are read, the safest approach is to limit what Claude is allowed to do with that material, especially actions that send or change things.

Runaway cost

A task that loops or repeats can use a large amount of time and allowance. A poorly defined job may keep exploring, or a failing step may be retried again and again. Sensible limits, such as a maximum number of items, a time budget, or a rule to stop after repeated failures, keep the cost predictable.

Privacy of what it collects

Long tasks gather files, notes, and intermediate results. Think about where these end up, who can see them, and whether they contain private information. Keep them in places you control, and delete working files that are no longer needed.

Shared and work environments

If you use Claude at work, remember that long tasks may touch company systems, files, and customer data. Follow your organization’s rules about what may be processed, where results may be stored, and who may see them. If a connector or a tool is not approved, do not look for a workaround; ask your administrator. Boundaries set by your organization exist to protect people and data that you may not see from where you sit.

You do not need to watch every step, but you should be able to see what happened.

Monitoring a long task is less about staring at it and more about leaving good traces. These traces let you check in whenever you like, let others understand the work, and help you find the cause if something goes wrong.

What to look at when you return

Measures that tell you how it is going

These measures are habits of attention, not fancy dashboards. If you ask Claude to end each stage with a two-line status, “done, next, problems”, you will have most of what you need. For recurring tasks, keep a simple history of past runs so you can compare today’s result with last week’s.

Reading a status update well

A good status update has three parts: what is done, what is next, and what is wrong. Read the third part first. A status that lists no problems on a long, complicated task deserves a second look, because real work almost always meets small trouble. Honest updates mention uncertainties, skipped items, and assumptions. If an update is only cheerful, ask for the details behind it.

The last step of every long task is to check the result, and for important work, to have someone else do it.

Verification means testing the work against reality instead of assuming it is right. Facts are compared with their sources. Numbers are recomputed by running the calculation. Documents are opened and read. Pages are looked at as a reader would see them. This is not pessimism; it is how reliable work is made.

What to check, by type of output

The value of a fresh pair of eyes

A person who has just finished writing a report often cannot see its flaws, because they know what they meant. The same is true of any worker. For high-stakes tasks, a separate reviewer who did not see the work being produced has a real advantage. In some products, a separate helper agent can play that role. Alternatively, you can open a new chat, give a reviewer instruction and the finished work, and ask for problems only.

flowchart LR
  A["Work is produced"] --> B["Self-check: facts, numbers, format"]
  B --> C{"Is it high-stakes?"}
  C -- "No" --> D["Deliver with notes on assumptions"]
  C -- "Yes" --> E["Independent review by a fresh reviewer"]
  E --> F{"Problems found?"}
  F -- "Yes" --> G["Fix and re-check"]
  G --> B
  F -- "No" --> D
    

Make checks part of the plan

Verification works best when it is planned from the start and not squeezed in at the end. Ask for the last item in the task list to be “check the work”, and for the earlier items to produce things that can be checked: sources saved beside facts, formulas visible in spreadsheets, and tests for any code. If a result cannot be checked, say so plainly in the final note, so that you and your reader know how much to trust it.

Every long task meets trouble sooner or later, and the difference is how gracefully it recovers.

Principles of good recovery

Learning from each failure

After a problem is fixed, spend a minute asking why it happened and what would have prevented it. Maybe the brief lacked a rule, the sample step was skipped, or a note was never saved. Add the lesson to your brief template or checklist. Over time your own set of habits grows, and each long task goes more smoothly than the last. The aim is not to avoid every problem, but to make each problem happen only once.

Long tasks use more of everything, so a little planning keeps them affordable.

Every step of a long task reads and writes text, and text is measured in tokens. Reading many files, running many tool calls, and writing long outputs all add up. In addition, working in parallel with helper agents multiplies the total. Plans and allowances differ, and how usage is counted can change, so check the help center for current details. The principles below hold regardless.

The cheapest hour is the one you do not repeat

The biggest waste in long tasks is usually not a clever inefficiency but a misunderstanding. Hours spent producing the wrong thing cost far more than a few minutes spent clarifying the goal. That is why the brief, the plan, and the early sample are not formalities. They are the cost-control tools with the best return.

Setting a budget

For big jobs, it helps to name a budget before starting. It might be a number of items to process, a rough time limit, or a rule such as “stop and report if more than ten sources fail”. Claude can then plan within the limit, choose cheaper methods where they are good enough, and tell you when the limit is near. A budget turns a vague worry about cost into a clear boundary that both of you can follow.

Handing over long tasks saves your time, but it needs trust that has to be earned and checked.

Main trade-offs

When not to use a long task

Not every job belongs in a long run. If the goal is unclear even to you, spend time clarifying it first. If the work needs your constant judgment, such as a delicate conversation, work with Claude step by step. If a single mistake would be severe and cannot be checked, do it more directly with close supervision. Long tasks shine when the goal is clear, the work is substantial, the steps can be checked, and mistakes can be corrected.

Some habits make long tasks calm, and others make them chaotic.

Six examples show long tasks that go well.