You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
resource_heavy_for_domain (severity: high) — 47 turns for a local static-analysis task is excessive
partially_reducible (severity: low) — agentic_fraction=0.50 suggests ~50% of turns are data-gathering that could be deterministic
Ranked Recommendations
1. 🔴 Add a bash pre-step to collect all file metrics up front
Estimated savings: ~800K–1M tokens/run (40–50%)
The prompt instructs the agent to iterate file-by-file: run wc -l, grep -n, awk, and repeat for each changed file. With 47 turns at ~42K input tokens/turn (accumulated context), this is the dominant cost.
A single pre-step bash script can:
Identify all changed .go/.js/.cjs files in the last 24 hours
Run wc -l, grep -n "^func ", and export-count greps across all files at once
Run go list ./... 2>&1 | grep -i "import cycle" once
Write a structured JSON summary to /tmp/gh-aw/agent/arch-metrics.json
The agent then reads one file instead of running 20–30 individual shell commands, reducing turns from ~47 to ~15–20.
Concrete action: Add a steps: block in the workflow frontmatter with a bash pre-step that runs the full metric collection script.
Evidence: 47 turns, actuation_style=read_only, all outputs are analysis (no write actions), agentic_fraction=0.50.
The workflow is configured with github: toolsets: [repos]. The entire analysis is performed with local bash commands (git log, wc, grep, awk, go list). No GitHub API reads are needed for local static analysis. With mount-as-clis: true, the gh CLI is available if needed.
Removing the toolset eliminates the tool-definition tokens injected into every request.
Concrete action: Remove the github: block from the tools: section (or replace with toolsets: []).
Evidence: 3 github_api_calls recorded for the run — these are likely the safe-output create_issue call and repo metadata lookups, not repos-toolset calls. The prompt never references GitHub API operations for analysis.
The edit: tool is listed under tools:. The workflow's primary task (code analysis + issue creation) doesn't require editing files — only bash and safe-outputs are needed. edit is used only during workflow recompile (footer-workflow-recompile message), not in normal runs.
Concrete action: Remove edit: from the tools: section.
Evidence: No edit tool calls observed in run data. actuation_style=read_only.
4. 🟢 Simplify the per-violation AI suggestion step
Step 5 asks the agent to generate a "concise refactoring suggestion" for every BLOCKER and WARNING violation, including (1) what the violation is, (2) why it's a problem, and (3) a concrete plan. This produces verbose output and may require additional read turns to gather context for suggestions.
Concrete action: Replace per-violation narrative suggestions with a templated 2-line note: violation description + a single-sentence fix hint. Move the detailed architectural guidance to the issue body as boilerplate.
Evidence: 12,444 output tokens generated (vs typical ~5K for issue-creation workflows), 47 turns suggest multiple reasoning cycles per violation.
Only 1 run available in the 7-day window (scheduled daily, weekdays only). Recommendations are based on structural prompt analysis supplemented by the run fingerprint.
The ~800K token savings estimate for recommendation rejig docs #1 is conservative — actual savings depend on the number of changed files per run. Runs with few changes (triggering early noop) will save proportionally less.
Cache write tokens = 0 in this run, which means the KV cache wasn't populated. This may be normal for the first run of the day or after a workflow change.
Target Workflow
Architecture Guardian (
architecture-guardian.md) — selected as highest-token eligible workflow (1.97M tokens, not optimized in the last 14 days).Analysis Period
Token Profile
Agentic Assessments (from run classifier)
resource_heavy_for_domain(severity: high) — 47 turns for a local static-analysis task is excessivepartially_reducible(severity: low) —agentic_fraction=0.50suggests ~50% of turns are data-gathering that could be deterministicRanked Recommendations
1. 🔴 Add a bash pre-step to collect all file metrics up front
Estimated savings: ~800K–1M tokens/run (40–50%)
The prompt instructs the agent to iterate file-by-file: run
wc -l,grep -n,awk, and repeat for each changed file. With 47 turns at ~42K input tokens/turn (accumulated context), this is the dominant cost.A single pre-step bash script can:
.go/.js/.cjsfiles in the last 24 hourswc -l,grep -n "^func ", and export-count greps across all files at oncego list ./... 2>&1 | grep -i "import cycle"once/tmp/gh-aw/agent/arch-metrics.jsonThe agent then reads one file instead of running 20–30 individual shell commands, reducing turns from ~47 to ~15–20.
Concrete action: Add a
steps:block in the workflow frontmatter with a bash pre-step that runs the full metric collection script.Evidence: 47 turns, actuation_style=
read_only, all outputs are analysis (no write actions), agentic_fraction=0.50.2. 🟡 Remove the
reposGitHub toolsetEstimated savings: ~30K–50K tokens/run (reduced tool-list context)
The workflow is configured with
github: toolsets: [repos]. The entire analysis is performed with local bash commands (git log,wc,grep,awk,go list). No GitHub API reads are needed for local static analysis. Withmount-as-clis: true, theghCLI is available if needed.Removing the toolset eliminates the tool-definition tokens injected into every request.
Concrete action: Remove the
github:block from thetools:section (or replace withtoolsets: []).Evidence: 3
github_api_callsrecorded for the run — these are likely the safe-outputcreate_issuecall and repo metadata lookups, not repos-toolset calls. The prompt never references GitHub API operations for analysis.3. 🟡 Remove the
edittool from the tools listEstimated savings: ~10K–20K tokens/run (tool schema injection)
The
edit:tool is listed undertools:. The workflow's primary task (code analysis + issue creation) doesn't require editing files — only bash and safe-outputs are needed.editis used only during workflow recompile (footer-workflow-recompilemessage), not in normal runs.Concrete action: Remove
edit:from thetools:section.Evidence: No edit tool calls observed in run data.
actuation_style=read_only.4. 🟢 Simplify the per-violation AI suggestion step
Estimated savings: ~50K–100K tokens/run (reduced output + fewer turns)
Step 5 asks the agent to generate a "concise refactoring suggestion" for every BLOCKER and WARNING violation, including (1) what the violation is, (2) why it's a problem, and (3) a concrete plan. This produces verbose output and may require additional read turns to gather context for suggestions.
Concrete action: Replace per-violation narrative suggestions with a templated 2-line note: violation description + a single-sentence fix hint. Move the detailed architectural guidance to the issue body as boilerplate.
Evidence: 12,444 output tokens generated (vs typical ~5K for issue-creation workflows), 47 turns suggest multiple reasoning cycles per violation.
Supporting Data
Run token breakdown
Behavior fingerprint
Configured tools
github: toolsets: [repos]bash: git log/diff/show, find, wc, grep, cat, head, awk, sed, sortedit:safe-outputs: create-issue, noopCaveats
References: