AI Automation Pipeline Token Plan Failure Post-Mortem: 5 Real BUDGET_STOP_FLAG Misjudgment Scenarios and Human-Semantics Rule v6

My OpenClaw AI automation pipeline hit 3 concurrency conflicts back-to-back in W30 (2026-07-20) — concurrency / path bug / is_en — pushing all 4 article-generation cron jobs to the edge of collapse. While writing the post-mortems for those 3, I traced the timeline back to 2026-07-04 10:35 AM — that day, none of the 6AM/12PM/18PM/22PM jobs failed directly. **The prompt that added the budget cap itself was broken.** The original prompt used ls /tmp/article-gen/BUDGET_STOP_FLAG 2>/dev/null shell syntax, which the LLM misread as "if BUDGET_STOP_FLAG exists, skip publishing." In an isolated session, the LLM interpreted it as "**as long as this query returns anything** (including ls's own stderr warnings, permission denied errors, etc.), the cap is on" — and a force-run at 10:35 burned 7.31M tokens before being noticed. This article breaks down 5 real misjudgment scenarios, walks through the human-semantics rewrite, touch/rm switches, and 3-step verification protocol across the 4 cron jobs, and promotes this rewrite to permanent standard v6 (continuing from v3 flock lock, v4 metadata-driven slug fix, v5 is_en fix). If you also run LLM article-generation crons, budget cap is upstream of every other guard — one bad line can drain the entire monthly token allocation.

⏳ Too Long; Didn't Read

• **Root cause**: The 7/4 10:35 budget cap prompt used `ls ... 2>/dev/null`. In the isolated session, the LLM treated "any stderr output" as "cap is on" — single force-run consumed **7.31M tokens** (vs normal 540K, 13.5× overspend).
• **Symptom**: The 4 article-generation crons (6AM/12PM/18PM/22PM) had a probability of **early-stopping** — one 6AM run, the AI called `sys.exit(0)` directly at Phase 0, no file written, no pipeline run, the next day the owner discovered 0 articles published.
• **First-version misjudgment**: `ls /tmp/article-gen/BUDGET_STOP_FLAG` returns non-zero (file doesn't exist) → the LLM treats it as "query failed = file doesn't exist = cap not on = continue." This is **accidentally correct.** But in subsequent cron sessions, the `ls ... 2>/dev/null` stderr behavior plus path expansion makes the AI oscillate between "skip" and "continue."
• **Human-semantics version v6** (already in effect): the prompt header is rewritten to:

> 【Budget Cap Check (Human Semantics Version)】

> Step 1: Check whether the file /tmp/article-gen/BUDGET_STOP_FLAG exists.

> - If it exists, immediately output "⏸️ Budget cap is on, skipping this publish" and end the task.

> - If it doesn't exist, continue the normal task.

Key change: let the AI do a semantic judgment (does the file exist?), not parse shell output.

• **Complete governance loop (v3 → v4 → v5 → v6)**:

- v3 flock lock: solves /tmp/article-gen/ multi-session overwrite (concurrent write conflicts)

- v4 metadata-driven: solves flock side-effects (slug misalignment, EN duplicates, empty titles)

- **v5 generate-html.py is_en fix**: solves is_en = basename.startswith('en') misjudging *-cn.txt as CN

- v6 human-semantics budget cap: prevents the LLM from misreading the cap switch prompt at the source

• **3-step verification**: touch flag → cron immediately outputs ⏸️ → rm flag → cron runs normally; any step failing to behave as expected means the prompt is broken and must be rolled back immediately.
• **Permanent standard v6 promotion condition**: any LLM cron prompt header's "switch judgment" MUST use human semantics (**check whether file X exists**); `ls ... 2>/dev/null` / `if [ -f ... ]; then` syntax requiring the AI to parse shell output is forbidden.

Why Budget Cap Is "Upstream Governance"

The concurrency lock (v3) and metadata-driven fix (v4/v5) all solve "who touched my cn.txt" at the write-file / run-pipeline / push-GitHub stage. But budget cap is further upstream — after the AI session starts, before reading the prompt — deciding "should today's publish run at all." Once it fails, all downstream guards are useless: even if v3 flock lock works perfectly and v5 is_en is always correct, the 7.31M-token single-run waste directly eats one-third of the monthly budget (measured on 7/4).

What makes it more insidious is that budget cap failure doesn't need to trigger every time. It's a probabilistic misjudgment: before 7/4 10:35, 3 force-runs happened to work correctly (stderr didn't push the LLM to the wrong branch), but the 4th one went wrong. That's why 7.31M-token waste happened "suddenly" instead of "gradually accumulating" — until the LLM state distribution shifted into the wrong branch, the owner wouldn't notice.

Practical impact: budget cap must work with 100% reliability. Any probabilistic misjudgment is unacceptable. That's why v6 forces human-semantics rewrites: let the AI do what it's good at (semantic judgment: does the file exist? is the path valid?), instead of having it parse shell exit codes (exit code, stderr, redirection).

💣 Crash Log: 5 Real Misjudgment Scenarios (Reverse Chronological)

Scenario 1: 7/4 10:35 force-run wastes 7.31M tokens (worst)

Symptom: On the morning of 7/4, the owner had the AI add a budget cap to the 12PM cron prompt header. The AI produced v1:

Step 1: Check token balance
ls /tmp/article-gen/BUDGET_STOP_FLAG 2>/dev/null
if [ $? -eq 0 ]; then echo "⏸️ Budget cap is on"; exit 0; fi

The owner force-ran at 10:35 to verify. The AI spawned a subagent, the subagent saw the prompt and **parsed the ls exit code** — but in the isolated session, 2>/dev/null's stderr suppression was **invisible** to the LLM. The LLM only saw "ls didn't produce any file path I can recognize," so it inferred "ls didn't find the file = cap not on = continue." **This time it accidentally ran correctly** (because it misjudged as "continue" instead of "skip," the right direction).

But at 11:42 the owner added the same check to the 6AM prompt header, and this time the AI made the opposite inference — "ls returned no file path = stderr suppressed = possibly an error = treat cap as on = skip." This force-run triggered 6AM skip + 12PM re-execution — two AI subagents launched simultaneously, eventually consuming 7.31M tokens to publish a single 12PM USB-C HDMI 4K@60Hz article.

**Root cause**: When the LLM sees ls ... 2>/dev/null in an isolated session, it will **invent a reasonable inference** — but the inference direction (skip / continue) is **random**, depending on the most recent few tokens in the context window. This kind of "let the AI parse shell output" pattern is, by itself, injecting uncertainty into the prompt.

Fix: v6 human-semantics version — hand the judgment semantics directly to the AI:

Step 1: Check whether the file /tmp/article-gen/BUDGET_STOP_FLAG exists
(use the exec tool to call `test -f /tmp/article-gen/BUDGET_STOP_FLAG && echo EXISTS || echo MISSING`
 and decide based on whether stdout is EXISTS)

But the better way is to **let the AI call an explicit semantic tool** (e.g., the read tool to stat this file). This turns "judgment" from "shell exit code inference" into "file metadata query," and the LLM's state distribution has no effect on the outcome.

Scenario 2: 6/22 12PM posts a false "low budget warning" tweet (second worst)

**Symptom**: After 6/22 12PM finished, the AI itself added: "⚠️ Note: current token balance is low, owner is advised to manually touch /tmp/article-gen/BUDGET_STOP_FLAG." But **at that time the token balance was actually 78%**.

**Root cause**: The LLM tripped over the "disk full" keyword in the tool description when calling exec to run df -h (disk), and confabulated disk-space-low information into token-balance-low. Same pattern, this time "direction right" (reminding the owner) but "fact wrong" (78% misjudged as low).

**Fix**: v6 explicitly specifies — the AI does NOT proactively estimate token balance. Budget judgment **only has one method**: touch /tmp/article-gen/BUDGET_STOP_FLAG (owner one-keystroke pause). The AI doesn't need to predict, doesn't need to warn, doesn't need to make the owner decide.

Scenario 3: 7/4 12PM prompt got truncated → flag permanent (subtle)

**Symptom**: On 7/4 13:00 the owner resumed 12PM (rm /tmp/article-gen/BUDGET_STOP_FLAG). But the 6/22 "warning post" had given the owner a habit — **always run ls after a run**. When ls was run at 7/4 13:00, the flag was still there (because when the owner did rm at 13:00, it was only rm /tmp/article-gen/BUDGET_STOP_FLAG, but what 6/22 actually created was /tmp/BUDGET_STOP_FLAG, missing article-gen/).

**Root cause**: The v1 prompt wrote the flag path as /tmp/BUDGET_STOP_FLAG. All the owner's rm operations after 6/22 were based on this wrong path. As a result, when the 7/3 22PM recap task ran, it skipped after 30 seconds (cap still on), and the owner didn't notice.

**Fix**: v6 fixes the flag path to /tmp/article-gen/BUDGET_STOP_FLAG. Both the prompt and owner operations are based on this path. **Any cron prompt must spell out the full path**, no subdirectory abbreviations allowed.

Scenario 4: 7/12 6AM prompt change with insufficient force-run retest (lesson)

**Symptom**: On the morning of 7/12, the owner modified the 6AM prompt header (adding budget cap + 5 tools limit + 900s timeout), and the AI deployed **without force-run verification**. As a result, on 7/12-7/13 — fully 2 days — 6AM tasks published 0 articles, and the owner didn't see the 7/13 6AM log full of ⏸️ Budget cap is on until later — but **the token balance was actually 65%**.

Root cause: That 7/12 prompt change put the budget cap check at the very end (after the tools list). When the AI session started, the tools initialization failed, the whole prompt parsing failed, and the AI fell back to "skip to be safe."

**Fix**: v6 mandates the budget cap check as the very first line of the prompt (before any tool list), and any prompt modification must do 3-step verification (touch → skip ✓ / rm → continue ✓ / test -f returns immediately ✓) — non-negotiable.

Scenario 5: 6/27-6/28 `wc -c` misjudges empty file as "cap on" (most subtle)

**Symptom**: After 6/27 22PM finished, 6/28 6AM's budget cap judgment logic (v2, using wc -c /tmp/article-gen/BUDGET_STOP_FLAG) — because wc returned an empty string in the isolated session — the AI interpreted it as "file size 0 = flag exists but is empty = should skip." Result: 6/28 6AM skipped directly, 0 articles published.

**Root cause**: wc -c returning 0 could mean "file doesn't exist" or "file exists but is empty." The LLM in an isolated session has no way to distinguish these two cases.

**Fix**: v6 mandates using test -f for unambiguous judgment (returns 0 if file exists, 1 if not), instead of wc -c / ls patterns that "return a string for the AI to parse."

🛠️ Practical Fix: v6 Human-Semantics Permanent Rule

Fix 1: Prompt Header Rewrite (in effect since 2026-07-04 11:00)

v1 (deprecated):

【Budget Cap Check】
Step 1: ls /tmp/article-gen/BUDGET_STOP_FLAG 2>/dev/null
If it exists, skip; otherwise continue.

v6 (permanent standard):

• If it exists, immediately output "⏸️ Budget cap is on, skipping this publish" and end the task.
• If it doesn't exist, continue the normal task.

【Budget Cap Check (Human Semantics Version)】
Step 1: Check whether the file /tmp/article-gen/BUDGET_STOP_FLAG exists.

Key differences:

• v1 lets the LLM parse shell output (exit code / stderr / path)
• v6 lets the LLM use the `read` tool or `exec test -f` to directly query file metadata
• v6's semantics is "**file exists**", not "**shell exit code**" or "**ls return value**"

Fix 2: Owner One-Keystroke Pause Switch

# Owner wants to pause:
touch /tmp/article-gen/BUDGET_STOP_FLAG

# Owner wants to resume:
rm /tmp/article-gen/BUDGET_STOP_FLAG

# Verify cap status (no AI involved):
test -f /tmp/article-gen/BUDGET_STOP_FLAG && echo "⏸️ Paused" || echo "✅ Publishing normally"

Fix 3: 3-Step Verification Protocol (mandatory after every prompt change)

# Step 1: Verify cap is in effect
touch /tmp/article-gen/BUDGET_STOP_FLAG
# → Run a force-run, must see "⏸️ Budget cap is on, skipping this publish"

# Step 2: Verify cap is lifted
rm /tmp/article-gen/BUDGET_STOP_FLAG
# → Run a force-run, must see normal execution (write file + run pipeline)

# Step 3: Verify cap status query
test -f /tmp/article-gen/BUDGET_STOP_FLAG && echo "⏸️" || echo "✅"
# → Must return the correct status immediately

Any step that fails to behave as expected means the prompt is broken — roll back to the previous version immediately.

Fix 4: Put Budget Cap on the First Line of the Prompt

# Wrong: budget cap at the end
prompt: |
  You are an AI assistant...

  [Task description]

  [tools list]

  # budget cap check ← Too late, tools init failure triggers fallback skip

# Correct: budget cap on the first line
prompt: |
  【Budget Cap Check (Human Semantics Version)】
  Step 1: Check whether the file /tmp/article-gen/BUDGET_STOP_FLAG exists
  ...

  You are an AI assistant...
  [Task description]
  [tools list]

Fix 5: v3 → v4 → v5 → v6 Complete Governance Loop

v6 is the most upstream fix in this chain — it guarantees that "should today's publish run at all" is 100% reliable. If v6 fails, all downstream v3-v5 fixes are useless.

🛡️ 8-Point Production Verification Checklist

Print these 8 points as a comment block at the top of each cron task's prompt header, and check every time you modify:

1. ☐ Budget cap check is on the first line of the prompt (not the end)

2. ☐ Use the human-semantics version (no ls ... 2>/dev/null / wc -c / if [ $? ])

3. ☐ Flag path is fixed at /tmp/article-gen/BUDGET_STOP_FLAG (no subdirectory abbreviation)

4. ☐ 3-step verification: touch → skip ✓ / rm → continue ✓ / test -f returns immediately ✓

5. ☐ AI does NOT proactively estimate token balance (only owner one-keystroke pause for budget judgment)

6. ☐ After prompt modification, immediately force-run verification (avoid 7/12-7/13's 2 days of 0 publishes)

7. ☐ Tools list placed after the budget cap (avoid tools init failure triggering fallback skip)

8. ☐ Permanent rule written to MEMORY.md "Permanent Standards" section (v6 promoted)

🔗 Related Internal Links (same governance loop)

• **v3 flock lock fix**: solves /tmp/article-gen/ multi-session overwrite
• **v4 metadata-driven fix**: solves flock side-effects (slug misalignment, EN duplicates, empty titles)
• **v5 generate-html.py is_en fix**: solves `is_en = basename.startswith('en')` misjudging `*-cn.txt` as CN
• **2026-07-04 budget cap implementation record** ("governance background" section in v3 article): specific data for the 7.31M token waste
• **MEMORY.md Permanent Standards section**: v6 promotion record

Summary and Next Steps

Budget cap (v6) + flock lock (v3) + metadata-driven (v4/v5) form the complete July 2026 governance loop for the OpenClaw AI automation pipeline. These 4 articles combined are all the lessons from being beaten by the same class of problems over the past 4 weeks:

• **v6** prevents "should it run today at all" from being misjudged by the LLM
• **v3** prevents "who touched my file while I was running"
• **v4** prevents "flock side-effects corrupted file metadata"
• **v5** prevents "language misjudgment during HTML rendering"

Next step: Watch whether any of these 8 v6 rules get violated in August. If v6 also fails, the problem is even further upstream — possibly the prompt's token budget itself is set wrong, or the owner triggered multiple touches and the AI doesn't know which file to look at. That'll require a v7 "prompt-external budget control" article.

👉 Join MiniMax Token Plan: AI coding acceleration for businesses

👉 Join Zhipu Coding Plan: GLM-4.6/GLM-5 coding packages, China-stable, pay-per-token unlimited

👉 Join Aliyun AI: Top AI products with exclusive coupons for business innovation

📌 This article was AI-assisted generated and human-reviewed | TechPassive — An AI-driven content testing site focused on real tool reviews