⚡ Claude Token Optimization2026-09-21 — smoke-claude

Start in .github/workflows/smoke-claude.md and compare its current tools, max-turns, prompts, and triggers with the recommendations in this issue. Recompile with gh aw compile .github/workflows/smoke-claude.md, then run npx tsx scripts/ci/postprocess-smoke-workflows.ts and verify CI. Done means the intended settings are applied and new runs approach the target turn count without regressions.

Target Workflow: smoke-claude.md

Source report: #8828 (report body not directly readable to this agent due to integrity policy — analysis below uses the pre-downloaded run data at /tmp/gh-aw/token-audit/claude-logs.json, 6 runs, last ~36h)
Estimated tokens per run: ~5.1K (range 4,935–5,252)
Turns (target vs actual): target 1 turn (per workflow's own post-steps notice: "target: 1") vs actual avg 5.66 invocations (range 5–6)
Rebuild factor: ~1.002 (near-ideal, negligible context-rebuild waste)
Model: claude-haiku-4-5 (already the cheapest Claude tier)
AIC (aggregate instance cost metric): avg ~50.1/run, total 300.6 across 6 runs
Action minutes: avg 4.7 min/run (28 total)

Current Configuration

This workflow is already well-optimized structurally: no GitHub MCP toolset loaded (github: false), all deterministic work (API calls, curl checks, file writes) is pre-computed in steps: before the agent runs, and the prompt is a short "read one JSON file, call one safe output" instruction. The main inefficiency is turn count exceeding the workflow's own design target, not tool/prompt bloat.

Recommendations

1. Close the turn-count gap (1 target vs 5.66 actual)

Estimated savings: ~40–60% of tokens/run (~2–3K tokens), since cumulative_input_tokens (avg 4,575) grows with each additional turn's re-sent context

The workflow's own post-steps step (Report turn usage) states target: 1 turn, but actual runs average 5.66 invocations — a ~5-6x overshoot. With bash: unrestricted and a single cat + safe-output call as the only required actions, this should be achievable in 2 turns (read file → call tool), not 5-6.

Implementation:

• Restrict the bash: tool to only the command actually needed:

  tools:
    bash:
      - "cat /tmp/gh-aw/agent/final-result.json"
    github: false
  

  Restricting to an explicit allowed-command pattern (rather than a bare bash allow-all) reduces the chance the agent explores/re-reads/retries with extra bash invocations, each of which adds a turn and re-sends the growing transcript.
• Tighten the prompt's closing instruction to be more directive about turn budget, e.g. add: "Complete this in at most 2 tool calls total: one to read the file, one to call the required safe output. Do not re-read the file or make exploratory calls."
• Re-verify against the TURN_COUNT notice after the change; if turns don't drop, the excess is likely coming from the safe-output schema-probe warning already called out in the prompt ("Never call add_comment... as a schema probe") — indicating this has been a recurring problem needing a firmer guardrail (e.g., a single combined instruction listing exact JSON args to use, removing ambiguity).

2. Lower max-turns from 8 to 4 as a cost guard

Estimated savings: caps worst-case token spend at 50% of current ceiling; prevents any single run from silently consuming 8 turns' worth of growing context

Since actual average (5.66) already approaches half the current ceiling (8), and the target is 1 turn, an 8-turn ceiling is far too generous and allows a misbehaving run to burn significant tokens before failing. Tightening to max-turns: 4 still gives 2x headroom over the design target while capping runaway-cost scenarios.

max-turns: 4

3. Re-evaluate trigger frequency (biggest lever for aggregate cost)

Estimated savings: proportional to trigger reduction — cutting run frequency in half cuts aggregate token spend in half, independent of any per-run optimization

Per-run cost here is already tiny (~5.1K tokens, sub-cent at Haiku pricing). This workflow's total token footprint is dominated by how often it runs, not per-run inefficiency:

• schedule: every 12h → 2 runs/day unconditionally
• label_command: ready-for-aw on every pull_request labeled ready-for-aw → observed 4 of the last 6 runs were pull_request-triggered within an 18h window

If the schedule trigger and the label-command trigger are both meant to catch "Claude engine is broken," they're largely redundant — a broken engine would show up on either. Consider:

• Dropping the schedule: every 12h trigger to every 24h (halves scheduled runs), relying on the much more frequent pull_request label trigger for day-to-day coverage, or
• Confirming with the team whether both triggers are still needed for the smoke-test's coverage goals.

4. Restrict bash: allowed-list instead of full unrestricted access

Estimated savings: minor direct token savings, but reduces likelihood of exploratory extra turns (compounds with Recommendation 1)

Currently tools.bash has no allowed-command restriction, meaning the agent has full shell access even though the prompt only ever needs cat on one known file. Locking this down (see snippet in Recommendation 1) is a defense-in-depth improvement and nudges the agent toward the minimal-turn path.

Cache Analysis (Anthropic-Specific)

Data gap: The token-usage report format available at /tmp/gh-aw/token-audit/claude-logs.json for this workflow's runs exposes only aggregate token_usage and a working_set block (cumulative_input_tokens, peak_input_tokens, rebuild_factor, invocations) — it does not break out per-turn input/output/cache-read/cache-write token counts. A true cache-write-vs-read cost analysis (Sonnet cache write $3.75/M vs read $0.30/M) cannot be computed from this data without per-turn detail.

What the available data does show:

• rebuild_factor ≈ 1.002 across all runs — extremely low context-rebuild overhead, meaning prompt caching (to the extent it's used) is not being defeated by unstable/reordered context.
• peak_input_tokens (avg 4,566) is nearly identical to cumulative_input_tokens (avg 4,575) — most of the token cost is concentrated in the final turn's full context, consistent with a short, mostly-static prompt that just accumulates a few small tool-call turns on top.

Recommendation: Enable/verify per-turn token breakdown (input, output, cache_read, cache_write) in the Claude token-usage collector so future optimization passes on this and other Claude workflows can quantify actual cache-write amortization instead of relying on aggregate proxies.

Expected Impact

Implementation Checklist

• Restrict tools.bash to the single required command instead of unrestricted allow-all
• Tighten closing prompt instructions to explicitly cap tool calls at 2 and forbid exploratory/retry calls
• Lower max-turns from 8 to 4
• Discuss with workflow owner whether schedule: every 12h can be reduced to every 24h given redundant pull_request label trigger coverage
• Recompile: gh aw compile .github/workflows/smoke-claude.md
• Post-process: npx tsx scripts/ci/postprocess-smoke-workflows.ts
• Verify CI passes on PR
• Compare turn count and token usage on new runs vs this baseline (target: turns should approach the workflow's own stated "target: 1")

Generated by Daily Claude Token Optimization Advisor · copilot · auto · 50.7 AIC · ⊞ 10.4K · ◷