Does this automatically reuse plans at runtime?

Not in the shipped OSS tool. Today the Reuse lever is find-and-export: `tj optimize reuse` clusters your runs by plan shape and surfaces the repeated plans, and `tj optimize reuse --export-templates` writes them out as reusable templates you feed back into your agent yourself. A live plan-cache that matches an incoming task to a stored plan and skips the derivation at runtime is Pro/roadmap, not the default. The shipped value is making the repeated planning visible and handing you the template to cut it by hand.

What exactly are 'planning tokens'?

The tokens the model spends deciding HOW to approach a task before it does the work: decomposing the task into steps, choosing which tools to call and in what order, reasoning about sequence and edge cases. On a novel task that reasoning is worth paying for. On a repetitive agent it is the same reasoning regenerated every run, which is what Reuse isolates and measures separately from the execution itself.

How is Reuse different from the Script lever?

Script removes deterministic, non-reasoning steps from the run entirely, so no tokens are spent on work a plain function could do. Reuse keeps the reasoning but stops you paying to redo an identical plan derivation every run. They target non-overlapping slices of the bill, so a repetitive agent often benefits from both.

Install with `pipx install tokenjam` (or `pip install tokenjam`), run `tj onboard` to start recording sessions, then `tj optimize reuse` to see the repeated plans. Add `--export-templates` to write them out. It reads your own recorded runs, so the more history you have captured, the more reliable the clustering.

Can I pull the report through MCP?

The MCP surface exposes `get_optimize_report`, which is read-only: it returns the optimization findings, including the Reuse candidates, for an agent or assistant to read. Exporting the templates is a CLI action via `tj optimize reuse --export-templates`. The read path is available over MCP; the export runs from the command line.

What if my agent's plans are all different?

Then Reuse will show scattered, low-count clusters and there is little to template, which is the correct answer: your agent is doing genuinely varied work and the planning cost is earning its keep. Reuse pays off specifically when a repetitive agent keeps re-deriving the same stable plan. The clustering tells you which case you are in before you change anything.

Stop Paying to Re-Plan Work Your Agent Already Solved

TL;DR

A repetitive agent re-derives the same plan on every run: same task decomposition, same tool ordering, same reasoning to arrive there. You pay the planning tokens each time for work it already figured out last week.
Planning is often a large, invisible slice of dollar spend on repetitive agents, and it is pure waste when the plan is stable across runs.
tj optimize reuse clusters your runs by plan shape and isolates the planning tokens (the part spent deciding HOW before doing the work).
tj optimize reuse --export-templates writes the repeated plans out as reusable templates you can feed back into your agent to skip the re-derivation.
What ships today (Level 1) finds the repeated plans and exports templates. A live plan-cache that reuses a matched plan at runtime is Pro/roadmap, not the OSS default.

Watch a repetitive agent work and you see the same opening move over and over. Give it a ticket, and before it edits a line it spends a few hundred tokens deciding how to approach the problem: break the task into steps, decide which files to read, pick the tool order, reason its way to a plan. Then it executes. The next ticket comes in, structurally identical to the last one, and the agent does the exact same derivation from scratch. It has no memory that it solved this shape of problem yesterday, so it pays full price to rediscover the plan it already knows. Across a hundred runs a day, that rediscovery is a line item you are paying in real dollars and never see broken out.

Planning is spend you are not measuring

When you look at where an agent’s cost goes, the obvious buckets are tool output, retrieved context, and the final generation. Planning hides underneath all of it. It is the reasoning the model does before it commits to an action: the “let me first understand the structure, then I’ll check the config, then update the handler” narration, the scratch reasoning about edge cases, the re-reading of instructions to decide sequence. On a one-off task that reasoning is worth every token. On a repetitive agent it is the same reasoning, regenerated each run, producing a plan you have effectively already bought.

The tricky part is that this waste is invisible to a cost dashboard. A dashboard tells you a session cost $0.40. It does not tell you that $0.12 of it was the model talking itself into a plan identical to the one it derived in the previous forty sessions. Cost dashboards report the bill; they do not tell you what to change, and re-derived planning is exactly the kind of change they cannot surface. You need something that looks across runs, groups them by the plan they arrived at, and measures the planning slice specifically.

What `tj optimize reuse` does

The Reuse lever starts from your recorded runs. If you have not captured any yet, the setup is small:

pipx install tokenjam   # or: pip install tokenjam
tj onboard

Once TokenJam is recording your agent’s sessions, run:

tj optimize reuse

This clusters your runs by plan shape. Two runs land in the same cluster when they decompose the task the same way and reach for tools in the same order, even if the specific file paths or arguments differ. Within each cluster, TokenJam isolates the planning tokens: the portion of the run spent deciding HOW before any real work happened, as distinct from the work itself. The output is a set of repeated plan skeletons ranked by how much you are spending to re-derive them. A cluster of two runs is noise. A cluster of two hundred near-identical runs, each paying to reconstruct the same plan, is a candidate you can act on.

The framing I use for reading the result: a big cluster with a heavy planning slice is a stable plan the agent keeps re-solving. That is the pure-waste case. A small, scattered set of clusters means your agent is genuinely facing varied work, and the planning cost is earning its keep.

Exporting the repeated plans as templates

Finding the clusters is the read step. To act on them, export:

tj optimize reuse --export-templates

This writes the repeated plans out as reusable templates. A template is the recovered plan skeleton for a cluster: the task decomposition and tool sequence the agent kept converging on, captured in a form you can feed back into your own agent as a starting scaffold. Instead of letting the model re-derive the approach every run, you hand it the plan it already arrived at and let it fill in the run-specific details. The reasoning that produced the plan happened once, and you stop paying to reproduce it.

Where the shipped tier stops, honestly

The version that ships in the OSS tool is Level 1: it finds the repeated plans and exports them as templates. Feeding a template back into your agent is a change you make and control. The tool does the analysis and hands you the artifact; wiring the template into your prompt scaffold is your step.

What it does not do today is live plan-caching, where the agent transparently matches an incoming task to a stored plan at runtime and skips the derivation automatically. That runtime tier is Pro/roadmap, not the OSS default, and I am not going to pretend otherwise. The honest value of the shipped lever is upstream of automation: planning is frequently a large, unmeasured fraction of spend on repetitive agents, and Reuse makes that fraction visible and gives you the template to eliminate it by hand. The runtime cache is an optimization on top of a decision you can already make yourself once you can see the repeated plans.

How this differs from the Script lever

Reuse is easy to confuse with Script, and they solve different problems. Script targets deterministic, non-reasoning steps: the parts of a run where the agent is doing something a plain function could do, and it removes those steps from the model’s path entirely so no tokens are spent on them at all. Reuse does the opposite with the reasoning. It keeps the reasoning, because deciding how to approach a task genuinely needs a model, but it stops you from paying to redo an identical decision every run.

Script deletes work that never needed a model; Reuse stops re-buying a plan the model already produced. They are complementary. A repetitive agent often has both a deterministic tail Script can strip and a stable plan skeleton Reuse can template, and the two levers attack non-overlapping slices of the same bill. If you are still mapping where that bill goes in the first place, where your agent bill actually goes and the agent token economics primer lay out the full waste surface these levers sit inside.

Common questions

Does this automatically reuse plans at runtime?: Not in the shipped OSS tool. Today the Reuse lever is find-and-export: `tj optimize reuse` clusters your runs by plan shape and surfaces the repeated plans, and `tj optimize reuse --export-templates` writes them out as reusable templates you feed back into your agent yourself. A live plan-cache that matches an incoming task to a stored plan and skips the derivation at runtime is Pro/roadmap, not the default. The shipped value is making the repeated planning visible and handing you the template to cut it by hand.
What exactly are 'planning tokens'?: The tokens the model spends deciding HOW to approach a task before it does the work: decomposing the task into steps, choosing which tools to call and in what order, reasoning about sequence and edge cases. On a novel task that reasoning is worth paying for. On a repetitive agent it is the same reasoning regenerated every run, which is what Reuse isolates and measures separately from the execution itself.
How is Reuse different from the Script lever?: Script removes deterministic, non-reasoning steps from the run entirely, so no tokens are spent on work a plain function could do. Reuse keeps the reasoning but stops you paying to redo an identical plan derivation every run. They target non-overlapping slices of the bill, so a repetitive agent often benefits from both.
How do I run it?: Install with `pipx install tokenjam` (or `pip install tokenjam`), run `tj onboard` to start recording sessions, then `tj optimize reuse` to see the repeated plans. Add `--export-templates` to write them out. It reads your own recorded runs, so the more history you have captured, the more reliable the clustering.
Can I pull the report through MCP?: The MCP surface exposes `get_optimize_report`, which is read-only: it returns the optimization findings, including the Reuse candidates, for an agent or assistant to read. Exporting the templates is a CLI action via `tj optimize reuse --export-templates`. The read path is available over MCP; the export runs from the command line.
What if my agent's plans are all different?: Then Reuse will show scattered, low-count clusters and there is little to template, which is the correct answer: your agent is doing genuinely varied work and the planning cost is earning its keep. Reuse pays off specifically when a repetitive agent keeps re-deriving the same stable plan. The clustering tells you which case you are in before you change anything.