⚡ Claude Token Optimization2026-08-21 — Smoke Claude

[github-actions]

Target Workflow: Smoke Claude (.github/workflows/smoke-claude.md)

Source report: #7588
Estimated cost per run: N/A (estimated_cost null on all 8 runs)
Total tokens per run: ~4.6K (range 4,461–4,729 across 8 runs)
Cache read rate: N/A (token_usage_summary null on all runs)
Cache write rate: N/A (same — no per-model/cache breakdown reported)
LLM turns: N/A (turns null on all runs; target is 1 turn per the workflow's own post-steps check)

Current Configuration

Setting	Value
Tools loaded	1 (bash); github: false (GitHub MCP toolset fully disabled)
Tools actually used	Unknown — tool_usage/mcp_tool_usage are null for all 8 runs (instrumentation gap, not a workflow bug)
Network groups	None declared in frontmatter (no network.allowed block)
Pre-agent steps	Yes — 5 steps: (smoke file creation, PR pre-fetch via gh pr list, GitHub.com reachability check via curl, file verification, final-result computation) plus 2 post-steps
Prompt size	~700 characters (single short paragraph + explicit safe-output instructions)

Recommendations

This workflow is already near-optimal for token efficiency — it is the cheapest possible Claude-engine configuration in this repo (single bash tool, github: false, model: claude-haiku-4-5, all deterministic work pre-computed in steps:). The 4.6K tokens/run average is far below the 100K high-token-count threshold, so no tool-surface or prompt-trimming changes are recommended. The actionable gaps are all in instrumentation, not the workflow logic itself.

1. Wire up cost/turn/cache instrumentation so future reports are actionable

Estimated savings: N/A (observability fix, not a token reduction) — but this blocks any future data-driven optimization of this workflow

Every run in the 7-day window has estimated_cost, turns, error_count, warning_count, and token_usage_summary all null, even though token_usage itself is populated. This means the Anthropic-specific levers this advisor is designed to surface (cache read/write ratio, per-turn breakdown, input/output ratio) cannot be computed for this workflow at all. Root-cause and fix the missing fields in the run-log parser / artifact schema (scripts/ci/check-token-usage.js and whatever populates .github/aw/logs/run-*/) so subsequent claude-token-usage-analyzer runs emit real turns, estimated_cost, and token_usage_summary for the Claude engine. Without this, no cache-write-vs-read cost tradeoff analysis is possible for this workflow.

2. Confirm the pre-agent steps remain the sole source of GitHub API + network calls

Estimated savings: Already realized — confirms current design is correct, guards against regression

The workflow already moves all deterministic work (PR list fetch via gh pr list, GitHub.com reachability via curl, file creation/verification) into steps: before the agent runs, and the agent's only job is to cat one pre-computed JSON file and call a safe-output tool. This is the ideal pattern this advisor would otherwise recommend introducing. No changes needed here — call this out explicitly in review so it isn't regressed by future edits that might move logic back into the agent prompt.

3. Keep tools.github: false and single-tool bash surface as-is

Estimated savings: ~10-15K tokens/turn avoided (already realized, not a new saving)

Loading the default GitHub toolset (~22 tools) would cost roughly 10-15K tokens/turn in schema overhead. This workflow correctly disables it (github: false) since all GitHub reads/writes happen via pre-agent steps: (gh pr list) and safe-outputs (add_comment, add_labels), not agent-invoked GitHub tools. No action needed; flagging so this isn't inadvertently re-enabled during future maintenance.

4. Do not add a network.allowed restriction beyond what's needed

Estimated savings: N/A — no unused network groups configured

The frontmatter does not declare a network.allowed block, so there are no unused network groups (e.g. node, playwright) to trim. If network restriction is added later for firewall hardening, only github.com (used by the GitHub.com reachability pre-step and safe-outputs) needs to be allow-listed for the agent's own network access — but since the agent doesn't do direct HTTP calls (the curl reachability check runs in a pre-agent steps: block, outside the agent sandbox), no agent-side network allowlist changes are needed.

Cache Analysis (Anthropic-Specific)

Not possible for this workflow — token_usage_summary (which would contain per-model cache_read/cache_write breakdown) is null for all 8 runs in the observed window. See Recommendation #1: fixing the instrumentation gap is a prerequisite for any cache write/read cost-tradeoff analysis.

Cache write amortization: Unknown (no data)
Cache cost vs benefit: Unknown (no data)

Expected Impact

Metric	Current	Projected	Savings
Total tokens/run	~4.6K	~4.6K	0% (already optimal)
Cost/run	N/A	N/A	N/A (instrumentation gap)
LLM turns	Unknown (target 1 per workflow's own check)	Unknown	N/A
Session time	~4.3m avg (from 8-run sample)	~4.3m (est., no change)	0%

Implementation Checklist

• Fix run-log/artifact instrumentation so estimated_cost, turns, and token_usage_summary are populated for Claude-engine runs (likely in scripts/ci/check-token-usage.js or the log-parsing pipeline feeding claude-logs.json)
• Re-run claude-token-usage-analyzer after the fix and confirm cache read/write and turn-count fields are non-null for Smoke Claude
• No workflow .md changes recommended at this time — Smoke Claude is already using the minimal-tool, pre-agent-steps pattern this advisor promotes
• Recompile only if instrumentation fix requires workflow-level changes: gh aw compile .github/workflows/smoke-claude.md
• Post-process: npx tsx scripts/ci/postprocess-smoke-workflows.ts
• Verify CI passes on PR
• Compare token usage on new run vs baseline once instrumentation is fixed

Generated by Daily Claude Token Optimization Advisor · auto · 23.1 AIC · ⊞ 10.6K · ◷