Target Workflow
File: .github/workflows/agentic-token-optimizer.md
Engine: copilot
7-day token usage: ~18,370,423 tokens across 3 runs (~6,123,474 avg/run)
Why This Workflow
agentic-token-optimizer is the highest-token workflow in the 7-day window by a wide margin — nearly 2× its nearest neighbour — and its 10 distinct prompt phases provide ample surface for optimization. Two phases (Phase 1 and Phase 3) are purely extractive/classificatory and well within a smaller model's capability, and two sections repeat the same REPO setup and gh api file-read pattern. Eliminating that redundancy and delegating the extractive phases to a small model can meaningfully reduce the main-model context loaded per run.
Optimization 1 — Common Tool Prefix (Highest Priority)
Repeated Tool Calls Found
The following tool invocations appear at the start of 2 sections:
REPO="${{ github.repository }}"
gh api "repos/$REPO/contents/$WF_PATH" --jq '.content' | base64 -d
Sections affected: ## Data Access Guidelines, ## Phase 3 — Read Workflow Source
Proposed Setup Step
Add a ## Setup section at the top of the prompt body that runs these calls once:
## Setup
Set the repository variable before any phase begins:
```bash
REPO="${{ github.repository }}"
All subsequent gh api calls must reuse $REPO and apply --jq or | jq to
extract only the fields needed. Never load full unfiltered API responses into context.
Then remove the duplicate `REPO=` assignment and duplicate `gh api ... | base64 -d` example from both affected sections.
**Estimated savings**: ~300,000 tokens/run (~5% reduction)
---
## Optimization 2 — Inline Sub-Agents
### LLM Expert Reasoning
- **Phase 1** scored 7/10 (strong): it reads static JSON files and applies filter/sort/aggregate logic — a classic extraction task that requires no cross-phase synthesis and runs with data already on disk.
- **Phase 3** scored 7/10 (strong): it is fully self-contained — given a workflow name, fetch and slice the `.md` source via `gh api`; no prior phase output is needed and it can run concurrently with Phase 2.
- Both phases qualify on the **extractive** heuristic: read structured input → return structured output.
- The independence and parallelism dimensions scored highest, meaning these phases can run as concurrent sub-agents without blocking the main model.
- The main model is freed to focus on Phase 2 (analysis), Phase 4 (issue creation), and Phase 5 (log update) — the cross-cutting judgment tasks that require full context.
### Proposed Sub-Agents
#### 1. `workflow-target-selector` (`small`)
**Extracted task**: Read token logs and return the highest-token unoptimized workflow with run stats.
**Why small**: Pure filter-and-sort over pre-aggregated JSON; no synthesis required.
**Score**: 7/10 (independence: 2, model-adequacy: 3, parallelism: 2, size: 2 [moderate-high])
**Estimated savings**: ~600,000 tokens/run
<details>
<summary>Agent definition (copy-paste ready)</summary>
```markdown
## agent: `workflow-target-selector`
---
description: Selects the highest-token unoptimized workflow from pre-aggregated run data.
model: small
---
You are given two JSON files on disk:
- `/tmp/gh-aw/token-audit/top-workflows.json` — pre-aggregated top workflows by token usage
- `/tmp/gh-aw/repo-memory/default/optimization-log.json` — recent optimizations (may not exist)
Task:
1. Read `top-workflows.json` and extract the `top_workflows` array.
2. Read `optimization-log.json` if it exists; collect workflow names optimized in the last 14 days.
3. Exclude workflows whose name contains "Token".
4. Exclude workflows optimized in the last 14 days.
5. Select the workflow with the highest `total_tokens` among those remaining.
6. Output a JSON object: {"workflow_name":"...","run_count":N,"total_tokens":N,"avg_tokens":N,"total_turns":N}
Output only the JSON object, no prose.
Invocation change in main prompt:
Before:
## Phase 1 — Select Target
- Start from `top-workflows.json`.
- Exclude workflows optimized in the last 14 days (use `optimization-log.json`).
- Exclude workflows with "Token" in the name to avoid self-targeting.
- Choose the highest token workflow that remains.
- If no snapshot/history exists, derive candidates directly from `all-runs.json`.
Then collect run-level data for the selected workflow:
- run count
- total and average tokens
...
After:
## Phase 1 — Select Target
Use the `workflow-target-selector` agent to identify the highest-token unoptimized workflow.
Its JSON output provides the workflow name and run stats needed for Phase 2 and Phase 3.
2. workflow-source-fetcher (small)
Extracted task: Fetch and slice a workflow .md file from GitHub, returning frontmatter and prompt body.
Why small: Straightforward gh api fetch + awk slice; purely extractive, no reasoning needed.
Score: 7/10 (independence: 3, model-adequacy: 2, parallelism: 2, size: 0 — low volume but high value)
Estimated savings: ~600,000 tokens/run
Agent definition (copy-paste ready)
## agent: `workflow-source-fetcher`
---
description: Fetches and slices a workflow .md file, returning frontmatter and prompt body.
model: small
---
Given: REPO and WF_NAME (the .md filename without path, e.g. "my-workflow.md").
Run these two bash commands and return their output labelled:
1. Frontmatter:
```bash
gh api "repos/$REPO/contents/.github/workflows/$WF_NAME" \
--jq '.content' | base64 -d \
| awk '/^---$/{n++; if(n==2) exit} n==1'
- Prompt body:
gh api "repos/$REPO/contents/.github/workflows/$WF_NAME" \
--jq '.content' | base64 -d \
| awk 'f; /^---$/{f=1}'
Return both outputs with clear "### Frontmatter" and "### Prompt Body" headers. No prose.
</details>
**Invocation change in main prompt:**
Before:
Phase 3 — Read Workflow Source
Use gh api with --jq (via cli-proxy) to read the target workflow .md source.
Extract only the sections you need — do not load the whole file if a targeted slice
is sufficient.
...
Phase 3 — Read Workflow Source
Use the workflow-source-fetcher agent with REPO and the target workflow filename
to retrieve the frontmatter and prompt body. This can run concurrently with Phase 2.
---
### Estimated Impact
| Metric | Before | After (estimated) |
|---|---|---|
| Avg tokens/run | ~6,123,474 | ~4,580,000 (~25% reduction) |
| Main-model context saved | — | ~1,500,000 tokens/run |
| Parallelism opportunity | None | Phase 2 + Phase 3 (workflow-source-fetcher) in parallel |
### Implementation Steps
1. **Common prefix**: Add `## Setup` section at the top of the prompt body and remove duplicate `REPO=` assignments and `gh api ... | base64 -d` examples from `## Data Access Guidelines` and `## Phase 3 — Read Workflow Source`
2. **Sub-agents**: Add `workflow-target-selector` and `workflow-source-fetcher` agent blocks at the bottom of `.github/workflows/agentic-token-optimizer.md`, after all workflow content
3. Update Phase 1 and Phase 3 sections to invoke sub-agents by name
4. Compile: `gh aw compile agentic-token-optimizer`
5. Test: `gh workflow run agentic-token-optimizer.yml`
**References:**
- Optimizer run: [§25953007576](https://github.com/githubnext/agentic-ops/actions/runs/25953007576)
<!-- gh-aw-tracker-id: daily-subagent-optimizer -->
> Generated by [Daily Sub-Agent Optimizer](https://github.com/githubnext/agentic-ops/actions/runs/25953007576/agentic_workflow) · ● 8.5M · [◷](https://github.com/search?q=repo%3Agithubnext%2Fagentic-ops+is%3Aissue+%22gh-aw-workflow-call-id%3A+githubnext%2Fagentic-ops%2Fdaily-subagent-optimizer%22&type=issues)
> - [x] expires <!-- gh-aw-expires: 2026-05-23T04:49:12.763Z --> on May 23, 2026, 4:49 AM UTC
<!-- gh-aw-agentic-workflow: Daily Sub-Agent Optimizer, gh-aw-tracker-id: daily-subagent-optimizer, engine: copilot, version: 1.0.40, model: claude-sonnet-4.6, id: 25953007576, workflow_id: daily-subagent-optimizer, run: https://github.com/githubnext/agentic-ops/actions/runs/25953007576 -->
<!-- gh-aw-workflow-id: daily-subagent-optimizer -->
<!-- gh-aw-workflow-call-id: githubnext/agentic-ops/daily-subagent-optimizer -->
Target Workflow
File:
.github/workflows/agentic-token-optimizer.mdEngine: copilot
7-day token usage: ~18,370,423 tokens across 3 runs (~6,123,474 avg/run)
Why This Workflow
agentic-token-optimizeris the highest-token workflow in the 7-day window by a wide margin — nearly 2× its nearest neighbour — and its 10 distinct prompt phases provide ample surface for optimization. Two phases (Phase 1 and Phase 3) are purely extractive/classificatory and well within a smaller model's capability, and two sections repeat the sameREPOsetup andgh apifile-read pattern. Eliminating that redundancy and delegating the extractive phases to asmallmodel can meaningfully reduce the main-model context loaded per run.Optimization 1 — Common Tool Prefix (Highest Priority)
Repeated Tool Calls Found
The following tool invocations appear at the start of 2 sections:
Sections affected:
## Data Access Guidelines,## Phase 3 — Read Workflow SourceProposed Setup Step
Add a
## Setupsection at the top of the prompt body that runs these calls once:All subsequent
gh apicalls must reuse$REPOand apply--jqor| jqtoextract only the fields needed. Never load full unfiltered API responses into context.
Invocation change in main prompt:
Before:
After:
2.
workflow-source-fetcher(small)Extracted task: Fetch and slice a workflow
.mdfile from GitHub, returning frontmatter and prompt body.Why small: Straightforward
gh apifetch +awkslice; purely extractive, no reasoning needed.Score: 7/10 (independence: 3, model-adequacy: 2, parallelism: 2, size: 0 — low volume but high value)
Estimated savings: ~600,000 tokens/run
Agent definition (copy-paste ready)
Return both outputs with clear "### Frontmatter" and "### Prompt Body" headers. No prose.
Phase 3 — Read Workflow Source
Use
gh apiwith--jq(via cli-proxy) to read the target workflow.mdsource.Extract only the sections you need — do not load the whole file if a targeted slice
is sufficient.
...
Phase 3 — Read Workflow Source
Use the
workflow-source-fetcheragent with REPO and the target workflow filenameto retrieve the frontmatter and prompt body. This can run concurrently with Phase 2.