OpenClaw Scheduler Token Auditor

Audit scheduler token usage conservatively. Separate what is measured, what is only bounded, and what remains unknown.

What this skill is for

Use this skill to answer questions like:

• - Which cron job is burning the most tokens?
• Did this scheduled task exceed 50000 tokens per run?
• Is heartbeat usage actually expensive, or does it only look scary?
• Why did scheduler token usage spike?
• Audit all scheduled tasks against a custom threshold such as 80000 or 120000 tokens.

How users typically trigger it

This skill should trigger for requests such as:

• - INLINECODE0
• INLINECODE1
• INLINECODE2
• INLINECODE3
• INLINECODE4
• INLINECODE5
• INLINECODE6
• INLINECODE7

If the user gives no threshold, use 50000 tokens per run.

Core rule set

1. 1. For cron runs, only usage.total_tokens is authoritative.

Do not replace it with hand-summed input + output values.

1. 2. Session status, session lists, and transcripts are supporting evidence.

Use them to explain a result, not to manufacture one.

1. 3. Missing usage means unknown.

If a run lacks usage.total_tokens, do not call it cheap or safe.

1. 4. Heartbeat analysis is usually bounded, not exact.

Without explicit usage fields, you may rule out obviously huge per-run usage, but you may not claim an exact token count.

1. 5. State the threshold explicitly.

Default to 50000 unless the user specifies another threshold.

1. 6. Do not invent commands or undocumented fields.

Prefer first-class OpenClaw tools.

Evidence classes

Use exactly one label per audited target:

• - Exact — authoritative token count exists, usually from INLINECODE11
• Bounded — no exact count, but current evidence safely rules out obvious extreme usage
• Inconclusive — required evidence is missing, so no safe token claim can be made

Audit workflow

1) Classify the target

Separate the audit by evidence type:

• - Cron jobs
• Heartbeat sessions

Do not blur them into one vague conclusion.

2) Audit cron jobs

Preferred path:

• - INLINECODE12
• INLINECODE13

Procedure:

1. 1. Identify the relevant cron job or jobs.
2. Fetch recent run records.
3. Read usage.total_tokens from each run.
4. Compare each exact count to the active threshold.
5. Only after that, inspect session metadata or transcripts to explain why a verified expensive run happened.

CLI fallback only if needed:

CODEBLOCK0

Interpretation:

• - Has usage.total_tokens -> Exact
• Missing usage.total_tokens -> Inconclusive
• Never substitute transcript size or INLINECODE17

3) Explain expensive cron runs

Once a run is already verified as expensive, look for causes such as:

• - oversized prompts or task scope
• repeated large file reads, web fetches, or tool outputs
• session reuse that drags in extra context
• retries, loops, or obvious workflow mistakes

These are explanations for an exact finding, not substitutes for exact usage.

4) Audit heartbeat sessions

Treat heartbeat as bounded-risk analysis unless explicit usage data exists.

Useful checks:

• - sessions_list to find heartbeat sessions
• INLINECODE19 to inspect context accumulation
• INLINECODE20 to inspect recent transcript size, repetition, and tool fan-out

A Bounded conclusion is reasonable when the observed pattern shows:

• - little or no context accumulation
• short repetitive turns
• small reads and short outputs
• no evidence of large injected context or wide fan-out

Without explicit usage, phrase conclusions like:

• - INLINECODE21
• INLINECODE22
• INLINECODE23

Decision rules

Cron with usage.total_tokens

Allowed:

• - exact per-run token counts
• threshold pass/fail verdicts
• comparisons across runs
• trend summaries grounded in run records

Not allowed:

• - replacing the total with hand-summed fields
• estimating totals from transcript size

Cron without usage.total_tokens

Allowed:

• - INLINECODE26
• structural observations that help future debugging

Not allowed:

• - claiming the run is cheap, safe, or below threshold
• assigning a token number from side evidence

Heartbeat without explicit usage

Allowed:

• - bounded statements such as INLINECODE27
• structural explanations for that bounded conclusion

Not allowed:

• - exact per-run token counts
• exact cumulative totals inferred from transcripts alone

Output pattern

Always state the threshold used.

Examples:

• - INLINECODE28
• INLINECODE29

For each target, report:

• - target name
• target type: cron or INLINECODE31
• evidence class: Exact, Bounded, or INLINECODE34
• token finding
• threshold verdict: pass, fail, or unknown
• concise cause analysis when evidence supports it

Example phrasings:

• - Exact — INLINECODE35
• Bounded — INLINECODE36
• Inconclusive — INLINECODE37

Failure modes to avoid

1. 1. Hand-sum trap — input + output may disagree with INLINECODE39
2. Missing-data optimism — missing usage is not low usage
3. Transcript-as-meter trap — transcript size is not a billing source
4. Heartbeat overclaim — lightweight structure supports bounded conclusions, not exact counts
5. Mixed-evidence blur — do not merge Exact cron findings and Bounded heartbeat findings into one vague claim
6. Invented-command trap — if CLI syntax is uncertain, check docs or openclaw help first
7. Threshold drift — always say whether the threshold was default or user-specified

Minimal examples

Exact cron result

A run record contains usage.total_tokens: 158784, and the user gave no threshold.

Correct conclusion:

• - threshold used: INLINECODE42
• evidence class: INLINECODE43
• verdict: INLINECODE44

Custom threshold

A run record contains usage.total_tokens: 47617, and the user asks for 80000.

Correct conclusion:

• - threshold used: INLINECODE47
• evidence class: INLINECODE48
• verdict: INLINECODE49

Misleading hand-sum

A run shows input_tokens: 49680 and output_tokens: 9612, while the authoritative record says usage.total_tokens: 47617.

Correct conclusion:

• - use INLINECODE53
• do not report INLINECODE54

Bounded heartbeat result

A heartbeat session shows near-zero context accumulation and a repeating pattern of small checklist reads plus short acknowledgements.

Correct conclusion:

• - evidence class: INLINECODE55
• INLINECODE56
• INLINECODE57

Missing usage

A cron run exists but the record has no usage.total_tokens.

Correct conclusion:

• - evidence class: INLINECODE59
• verdict: INLINECODE60
• next step: investigate provider support, run logging, or other authoritative records