The Marathon Session

How one agent shipped a terminal UI

Point an agent at an empty repo for days and you expect it to lose the thread

This autonomous Amplifier run did the opposite: it built a full Textual-based terminal UI — the repo ramparte/amplifier-tui — from an empty directory.

The obvious question: how far did it actually get before drifting?

# the repo the marathon session built $ git remote -v origin git@github.com:ramparte/amplifier-tui.git # first commit — start of the build bf6d4bc 2026-02-05 20:24 feat: initial amplifier-tui project

In one dense ~24-hour burst, it shipped 138 feature commits

Git records 142 commits — 138 of them feat: — between Feb 7 11:42 and Feb 8 12:05. Across the whole repo, 296 commits carry the Co-Authored-By: Amplifier trailer.

So it shipped at scale. But what exactly did all that output become?

142
commits in the ~24h burst
138
feat: commits in that burst
296
Co-Authored-By: Amplifier commits, repo-wide
~24h
continuous burst, after a 38.3h pause

The output is real software you can run today

amplifier-tui is a Textual terminal UI: 55,134 lines of Python, 159 _cmd_ command handlers, and 11 built-in color themes (dark, nord, dracula, and more).

A run that produces this much should not have survived — here's why.

55,134
lines of Python (excl. .venv/.git)
159
_cmd_ command handlers
11
built-in color themes
284
total commits, Feb–Apr 2026
The Problem Everyone Predicts

A run this long should have collapsed

Every context window fills, then gets wiped by compaction. The expected ending of a marathon autonomous run is drift: the agent forgets what it was doing and loses the thread.

So how did this one keep shipping across all those memory resets?

The orchestrator never held the whole job

build-session.md documents an "Autonomous Orchestrator" that delegates exploration, design, build, and bug-hunting to disposable foundation:* sub-agents — so no single context has to remember everything.

That handles the work. But where did the orchestrator keep its own memory?

Its real memory lived on disk, not in context

SESSION-HANDOFF.md and .amplifier/context/build-session.md are git-tracked files. When context is wiped, a resumed session reloads them and picks up the thread — memory that outlives every compaction.

Together these two moves are the whole survival mechanism.

Small orchestrator + disposable workers + memory on disk is why it kept shipping

And it finished clean: a disciplined 6-phase refactor (Phase 0–5, then a Phase 6 pytest suite), with a "Build Verification First" milestone that committed testing infrastructure on its own.

1,454 test functions across 40 files now stand behind the result.

  1. Phase 0–5 — type safety → widgets → commands → persistence → features → error handling
  2. Phase 6 — comprehensive pytest suite (1,454 test functions, 40 files)
  3. Build Verification First — test infra committed as its own milestone (4a89aaa, 8b988ba)
The Pattern To Keep

Long-running agents don't need a bigger memory

They need to delegate to disposable workers and keep their real state in files. A tiny orchestrator plus memory on disk beats trying to hold everything in one ever-growing context.

Small orchestrator. Disposable sub-agents. Memory on disk. That's how a marathon run finishes instead of drifting.

Sources

Research Methodology

Repo state as of: 2026-04-23 (last commit c967de0). Feature status: Shipped.

Primary sources: the ramparte/amplifier-tui git repo, .amplifier/context/build-session.md, SESSION-HANDOFF.md, and README.md.

Commands run:

Primary contributors: Sam Schillace authored 283 of 284 commits; 1 commit by Michael J. Jabbour. 296 commits carry the Co-Authored-By: Amplifier trailer.

Gaps: The ~62h figure is wall-clock and includes a 38.3h gap; continuous coding was ~24h. Compaction counts, sub-agent counts, and token figures were NOT reproducible from these repos and are deliberately not claimed. Test pass rate is not verifiable here (runtime deps not installed); only the static count of 1,454 test functions is verified.

More Amplifier Stories