Skip to content

⚡ Claude Token Optimization2026-08-05 — Smoke Claude #6955

Description

@github-actions

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

  • Replace the 7-line explanatory HTML comment (lines 136–143) with a single-line <!-- run: ${{ github.run_id }} -->
  • Condense the bulleted instruction list (lines 149–152) into fewer, denser sentences
  • Change max-turns: 8 to max-turns: 2 in the frontmatter
  • Recompile: gh aw compile .github/workflows/smoke-claude.md
  • Post-process: npx tsx scripts/ci/postprocess-smoke-workflows.ts
  • Verify CI passes on PR (pull_request trigger path still calls add_comment + conditional add_labels)
  • Compare token usage on new run vs the ~3.5K/run baseline recorded here

Generated by Daily Claude Token Optimization Advisor · auto · 38.9 AIC · ⊞ 10.1K ·

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions