Claude Tag's 'Multi-Day' Mode Is A $4K Billing Trap

By Lazar Milicevic · Published August 13, 2026 · 7 min read

Anthropic shipped Claude Tag with a phrase that made it go viral: persistence over days. Tag Claude in Slack, walk away, get pinged Monday. Sounds like a teammate. It's a cron job with a wallet. I've built three async agent systems for clients this year, and the exit condition on every viral demo is the same thing: an LLM deciding, in a loop, when the job is done. Here's what breaks and what to build instead.

What "persistence over days" actually is under the hood

Persistence over days is three components stitched together: a state store holding conversation and tool history, a scheduler that re-invokes the agent on cron or event triggers, and a tool loop where the model calls a function, reads the result, calls another function, and keeps going until it decides it's done. Every re-invocation replays context. Every tool call costs tokens. The exit condition is a probability distribution.

That last part is the one that should scare you. You are trusting a language model to know when a job is finished, in a loop, with your billing key attached. There is no while (task.done) you can inspect in a debugger. The model emits a stop token when its own weights say the work looks complete. Sometimes that's after 3 tool calls. Sometimes 47. Sometimes it re-reads the same doc four times because retrieval returned near-duplicates.

Three things fail here in production:

• Context replay tax. Each wake-up ships the accumulated conversation back into the prompt. A 40K-token thread that runs six times over a weekend is 240K tokens billed, minimum, before any new work happens.
• Tool loop drift. The model tries an API, gets a 429, "reasons" about retry, tries again, calls a different tool, comes back. Real logs from my systems show 8-12x more tool calls than a human would use for the same task.
• Silent completion. The model returns a final message that reads plausible. Nobody verifies whether the work was actually done correctly.

The real math: $0.02 per task vs $2-$15 per task

Here are numbers from a system I run for a US-based SMB client, roughly 40 async tasks a day across email triage, CRM updates, and lead enrichment.

Now put that inside a Slack workspace with 30 people casually tagging the bot into threads. Nobody is watching individual runs. Nobody knows the difference between a tag that costs 2 cents and one that spins for six hours. You land the invoice, and it's $4,000 you didn't budget for.

The bill is the loud failure. The quiet one is worse.

The quiet-wrongness problem is the real liability

The agent posts a confident reply in a Slack thread. Someone on your team reads it, trusts it, and acts on it. They send the customer email. They approve the refund. They update the CRM record. There is no audit trail pointing to a checkpoint because there was no checkpoint. The human is now the one who executed the wrong action, and they did it because the bot sounded sure.

This is the pattern I see fail most often in async agent deployments:

• Bot replies confidently in a channel where 8 people are watching.
• One person reads it while doing something else, treats it as verified work.
• Action gets executed downstream in another system.
• Two weeks later a customer complains, and there is no log tying the wrong action back to the model version, the prompt, or the tool calls that produced it.

Anthropic's demo skipped who reviews the output before it becomes a message the whole team acts on. That question has exactly one right answer in a real business: a named human, reviewing in the interface they already live in.

The four checkpoints I bake into every async agent

Before the first token is spent on any async task I ship, four hard limits are already in the code. These are non-negotiable, and they are what separates a working system from a launch video.

1. Max-token cap per run. Fails loud, not silent. Between 5,000 and 50,000 tokens depending on the job. The wrapper aborts and pings me if we hit it.

MAX_TOKENS_PER_RUN = 15_000
MAX_TOOL_CALLS = 10

def run_agent(task):
    total_tokens = 0
    tool_calls = 0
    while not task.done:
        if total_tokens >= MAX_TOKENS_PER_RUN:
            raise BudgetExceeded(f"Hit {MAX_TOKENS_PER_RUN} on {task.id}")
        if tool_calls >= MAX_TOOL_CALLS:
            raise LoopExceeded(f"Hit {MAX_TOOL_CALLS} on {task.id}")
        step = model.step(task.state)
        total_tokens += step.usage.total_tokens
        if step.tool_call:
            tool_calls += 1
            step.tool_call.execute()
        task.state = step.state

2. Max-loop counter. The agent gets 8, 12, or 20 tool calls, forced stop, forced report. If it hasn't finished, that's information — a human decides whether to extend, not the model.

3. Mandatory human checkpoint before any write action. Sending an email, updating a CRM record, pushing an invoice, posting to a wide channel. Everything with side effects pauses, pings a human on Telegram or WhatsApp, waits for a thumbs up. The agent proposes. The human approves. Only then does anything hit production.

4. Per-run and per-day spend ceiling. Checkpoint every 60 seconds of runtime or every 10 cents of spend, whichever comes first. If the bot hits $5 in a day for a single user, it stops and asks. Not silently. Loud.

Every run also gets a structured log: model version, prompt hash, tool calls made, human who approved each write action, final token count. If something goes wrong two weeks later, I can reconstruct exactly what happened.

What to actually copy from Claude Tag (and what to skip)

The tag-and-forget UX is genuinely good. Users don't want another dashboard. They want to mention the bot in the tool they already use and get pinged when work is done. That interaction pattern is maybe 50 lines of code on top of the Slack, Telegram, or WhatsApp API.

• Copy: the mention-and-notify pattern, threaded replies for context isolation, one clear "done" ping.
• Copy: async job queue so the user isn't blocked waiting.
• Skip: unbounded runtime. Every job has a hard wall-clock and token ceiling.
• Skip: the model deciding when it's done on write actions. A human decides for anything that touches money, customer data, or an outbound message.
• Skip: trusting the reply text as verified work. Every action that matters gets a checkpoint ping to a named human before execution.

The hard part is not the UX. It's the guardrail layer underneath. Async, yes. Persistent across days with no checkpoint, no.

Common mistakes I see teams make on their first async agent

• No spend alarm at the API-key level. Set a hard monthly limit in the Anthropic console and a daily soft alert to Slack or email. Every provider gives you this. Use it.
• One shared API key across all agents. You cannot attribute cost. Give every agent its own key, tag every request with a user_id and task_id in metadata.
• Logging only the final response. Log every tool call, every token count, every model version. If you can't reconstruct a run, you can't debug it.
• Human approval by email. Approvals need to happen where the person already checks 20 times a day. For most SMB operators, that's Telegram or WhatsApp, not another dashboard.
• Treating the agent's reply as an audit trail. The reply is output. The log is truth. Never confuse them.

Where bizflowai.io fits

At bizflowai.io we build these async agents for solopreneurs and small teams with the four checkpoints baked in from day one. Every deployment ships with token caps, loop limits, human approval routing to Telegram or WhatsApp, and structured logging that lets the operator see what was spent, what was decided, and who approved each write action. Clients running our systems handle 40+ async tasks a day for under a dollar, with zero silent failures reaching production.

The prediction

Six months from now, the Twitter threads will show up. The $4K bill screenshots. The Slack channels full of confidently wrong replies that got acted on. Teams quietly turning the feature off. Async agents are the right direction. Unbounded persistent agents without checkpoint gates are a liability the vendor has offloaded onto the customer. If you're a founder, your job is to put the gates back in before you turn it on.

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

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

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

Visit bizflowai.io for our services, case studies, and AI consulting.