Organizing about 20 sources, classifying about 30 customer messages, modifying code and running tests, and reading customer information to prepare a reply are all examples of what this lesson calls a long task. The defining factor is not elapsed time but the shape of the work: many inputs, multiple dependent steps, possible retries or data changes, and an outcome that cannot be judged safely from the final answer alone.
Once this kind of task starts, AI may keep reading data, rebuilding context, and retrying automatically after failures. After a few rounds, nobody can immediately answer three questions: how much has already been spent, where it should stop, and who is responsible for final acceptance. For small teams, the real risk is not whether the model can run more steps, but that the scope keeps expanding while cost and accountability boundaries fade.
Models like Grok 4.5 can make long tasks that were previously too expensive, too slow, or too likely to fail partway through feel more worth testing. After SpaceXAI announced Grok 4.5, both TechCrunch and Engadget focused on model capability, pricing, and possible uses in coding (writing and editing code with an AI) and agentic work (AI performing multi-step tasks). But no team should decide based only on benchmarks—standardized tests used to compare model performance—or on how long the model can run.
A practical starting point is to define for each task how many tokens, how much context, and how many retries it has, and when human approval is required. A token is the basic unit the AI uses to split and process text, and it affects both cost and context capacity. An agent is an AI assistant that can execute multiple task steps autonomously in sequence. When these two are combined, unlimited read, edit, and retry behavior can quickly become unmanaged spend.
Therefore, research summaries, document cleanup, code changes, and customer-support drafts should not be treated as “let AI run longer.” They require distinct task levels, stop points, and human accountability. Even strong model capability cannot replace team-defined boundaries.
This lesson is not a Grok 4.5 benchmark and does not endorse any specific model. What we do instead is build a practical token-and-cost cap table before bringing any long-running model into a team workflow (a repeatable sequence of handoffs).
In this lesson
You will take away three things:
- A “task tier × limit setting” decision table to decide which tasks can run automatically and which ones require human approval.
- A 5-step rollout process so you do not place a long-running agent directly into production data or publishing workflows on day one.
- An AI handoff card you can give to an AI, asking it to generate a first version of cost guardrails for your own task list.
First, separate the task types: long-running AI is not one switch
When teams try a new model, they often ask: “Should we open this model for everyone?”
That question is too broad. A better question is: “Which kinds of tasks can run automatically to completion? Which kinds can only run to draft? Which kinds need a human check at every step?”
For example, even if all of these use an AI agent:
- Summarizing 20 public documents into a research brief is one kind of task.
- Editing code in a repository and opening a pull request (a proposal to merge code changes after review) is another.
- Reading customer data, sending replies, and updating a CRM (customer relationship management system) sits at a completely different risk level.
If you are letting an agent write code, read this alongside: Before letting an AI agent write code, put checkpoints into the task. That article focuses on where to place stops inside the task. This lesson adds how many tokens, how much money, and how many retries the agent can spend before each stop.
One table to decide how far a task can run, how much it can spend, and when it must stop
You can take the table below directly into a meeting. The point is not to copy every number forever. It gives you a conservative starting point. Run it for two weeks, then adjust based on actual costs.
For this table, one task run includes every model call from the initial request until stop/completion, and token usage is cumulative input+output across all calls. Retries are inside the same total token and total cost caps; they do not get fresh budgets.
| Task tier + examples | Execution cap | Stop point + human responsibility |
|---|---|---|
| L1: Low-risk draft (meeting records cleanup, public article summaries, internal document rewriting) | 20,000 tokens / US$1 / max 1 retry; all attempts share the same cumulative token + total cost caps | Stop before sending output externally or posting on a public page; responsible person reviews and approves |
| L2: Medium-risk analysis (competitor research cleanup, customer support case classification, specification comparison) | 60,000 tokens / US$5 / max 2 retries; all attempts share the same cumulative token + total cost caps | Stop before affecting product decisions, customer commitments, or schedule; responsible person reviews and approves |
| L3: High-risk change (code edits, bulk data changes, contract/policy drafts) | 100,000 tokens / US$10 / max 1 retry; all attempts share the same cumulative token + total cost caps | Stop before writing to a code repository, database, contract, payment, or permission system; the responsible person reviews the proposed changes, tests, impact, and recovery plan |
| L4: Suggestions/drafts only (deleting data, formal notices, changing billing, refund approvals, permission upgrades) | 20,000 tokens / US$1 / no retries; suggestions/drafts cap only; side-effect execution budget: US$0 | If deletion, payment, formal notice, or permission upgrade is required, stop immediately. Side-effect execution authority: none. The responsible person reviews the suggestion and performs the final action personally |
This table has several important points.
First, token limits and cost limits should both exist. If you only set a cost limit, the model may still read too much data inside a cheap but very long context. If you only set a token limit, an expensive model can still overspend. Setting both limits together reduces the chance of losing control.
Second, retries are included in the same cumulative budgets. The cost of many long-running agents does not come from the first attempt. It comes from automatic retries after failure, repeated searches, and rebuilt context. If L2 allows 2 retries, all three attempts must stay within one total task budget cap. If the token or cost cap is reached, the task should stop.
Third, L4 should not be disguised as “just add one confirmation sentence.” Cost limits and authorization are separate controls. AI can produce suggestions and drafts within independent suggestions/drafts caps, but its side-effect execution authority and side-effect execution budget must both remain at zero. It must not receive authority to delete data, make payments, send formal notices, or upgrade permissions. The responsible person reviews the suggestion and performs the final action personally.
If your agent also touches identity, permissions, reasons, and consequences, read this next: The AI agent authorization four-question table: identity, permission, reason, consequence. Cost guardrails control “how much it spends.” Authorization guardrails control “what it is allowed to do.” You need both.
A 5-step rollout for small-team workflows
Once you have a limit table, the next step is not to open it to the whole company. Start with one small path. The process below fits small teams of 3 to 20 people, especially teams without a dedicated AI platform team.
1. Start with one long task whose output can be checked
Do not choose a vague first task like “help me become smarter.” Choose a task whose output can be checked and whose failure can be recovered, such as:
- Turn 15 public documents into a one-page summary.
- Classify 30 customer support messages into 5 categories and list 3 representative examples for each category.
- Read a small pull request and list the files that may need human review.
- Rewrite an internal SOP for new hires, without publishing it directly.
The test is simple: if the output is wrong, can you notice it within 10 minutes? If not, it should not be your first pilot task.
2. Write down “what it may read at most”
Long tasks can easily consume the entire context. Context means the material the AI can currently read, remember, and use for reasoning. More reading does not always mean more accuracy. When the data boundary is unclear, the AI is more likely to mix in outdated or irrelevant material.
Write the task specification explicitly:
- It may only read specified folders or specified URLs.
- It may read at most 10 files per run.
- For each file, it may only read the title, summary, and most recent 30 changed lines unless the responsible person approves more.
- It must not read customer personal data, payment data, secrets, internal salary data, or original contract text.
These constraints are more useful than saying “please handle this carefully,” because they can be enforced programmatically.
3. Separate dry-run from real execution
A dry-run (a trial run that does not change data or publish anything) means testing the task without any production effect. When a long-running agent enters a workflow for the first time, it should default to dry-run only.
For example, a coding agent may:
- Read the issue (the ticket describing requested work).
- Find related files.
- Propose an edit plan.
- Generate a patch draft (the proposed code diff).
- Suggest tests to run.
But it must not directly:
- Push to the main branch.
- Merge a pull request.
- Change production config (the settings for live production systems).
- Publish a package.
The same applies to a document agent. It can generate drafts and summaries of proposed changes, but it should not directly overwrite official documents. After you have reviewed 5 to 10 dry-run outputs and the failure patterns are predictable, then consider opening the next step.
4. Write stopping conditions as if–then rules
Do not write stopping conditions as abstract reminders. Write them as if–then rules:
- If a task is estimated to exceed the token or cost cap approved for its tier, output a plan first and do not enter full execution. For example, an L2 task with a 60,000-token cap should pause before crossing that limit and let the responsible person decide whether to narrow scope.
- If the task still fails after reaching the retry limit approved for its tier, stop, record the latest error, and ask the responsible person whether to narrow the scope, use another method, or end the task. L1 and L3 stop after one failed retry, L2 allows at most two retries, and L4 allows none.
- If the task needs to read a data source that is not on the allowlist (the approved source list), stop and list the reason.
- If the output will change content visible to external users, stop at draft status.
- If the task involves payment, deletion, permission upgrades, or formal commitments, generate suggestions only and do not execute.
These sentences can go into an agent system prompt (the instruction block loaded into the model) to tell the model when it should stop proactively. But a prompt is not a hard billing meter, permission system, or reliable kill switch. A controller outside the model must enforce the real token, cost, and retry limits. It should accumulate reported input/output tokens, tool charges, and retries, then check the remaining budget before every new call. If the remaining budget cannot accommodate the next call, it should not send the request and should return only the current result and items awaiting a human decision. For deletion, payment, formal sending, publishing, and permission upgrades, do not grant execution credentials at all; do not rely on a prompt that merely says “do not do this.”
5. Adjust only one knob each week
After the pilot, you will likely see a few common outcomes:
- Tasks often hit the token limit before completion.
- Cost is low, but human review takes too long.
- Retry count is too high, making total cost unpredictable.
- Low-risk tasks are blocked too often, while high-risk tasks move too easily to the next step.
Do not adjust everything at once. Change only one knob per week, for example:
- Raise the L1 token limit from 20,000 to 30,000.
- Lower the L2 retry limit from 2 retries to 1 retry.
- Change L3 from “may generate a patch” to “may only generate an edit plan.”
- Add one responsible person confirmation field before external publishing.
A small team’s biggest advantage is not having many governance documents. It is seeing quickly which limit is too tight and which stop is too loose. Adjusting one knob at a time tells you which change actually worked.
Common mistake: treating a cheaper model like a free employee
When model prices drop, teams easily make three mistakes.
The first mistake is looking only at the per-call API price. An API is the interface through which systems exchange data with other systems. For long-running tasks, API unit price is only one part of the total cost. The real total also includes context preparation, retries, human review, error repair, and debugging time when the task gets stuck.
The second mistake is putting every task into the same queue. A queue is a list of pending tasks. If low-risk summaries, high-risk code changes, and formal customer replies all sit in the same queue, it is hard for an agent to handle them safely with one set of rules. At minimum, separate tasks into “draft,” “analysis,” “change,” and “must not auto-complete.”
The third mistake is leaving no traceable record. You do not need a heavy audit system at the beginning, but you should at least record: task name, model, input data scope, token usage, estimated cost, whether it retried, and who gave final approval. Without these records, two weeks later you will only know that “it seems a bit expensive,” but not which task type is burning money.
The first executable version for a small team
If you can do only one thing today, create a “long-running AI task request card.” You do not need a new tool. Notion, Google Sheets, Linear, or a GitHub issue template all work.
Recommended fields:
- Task name: for example, “summarize 15 competitor announcements.”
- Task tier: L1, L2, L3, or L4.
- Allowed data sources: list folders, URLs, or document names.
- Forbidden data sources: for example, customer personal data, payment data, secrets, original contract text.
- Context cap: for example, read at most 10 files per run, the latest 30 changed lines per file, or up to 40,000 input tokens. If exceeded, summarize first and ask the responsible person whether to continue.
- Token limit: use the starting value from the table.
- Per-run cost limit: use the starting value from the table.
- Retry limit: 0, 1, or 2 retries.
- Stopping conditions: write at least 3 if–then rules.
- Owner: who reviews the output and approves the next step.
- Output status: must be one of draft, suggestion, patch, or real execution.
The purpose of this card is not to add administrative overhead. It is to make sure everyone knows how far the AI may run, where it must stop, who must review it, and how much spending is too much.
AI handoff card
You can give the following text directly to an AI and ask it to generate a first version of limits for one type of long-running task. Replace the brackets with your actual situation.
You are our small team’s AI workflow design assistant. Please help me create token, cost, retry, and human approval limits for the following long-running task.
Task name: [for example: summarize weekly competitor announcements]
Task goal: [one-page summary, classification table, edit plan, customer support draft, etc.]
Allowed data sources: [list folders, URLs, document types]
Forbidden data sources: [personal data, payment data, secrets, contracts, unreleased financial data, etc.]
Will the output be externally visible: [yes/no]
Will it modify code, databases, permissions, or payment status: [yes/no]
Acceptable human review time per run: [for example: 10 minutes]
Please output:
1. Recommended task tier: L1/L2/L3/L4, with reasons.
2. Per-run token limit and per-run cost limit.
3. Retry limit.
4. Context cap: for example, max 10 files per run, latest 30 changed lines per file, or max 40,000 input tokens; if exceeded, summarize first and ask whether to continue.
5. At least 3 if–then stopping conditions.
6. Which steps must stay dry-run, and which steps may enter real execution after responsible person approval.
7. A minimal task request card field list.
8. Stopping reminders written for the model.
9. Token/cost/retry checks that an external workflow controller must enforce.
10. Side-effect capabilities that must be removed at the tool-permission layer.
Constraints:
- Do not assume you can read data that is not listed.
- Do not recommend automatically deleting data, making payments, sending formal notices, or upgrading permissions.
- Do not treat a system prompt as a hard cost meter or permission control.
- If information is insufficient, list the questions the responsible person must answer instead of approving the task directly.
After using the handoff card, do not turn the AI’s answer directly into policy. Ask a responsible person to review it and confirm at least three things: whether the data scope is correct, whether the stopping conditions are explicit, and whether the cost limits match your actual budget.
Everyday four-panel comic
- Before moving, three friends look at three boxes in the room and think the work will be manageable.
- When they open the closet and shelves, they discover far more belongings than they expected.
- The three friends pause and limit today’s work to a simple three-item checklist containing only what they have agreed to handle.
- They seal only the agreed boxes and leave everything else neatly in place for next time.
References
xAI official blog: Introducing Grok 4.5 — https://x.ai/news/grok-4-5 (2026-07-08)
TechCrunch: SpaceXAI releases Grok 4.5, which Elon describes as an ‘Opus-class model’ — https://techcrunch.com/2026/07/08/spacexai-releases-grok-4-5-which-elon-describes-as-an-opus-class-model/ (2026-07-08)
Engadget: SpaceXAI Launches Grok 4.5, Its First Built With Cursor’s Help — https://www.engadget.com/2211260/spacex-ai-grok-4-5-cursor/ (2026-07-09)
