Skip to content

[subagent-optimizer] Optimize agentic-token-optimizer — 2026-05-16 #52

@github-actions

Description

@github-actions

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'
  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.
...


After:

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 -->

Metadata

Metadata

Assignees

No one assigned

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions