Target Workflow: Smoke Claude
Source report: #6954 (body not readable in this session due to integrity policy — recommendations below are derived directly from /tmp/gh-aw/token-audit/claude-logs.json and the staged workflow source)
Estimated cost per run: ~$0.006 (Claude Haiku 4.5 pricing, ~3.5K tokens/run)
Total tokens per run: ~3.5K avg (range 472–4,450 across 12 runs in the last 7 days)
Cache read/write rate: not exposed in the current log export (no cache_read/cache_write fields present in claude-logs.json)
LLM turns: target is 1 turn (workflow explicitly reports GH_AW_TURN_COUNT, target: 1); max-turns: 8 configured as a ceiling
Current Configuration
| Setting |
Value |
| Tools loaded |
1 (bash) — github: false |
| Tools actually used |
bash only (used implicitly by pre/post steps, not the agent turn itself) |
| Network groups |
none configured under network: (defaults apply) |
| Pre-agent steps |
Yes — 5 steps: blocks pre-compute PR list, GitHub reachability check, and a final-result.json before the agent runs |
| Prompt size |
~1.1K chars (lines 134–153 of the workflow body) |
Analysis
This workflow is already close to optimal for a single-turn smoke test: tools.github: false avoids loading the ~22-tool GitHub MCP toolset (saving an estimated 10–15K tokens/turn that a default github: block would add), and all deterministic work (PR fetch, curl reachability check, JSON assembly) happens in pre-agent steps:, not inside the LLM turn. The agent's job is reduced to "read one JSON file and call one safe-output." Token usage of ~3.5–4.1K/run on pull_request events is consistent with a single Haiku turn plus tool-call overhead; the two outlier runs (472 and 533 tokens) suggest the agent occasionally exits after a trivial noop without the full read+comment flow (e.g., non-PR schedule runs), which is expected behavior, not a defect.
Because this workflow is already minimized, the remaining opportunities are marginal. They are listed below in descending order of expected impact.
Recommendations
1. Trim the prompt's explanatory HTML comment
Estimated savings: ~150–250 tokens/run (~5-7% of total)
Lines 136–143 contain a 7-line HTML comment explaining why ${{ github.run_id }} must remain in the prompt (a gh-aw templating quirk). This comment is read by the LLM on every turn even though it's developer-facing metadata, not agent instructions. Move this explanation to a code comment in the workflow's YAML frontmatter (which is stripped before the prompt is rendered) or to a NOTES.md alongside the workflow, and replace the in-prompt block with the single load-bearing line:
<!-- run: ${{ github.run_id }} -->
This preserves the GitHub Actions expression (required so gh-aw emits the interpolation step) while cutting the explanatory prose from the token stream.
2. Collapse the numbered instruction list into fewer, denser sentences
Estimated savings: ~50–100 tokens/run (~2%)
Lines 145–154 use a bulleted list with repeated phrasing ("call add_comment", "call add_labels", "call noop"). Since max-turns: 8 is far above the 1-turn target and the task is fully deterministic given final-result.json, a single compact instruction ("If event=="pull_request": add_comment(pr_number, checks+result) then add_labels(["smoke-claude"]) iff result==PASS; else noop(result).") communicates the same branching logic in fewer tokens without changing behavior.
3. Lower max-turns from 8 to 2
Estimated savings: No direct token savings, but bounds worst-case cost/turns if the agent misbehaves
The workflow's own post-step explicitly targets 1 turn (Report turn usage step logs GH_AW_TURN_COUNT against a target of 1). Allowing up to 8 turns means a malformed response or retry loop could inflate a single run to several times its expected token cost with no workflow-level guard. Setting max-turns: 2 keeps a small safety margin for one retry while capping worst-case token blowup at ~2x instead of ~8x.
4. Confirm cache instrumentation for future audits
Estimated savings: N/A (diagnostic improvement only)
claude-logs.json does not currently expose cache_read_tokens/cache_write_tokens for Anthropic runs, so this issue cannot quantify cache hit/write rates or Anthropic-specific cache-cost tradeoffs as the audit template requests. If the log-download step in the token-usage-analyzer workflow can extract these fields from the Claude Code JSONL trace (they are present in the raw usage block of Anthropic API responses), future optimization issues for this and other Claude-engine workflows will be able to make prefix-caching recommendations with real data instead of noting the gap.
Cache Analysis (Anthropic-Specific)
Not available — the pre-downloaded claude-logs.json for this workflow's 12 runs in the last 7 days contains token_usage and aic (estimated cost) but no per-turn cache read/write breakdown. See Recommendation 4.
Expected Impact
| Metric |
Current |
Projected |
Savings |
| Total tokens/run |
~3.5K avg (4.1K on PR runs) |
~3.3–3.4K on PR runs |
~5-8% |
| Cost/run |
~$0.006 |
~$0.0056 |
~5-8% |
| LLM turns |
1 (target), 8 (ceiling) |
1 (target), 2 (ceiling) |
ceiling -6 |
| Session time |
2.5–3.9m |
~same (steps dominate duration, not the LLM turn) |
~0% |
Implementation Checklist
Generated by Daily Claude Token Optimization Advisor · auto · 38.9 AIC · ⊞ 10.1K · ◷
Target Workflow:
Smoke ClaudeSource report: #6954 (body not readable in this session due to integrity policy — recommendations below are derived directly from
/tmp/gh-aw/token-audit/claude-logs.jsonand the staged workflow source)Estimated cost per run: ~$0.006 (Claude Haiku 4.5 pricing, ~3.5K tokens/run)
Total tokens per run: ~3.5K avg (range 472–4,450 across 12 runs in the last 7 days)
Cache read/write rate: not exposed in the current log export (no
cache_read/cache_writefields present inclaude-logs.json)LLM turns: target is 1 turn (workflow explicitly reports
GH_AW_TURN_COUNT, target: 1);max-turns: 8configured as a ceilingCurrent Configuration
bash) —github: falsebashonly (used implicitly by pre/post steps, not the agent turn itself)network:(defaults apply)steps:blocks pre-compute PR list, GitHub reachability check, and afinal-result.jsonbefore the agent runsAnalysis
This workflow is already close to optimal for a single-turn smoke test:
tools.github: falseavoids loading the ~22-tool GitHub MCP toolset (saving an estimated 10–15K tokens/turn that a defaultgithub:block would add), and all deterministic work (PR fetch,curlreachability check, JSON assembly) happens in pre-agentsteps:, not inside the LLM turn. The agent's job is reduced to "read one JSON file and call one safe-output." Token usage of ~3.5–4.1K/run onpull_requestevents is consistent with a single Haiku turn plus tool-call overhead; the two outlier runs (472 and 533 tokens) suggest the agent occasionally exits after a trivialnoopwithout the full read+comment flow (e.g., non-PR schedule runs), which is expected behavior, not a defect.Because this workflow is already minimized, the remaining opportunities are marginal. They are listed below in descending order of expected impact.
Recommendations
1. Trim the prompt's explanatory HTML comment
Estimated savings: ~150–250 tokens/run (~5-7% of total)
Lines 136–143 contain a 7-line HTML comment explaining why
${{ github.run_id }}must remain in the prompt (a gh-aw templating quirk). This comment is read by the LLM on every turn even though it's developer-facing metadata, not agent instructions. Move this explanation to a code comment in the workflow's YAML frontmatter (which is stripped before the prompt is rendered) or to aNOTES.mdalongside the workflow, and replace the in-prompt block with the single load-bearing line:<!-- run: ${{ github.run_id }} -->This preserves the GitHub Actions expression (required so gh-aw emits the interpolation step) while cutting the explanatory prose from the token stream.
2. Collapse the numbered instruction list into fewer, denser sentences
Estimated savings: ~50–100 tokens/run (~2%)
Lines 145–154 use a bulleted list with repeated phrasing ("call
add_comment", "calladd_labels", "callnoop"). Sincemax-turns: 8is far above the 1-turn target and the task is fully deterministic givenfinal-result.json, a single compact instruction ("Ifevent=="pull_request": add_comment(pr_number, checks+result) then add_labels(["smoke-claude"]) iff result==PASS; else noop(result).") communicates the same branching logic in fewer tokens without changing behavior.3. Lower
max-turnsfrom 8 to 2Estimated savings: No direct token savings, but bounds worst-case cost/turns if the agent misbehaves
The workflow's own post-step explicitly targets 1 turn (
Report turn usagestep logsGH_AW_TURN_COUNTagainst a target of 1). Allowing up to 8 turns means a malformed response or retry loop could inflate a single run to several times its expected token cost with no workflow-level guard. Settingmax-turns: 2keeps a small safety margin for one retry while capping worst-case token blowup at ~2x instead of ~8x.4. Confirm cache instrumentation for future audits
Estimated savings: N/A (diagnostic improvement only)
claude-logs.jsondoes not currently exposecache_read_tokens/cache_write_tokensfor Anthropic runs, so this issue cannot quantify cache hit/write rates or Anthropic-specific cache-cost tradeoffs as the audit template requests. If the log-download step in the token-usage-analyzer workflow can extract these fields from the Claude Code JSONL trace (they are present in the rawusageblock of Anthropic API responses), future optimization issues for this and other Claude-engine workflows will be able to make prefix-caching recommendations with real data instead of noting the gap.Cache Analysis (Anthropic-Specific)
Not available — the pre-downloaded
claude-logs.jsonfor this workflow's 12 runs in the last 7 days containstoken_usageandaic(estimated cost) but no per-turn cache read/write breakdown. See Recommendation 4.Expected Impact
Implementation Checklist
<!-- run: ${{ github.run_id }} -->max-turns: 8tomax-turns: 2in the frontmattergh aw compile .github/workflows/smoke-claude.mdnpx tsx scripts/ci/postprocess-smoke-workflows.tspull_requesttrigger path still callsadd_comment+ conditionaladd_labels)