π― Target Workflow
Daily Agentic Workflow Token Usage Audit (workflows/agentic-token-audit.md)
Selected because it runs 10+ times per week (weekdays + manual triggers), making it the highest-frequency agentic workflow not excluded by name rules. All prior optimization-log entries for this workflow were produced under zero-run-data conditions; this analysis is the first based on direct prompt structure inspection and live run timing data.
Note: The last optimization-log entry for this workflow is dated 2026-05-20 (2 days ago), which is within the standard 14-day window. However, because the available token telemetry (all-runs.json, daily snapshots) contained no run data throughout the audit period, all prior entries in the optimization log were effectively placeholder analyses. This fresh structural audit is therefore non-redundant.
π Token Profile
| Metric |
Value |
| Analysis period |
2026-05-15 β 2026-05-22 (7 days) |
| Runs audited |
10 |
| Avg run duration (agent job only) |
~3 min |
| Avg total run duration |
~5.1 min |
| All conclusions |
β
success (10/10) |
| Token telemetry |
Not available (empty in all-runs.json) |
| Prompt size |
~11,700 chars (~2,900 tokens) |
Token telemetry is absent from the pre-aggregated data files. Run-duration data and prompt structure analysis are the primary evidence base for the recommendations below.
References:
π Ranked Recommendations
1. Extract Phase 3 (Chart Generation) as an Inline Sub-Agent
Estimated savings: ~600 tokens/run
Phase 3 asks the main agent to: write a matplotlib/seaborn Python script, set PYTHONPATH, run it, interpret the output, handle errors, upload assets, and capture the returned URLs β all inline in the main context window. This is fully independent of Phase 4 (issue publishing), needs only the two already-computed JSON files as inputs, and is pure extractive/formatting work.
Sub-agent score breakdown:
| Dimension |
Score |
Rationale |
| Independence |
3/3 |
Depends only on Phase 1 output (audit_snapshot.json); no dependency on Phase 4 |
| Small-model adequacy |
3/3 |
Writes deterministic data-vis code from structured JSON; no strategic reasoning needed |
| Parallelism |
2/2 |
Can run concurrently with Phase 2 (repo-memory persistence) |
| Size |
2/2 |
Substantial enough (package import, 2 charts, asset upload) to justify agent overhead |
| Total |
10/10 |
Strong candidate |
Proposed change: Replace the Phase 3 prose with an inline ## agent: block that receives the chart data paths, generates both PNGs, uploads them, and returns the two asset URLs. The main agent then embeds those URLs in the Phase 4 issue template.
## agent: generate-charts
Model: small
Input files: /tmp/gh-aw/token-audit/audit_snapshot.json, /tmp/gh-aw/repo-memory/default/rolling-summary.json
Output: Upload token_by_workflow.png and token_trend.png; return asset URLs.
Generate two matplotlib/seaborn (whitegrid, 300 DPI, white bg) charts:
1. Horizontal bar chart of top 15 workflows by total_tokens from audit_snapshot.json.
2. Line chart of total_tokens over time from rolling-summary.json (skip if < 2 points).
Set PYTHONPATH=/tmp/gh-aw/token-audit/site-packages. Upload each PNG via upload_asset.
Return the two URLs.
2. Compress the RunData Schema Table in ## Data Sources
Estimated savings: ~400 tokens/run
The current prompt includes a full 15-row Markdown table documenting the RunData JSON schema. This is reference documentation that the agent must process on every run, even though jq expressions in the workflow body already demonstrate the correct field paths.
Action: Replace the table with a 3-line compact reference that lists only the fields actually needed for aggregation:
Key fields: workflow_name, workflow_path, token_usage (int, omitemptyβ0),
effective_tokens, estimated_cost (float, omitemptyβ0), action_minutes,
turns, conclusion, status, error_count, warning_count, url.
This retains enough for the agent to write correct jq/Python without the full table.
3. Consolidate the PYTHONPATH Setup Instruction
Estimated savings: ~200 tokens/run
The Phase 3 section includes a multi-line parenthetical block explaining the PYTHONPATH requirement and showing the full prefix literal twice. The same information appears in the pre-step comments.
Action: Add a single top-level ## Environment or ## Setup note early in the prompt:
PYTHONPATH must be set for all Python calls:
export PYTHONPATH=/tmp/gh-aw/token-audit/site-packages${PYTHONPATH:+:$PYTHONPATH}
Run this once before executing any Python scripts.
Remove the repeated inline PYTHONPATH blocks from Phase 1 and Phase 3.
4. Compress the Phase 4 Report Template
Estimated savings: ~300 tokens/run
The Phase 4 section includes a verbatim 40-line Markdown template (with fenced code block) plus formatting requirements. The template includes placeholder literals (UPLOAD_URL_WORKFLOW_PLACEHOLDER, YYYY-MM-DD, etc.) that the agent must substitute β which requires it to re-read and reproduce the template structure in its output.
Action: Replace the template with a compact 8-line schema:
Issue sections (use ### headers):
1. π Executive Summary β period, total runs, tokens (comma-formatted), cost, action-minutes, active workflows.
2. π Top 5 Workflows by Token β table: Workflow | Runs | Total Tokens | Avg Tokens | Total Cost | Avg Cost.
3. π Trends β embed chart images (skip placeholder if upload missing); summarize rolling trend.
4. Per-Workflow Breakdown β full table in <details>.
5. π‘ Observations β flag >30% concentration, high error ratios, avg > 100k tokens.
Footer: Data snapshot: `memory/token-audit/YYYY-MM-DD.json`.
5. Trim the OTEL Experiment Section
Estimated savings: ~150 tokens/run
The ## Experiment OTEL Span Attributes section is 20 lines of inline JavaScript boilerplate that runs only when /tmp/gh-aw/experiments/assignments.json exists. When experiments are inactive the agent still processes this instruction block.
Action: Move the OTEL logic entirely into a workflow steps: pre-run script (not the agent prompt), so the agent never sees this instruction. If the step produces output, pass it as environment context rather than agent instruction.
π§ Structural Optimization
Inline Sub-Agent: Chart Generation (Phase 3)
As detailed in Recommendation #1 above, Phase 3 is the clearest sub-agent candidate in this workflow. The change requires:
- Adding an
## agent: generate-charts block after Phase 2 in the prompt.
- Removing the inline chart-generation prose from Phase 3.
- Updating the Phase 4 template instruction to use
{{generate-charts.output.url_workflow}} and {{generate-charts.output.url_trend}} (or equivalent binding syntax).
No other sections scored β₯ 6 on the sub-agent matrix: Phase 1 (Python data processing) requires access to raw log files and produces the intermediate JSON that all subsequent phases depend on; Phase 4 (issue publishing) requires cross-phase synthesis and is the final authoritative output.
π Caveats
- Token telemetry (
token_usage, estimated_cost, turns) is unavailable in pre-aggregated data files for this analysis window; all savings estimates are based on prompt character counts and run timing rather than measured token deltas.
- Savings estimates assume a tokenizer ratio of ~4 chars/token. Actual savings will vary with model and sampling.
- The sub-agent recommendation depends on the inline-agent feature being available in this workflow runner version.
- All 10 audited runs concluded successfully; no error-related token waste was observed.
Total estimated savings: ~1,650 tokens/run (~16,500 tokens/week)
Generated by Agentic Workflow Token Usage Optimizer Β· β 7.5M Β· β·
π― Target Workflow
Daily Agentic Workflow Token Usage Audit (
workflows/agentic-token-audit.md)Selected because it runs 10+ times per week (weekdays + manual triggers), making it the highest-frequency agentic workflow not excluded by name rules. All prior optimization-log entries for this workflow were produced under zero-run-data conditions; this analysis is the first based on direct prompt structure inspection and live run timing data.
π Token Profile
Token telemetry is absent from the pre-aggregated data files. Run-duration data and prompt structure analysis are the primary evidence base for the recommendations below.
References:
π Ranked Recommendations
1. Extract Phase 3 (Chart Generation) as an Inline Sub-Agent
Estimated savings: ~600 tokens/run
Phase 3 asks the main agent to: write a
matplotlib/seabornPython script, set PYTHONPATH, run it, interpret the output, handle errors, upload assets, and capture the returned URLs β all inline in the main context window. This is fully independent of Phase 4 (issue publishing), needs only the two already-computed JSON files as inputs, and is pure extractive/formatting work.Sub-agent score breakdown:
audit_snapshot.json); no dependency on Phase 4Proposed change: Replace the Phase 3 prose with an inline
## agent:block that receives the chart data paths, generates both PNGs, uploads them, and returns the two asset URLs. The main agent then embeds those URLs in the Phase 4 issue template.2. Compress the RunData Schema Table in
## Data SourcesEstimated savings: ~400 tokens/run
The current prompt includes a full 15-row Markdown table documenting the RunData JSON schema. This is reference documentation that the agent must process on every run, even though
jqexpressions in the workflow body already demonstrate the correct field paths.Action: Replace the table with a 3-line compact reference that lists only the fields actually needed for aggregation:
This retains enough for the agent to write correct
jq/Python without the full table.3. Consolidate the PYTHONPATH Setup Instruction
Estimated savings: ~200 tokens/run
The Phase 3 section includes a multi-line parenthetical block explaining the PYTHONPATH requirement and showing the full prefix literal twice. The same information appears in the pre-step comments.
Action: Add a single top-level
## Environmentor## Setupnote early in the prompt:Remove the repeated inline PYTHONPATH blocks from Phase 1 and Phase 3.
4. Compress the Phase 4 Report Template
Estimated savings: ~300 tokens/run
The Phase 4 section includes a verbatim 40-line Markdown template (with fenced code block) plus formatting requirements. The template includes placeholder literals (
UPLOAD_URL_WORKFLOW_PLACEHOLDER,YYYY-MM-DD, etc.) that the agent must substitute β which requires it to re-read and reproduce the template structure in its output.Action: Replace the template with a compact 8-line schema:
5. Trim the OTEL Experiment Section
Estimated savings: ~150 tokens/run
The
## Experiment OTEL Span Attributessection is 20 lines of inline JavaScript boilerplate that runs only when/tmp/gh-aw/experiments/assignments.jsonexists. When experiments are inactive the agent still processes this instruction block.Action: Move the OTEL logic entirely into a workflow
steps:pre-run script (not the agent prompt), so the agent never sees this instruction. If the step produces output, pass it as environment context rather than agent instruction.π§ Structural Optimization
Inline Sub-Agent: Chart Generation (Phase 3)
As detailed in Recommendation #1 above, Phase 3 is the clearest sub-agent candidate in this workflow. The change requires:
## agent: generate-chartsblock after Phase 2 in the prompt.{{generate-charts.output.url_workflow}}and{{generate-charts.output.url_trend}}(or equivalent binding syntax).No other sections scored β₯ 6 on the sub-agent matrix: Phase 1 (Python data processing) requires access to raw log files and produces the intermediate JSON that all subsequent phases depend on; Phase 4 (issue publishing) requires cross-phase synthesis and is the final authoritative output.
π Caveats
token_usage,estimated_cost,turns) is unavailable in pre-aggregated data files for this analysis window; all savings estimates are based on prompt character counts and run timing rather than measured token deltas.Total estimated savings: ~1,650 tokens/run (~16,500 tokens/week)