Target Workflow
jsweep - JavaScript Unbloater (jsweep.md)
Selected as the highest-AIC workflow with actionable token data in the current audit window. daily-experiment-report ranked higher (1572 AIC) but had zero raw-token data, making prompt analysis impossible. No prior optimization entry exists in the log for jsweep.
Analysis Period & Runs Analyzed
| Dimension |
Value |
| Audit window |
7-day (2026-06-07 – 2026-06-14) |
| Runs with full AIC data |
1 (run §27489159289) |
| Historical runs from GitHub API |
10 (2026-06-05 – 2026-06-14) |
| Failure rate |
1 / 10 = 10% (failure on 2026-06-06) |
| Run duration range |
~12 – 21 min across 10 runs |
Cost Profile
| Metric |
Value |
| Total AIC (7-day window) |
1315.73 |
| Avg AIC / run |
1315.73 |
| Total raw tokens |
3,882,291 |
| Avg tokens / turn |
~66,936 |
| Avg turns / run |
58 |
| Avg action minutes |
20 |
| Cache efficiency |
N/A (single run in window) |
At 58 turns per run with a daily schedule, this workflow is the highest per-run turn-count in the fleet. The cumulative token cost of late turns (where context is largest) dominates spend.
Ranked Recommendations
1. Batch all type error fixes in one edit pass — avoid re-running typecheck after each fix
Estimated savings: ~120 AIC/run
Section 3 currently instructs:
- Re-run
npm run typecheck until all errors are resolved
This creates an O(n)-typecheck-runs pattern: the agent runs typecheck, fixes one error, re-runs, fixes another, and so on. With 10–15 typical type errors per file, this adds ~15–25 turns of typecheck → edit → typecheck cycles mid-conversation, where each turn carries the full accumulated context (estimated ~80–120K tokens per turn at that stage).
Action: Replace step 5 of the "@ts-nocheck removal" sub-process with:
After the first npm run typecheck, collect all reported errors. Apply all JSDoc annotations and type fixes in one batched edit (or at most two edits for large files). Then run npm run typecheck once more to verify. Do not run typecheck after each individual fix.
Evidence: 58 turns for a single-file cleanup is 3–4× the expected baseline. The typecheck iteration loop is the primary turn-count driver for files with @ts-nocheck (which are the priority-1 target on every run).
2. Parallel file reads in Section 2 (Analyze the File)
Estimated savings: ~35 AIC/run
Section 2 describes sequential sub-steps: first determine context, then check @ts-nocheck, then identify smells, then check for a test file, then read the test file. The .cjs file and its corresponding test file are independent reads that can be batched.
Action: Prepend this instruction to Section 2:
Read the target .cjs file and its corresponding test file (e.g., <basename>.test.cjs) in a single parallel batch at the start of analysis. If the test file does not exist, note it and proceed.
Evidence: Sequential analysis without batching wastes 1–2 turns on reads that have no dependency on each other.
3. Remove "Done Conditions" section and trim "Important Constraints"
Estimated savings: ~25 AIC/run
The "Done Conditions" block (16 lines) restates rules already stated in Section 7 Steps 3–4 and in "Important Constraints":
- "Stop immediately after calling
create_pull_request" — already in Step 7: "do not continue after this point"
- "Do not call
create_pull_request more than once" — already in Important Constraints: "One file per run"
- The noop guardrail — already in the noop-reminder import
"Important Constraints" itself has 8 bullets, of which 4 restate rules from Sections 3, 4, 6, and 7.
Action: Delete the entire "Done Conditions" section. Trim "Important Constraints" to 4 bullets keeping only:
@ts-nocheck priority (not covered elsewhere at section level)- No destructive cleanup commands (safety rule not repeated elsewhere)
- One file per run
- Before creating the PR, all validation checks must pass (summary reference)
This removes ~29 prompt lines, saving ~270 tokens from the system prompt on every one of 58 turns (~15,660 tokens total, ~5 AIC).
4. Remove Section 5 "Context-Specific Patterns"
Estimated savings: ~15 AIC/run
Section 5 (13 lines) lists standard GitHub Actions and Node.js API references: core.info(), github.rest.*, module.exports. These are general-knowledge APIs that the model does not require prompting on. The context classification itself is instructed in Section 2.
Action: Delete Section 5 entirely. If the author wants to keep a reference, compress it to a single sentence: "In github-script context use core.* and github.rest.*; in Node.js context use module.exports and standard patterns."
Evidence: No unique instructions in this section — all API names are standard model knowledge. 13 lines × 58 turns = token waste with no reasoning benefit.
Structural Optimization: Inline Sub-Agent
Precondition check: jsweep.md has no existing ## agent: blocks and has 9 major prompt sections — both conditions for sub-agent recommendations are met.
Candidate: File Analysis Sub-agent (Section 2)
| Dimension |
Score |
Rationale |
| Independence |
2 |
Needs the selected file path from Section 1, but nothing else |
| Small-model adequacy |
3 |
Purely extractive: read file, classify context, enumerate smells |
| Parallelism |
1 |
Sequential to Section 1; no concurrency opportunity |
| Size |
1 |
Relatively lightweight (read + classify) |
| Total |
7 |
Strong candidate |
Task for sub-agent: Given a .cjs file path, read the file and its test file in parallel, determine execution context (github-script vs Node.js), check for @ts-nocheck, and return a structured summary: {context_type, has_ts_nocheck, code_smells[], test_file_exists, test_coverage_gaps[]}.
Why a smaller model fits: This is a classification and extraction task — no code generation, no reasoning across multiple files, no iteration. The output is a short structured object. A Haiku-class model handles this accurately at a fraction of the cost.
Proposed invocation change in main prompt: Replace the bullets in Section 2 with:
## agent: analyze-file
model: haiku
input: "{{ selected_file_path }}"
Read `{{ input }}` and its test file (same directory, `.test.cjs` suffix) in parallel.
Return JSON: {"context_type": "github-script|nodejs", "has_ts_nocheck": true|false,
"code_smells": [...], "test_file_exists": true|false, "test_coverage_gaps": [...]}.
Estimated savings: ~50 AIC/run (3 turns offloaded to a cheaper model, reducing main-agent context growth early in the conversation).
Total Estimated Savings
| Recommendation |
Estimated AIC/run |
| Batch typecheck fixes (#1) |
~120 |
| Parallel file reads (#2) |
~35 |
| Remove redundant sections (#3) |
~25 |
| Remove Context Patterns section (#4) |
~15 |
| File analysis sub-agent (#5) |
~50 |
| Conservative total |
~245 |
At the observed daily schedule this represents ~245 AIC/day recoverable through low-risk prompt changes.
Caveats
- Full AIC/token data is available for only 1 run in the audit window. Turn counts and token estimates from that single run may not represent all file types (a small
.cjs with no @ts-nocheck and no type errors would use far fewer turns).
- The 1 failure on 2026-06-06 is unrelated to prompt efficiency; no reliability optimizations are recommended here.
- The sub-agent invocation syntax should follow the
## agent: block convention used elsewhere in the repo before adopting.
- Savings estimates assume a constant cost-per-token ratio; cached tokens cost less, so real savings may be lower if cache hit rates improve independently.
Run reference details
AIC/turn data available only for the run captured in the 7-day audit window.
References: §27489159289
Generated by Agentic Workflow AIC Usage Optimizer · 466.9 AIC · ⊞ 24.6K · ◷
Target Workflow
jsweep - JavaScript Unbloater (
jsweep.md)Selected as the highest-AIC workflow with actionable token data in the current audit window.
daily-experiment-reportranked higher (1572 AIC) but had zero raw-token data, making prompt analysis impossible. No prior optimization entry exists in the log for jsweep.Analysis Period & Runs Analyzed
Cost Profile
At 58 turns per run with a daily schedule, this workflow is the highest per-run turn-count in the fleet. The cumulative token cost of late turns (where context is largest) dominates spend.
Ranked Recommendations
1. Batch all type error fixes in one edit pass — avoid re-running typecheck after each fix
Estimated savings: ~120 AIC/run
Section 3 currently instructs:
This creates an O(n)-typecheck-runs pattern: the agent runs typecheck, fixes one error, re-runs, fixes another, and so on. With 10–15 typical type errors per file, this adds ~15–25 turns of
typecheck → edit → typecheckcycles mid-conversation, where each turn carries the full accumulated context (estimated ~80–120K tokens per turn at that stage).Action: Replace step 5 of the "
@ts-nocheckremoval" sub-process with:Evidence: 58 turns for a single-file cleanup is 3–4× the expected baseline. The typecheck iteration loop is the primary turn-count driver for files with
@ts-nocheck(which are the priority-1 target on every run).2. Parallel file reads in Section 2 (Analyze the File)
Estimated savings: ~35 AIC/run
Section 2 describes sequential sub-steps: first determine context, then check
@ts-nocheck, then identify smells, then check for a test file, then read the test file. The .cjs file and its corresponding test file are independent reads that can be batched.Action: Prepend this instruction to Section 2:
Evidence: Sequential analysis without batching wastes 1–2 turns on reads that have no dependency on each other.
3. Remove "Done Conditions" section and trim "Important Constraints"
Estimated savings: ~25 AIC/run
The "Done Conditions" block (16 lines) restates rules already stated in Section 7 Steps 3–4 and in "Important Constraints":
create_pull_request" — already in Step 7: "do not continue after this point"create_pull_requestmore than once" — already in Important Constraints: "One file per run""Important Constraints" itself has 8 bullets, of which 4 restate rules from Sections 3, 4, 6, and 7.
Action: Delete the entire "Done Conditions" section. Trim "Important Constraints" to 4 bullets keeping only:
@ts-nocheckpriority (not covered elsewhere at section level)This removes ~29 prompt lines, saving ~270 tokens from the system prompt on every one of 58 turns (~15,660 tokens total, ~5 AIC).
4. Remove Section 5 "Context-Specific Patterns"
Estimated savings: ~15 AIC/run
Section 5 (13 lines) lists standard GitHub Actions and Node.js API references:
core.info(),github.rest.*,module.exports. These are general-knowledge APIs that the model does not require prompting on. The context classification itself is instructed in Section 2.Action: Delete Section 5 entirely. If the author wants to keep a reference, compress it to a single sentence: "In github-script context use
core.*andgithub.rest.*; in Node.js context usemodule.exportsand standard patterns."Evidence: No unique instructions in this section — all API names are standard model knowledge. 13 lines × 58 turns = token waste with no reasoning benefit.
Structural Optimization: Inline Sub-Agent
Candidate: File Analysis Sub-agent (Section 2)
Task for sub-agent: Given a
.cjsfile path, read the file and its test file in parallel, determine execution context (github-script vs Node.js), check for@ts-nocheck, and return a structured summary:{context_type, has_ts_nocheck, code_smells[], test_file_exists, test_coverage_gaps[]}.Why a smaller model fits: This is a classification and extraction task — no code generation, no reasoning across multiple files, no iteration. The output is a short structured object. A Haiku-class model handles this accurately at a fraction of the cost.
Proposed invocation change in main prompt: Replace the bullets in Section 2 with:
Estimated savings: ~50 AIC/run (3 turns offloaded to a cheaper model, reducing main-agent context growth early in the conversation).
Total Estimated Savings
At the observed daily schedule this represents ~245 AIC/day recoverable through low-risk prompt changes.
Caveats
.cjswith no@ts-nocheckand no type errors would use far fewer turns).## agent:block convention used elsewhere in the repo before adopting.Run reference details
AIC/turn data available only for the run captured in the 7-day audit window.
References: §27489159289