Slim It Without Breaking It

Testing a lean Amplifier config in a disposable twin

Amplifier · In Practice

The Problem

Amplifier can burn six figures of tokens before you type a word

A full-foundation session on this machine balloons on open — and you can't safely slim the global install to fix it.

First, how big is "before you type a word"?

200K–600K

Input tokens on a bloated opening prompt

213,172

Constant assembled-prompt tokens in a spawned sub-agent

Measured, Not Felt

The bloat is a documented number, not a vibe

Local audit notes record open-time bloat directly: bloated opening prompts, a constant sub-agent prompt, and heavy laptop sessions.

So why not just trim the global install and be done?

200K–600K

Opening-prompt input tokens (lean-audit-handoff)

213,172

Constant sub-agent assembled prompt (REDESIGN-NOTES)

~350K

Tokens per laptop session (my-amplifier-lean)

The Catch

Trimming your global ~/.amplifier install puts every future session at risk

The obvious fix — hand-editing the global config — is exactly the one you can't afford. Break it, and you break every session that follows.

You need a safe place to experiment. That's what the next tool is for.

The Tool

amplifier-tester exists for exactly this job

A thin, shipping bundle whose second headline Example Use is verbatim: "try out a lean Amplifier configuration with my custom bundle composed in, without messing with my global Amplifier."

Its safety comes from one hard rule about your files.

v0.1.1

Shipping bundle version (bundle.md)

0

Runtime shipped — no provider, orchestrator, or tools; composed onto a foundation

Safety Mechanism

It snapshots your working tree — your local repo is never modified

The setup-digital-twin agent copies your working tree to a throwaway clone and pushes that to Gitea, under a hard rule to never mutate the source.

Then the snapshot runs somewhere isolated and disposable.

Hard rule: never run a state-mutating git command in the local repo path.

All commits happen in the snapshot directory, never in the source.

"Your local repo is never modified." (README)

Isolation & Teardown

The snapshot runs in an isolated twin you can destroy on command

The clone launches inside an isolated Digital Twin Universe container that installs as if pulling from upstream — then hands back an explicit teardown command.

Now you have a safe sandbox. What can you prove inside it?

1

Snapshot mirrors to Gitea, DTU profile generated with url_rewrites / pypi_overrides

2

Amplifier launches inside an isolated container, installing as if from upstream

3

amplifier-digital-twin destroy <id> tears it all down

The Payoff

The audited lean opening prompt lands at 45,451 tokens

Composed and measured inside the throwaway twin — input 20,122 + cache_write 25,329 = 45,451 — with the global install never touched.

And proving the next lean config stays cheap.

45,451

audited lean opening-prompt tokens
= 20,122 input + 25,329 cache_write

Keep This Pattern

Iterating on a lean config stays cheap

Re-run the validator and amplifier-digital-twin update <id> — no destroy-and-relaunch, no local commit — all within the repo-documented per-run wall time.

Prove a lean config safely and cheaply, then decide whether it's permanent.

~15–30

Minutes wall time per run (eval-harness README)

0

Local commits or relaunches needed to re-test

Sources

Research Methodology

Feature status: Shipping · amplifier-tester v0.1.1

Repos: microsoft/amplifier-bundle-amplifier-tester (created 2026-04-14, last pushed 2026-07-09, 12 merged PRs); microsoft/amplifier-module-provider-anthropic; local my-amplifier / .amplifier lean-audit artifacts.

Research performed:

Example Use verbatim: sed -n '8,12p' README.md
Isolated DTU claim: sed -n '3p' README.md + awareness context
Never-mutate hard rule: sed -n '205,250p' agents/setup-digital-twin.md; README line 86
Teardown command: grep -n 'destroy' agents/setup-digital-twin.md
Bloat figures: sed -n '11,19p' lean-audit-handoff.md; REDESIGN-NOTES.md; my-amplifier-lean.md
45,451 audited lean figure: hooks-token-warning/_logic.py & tests/test_logic.py
Thin bundle / v0.1.1: cat bundle.md; README line 38
Per-run wall time: .amplifier/evaluations/01-.../README.md:122 & run.sh lines 51, 90
Timeline & contributors: git log --all; gh pr list --state merged

Gaps: The "105k→53k" before/after in the original story is fabricated (zero grep hits); verified figures are 200K–600K before (bloated) and 45,451 after (audited lean). The ~15–30 min is eval-harness wall time, not a measured end-user session. No artifact links the 45,451 measurement specifically to an amplifier-tester DTU run. The DTU runtime is Incus, not Docker.

Primary contributors: David Koleczek (7 merged PRs + initial bundle); Brian Krabach (PR #9 v0.1.1, PR #11, Opus 4.7 provider support); Salil Das (PR #1).