What Grows Without Bound

A Conversation With No Last Turn

Every chat app you have used quietly assumes that conversations end. You open a new one tomorrow, the old one goes cold, and whatever it piled up stops piling up. Master Chief removes that assumption on purpose. It is one Dad-owned conversation that every doorway shares, and it has no last turn. That one design choice turns every quantity attached to a conversation into something that grows for as long as Dad keeps talking to it, which is the whole idea.

Master Chief was born on 2026-10-07. The same day, an end-to-end review of the new feature (coop #347) went through trash guards, the row marks, Dad's clock and Telegram's mirroring. It never asked what grows. Dad did, and coop todo #351 is his question. The design doc opens its growth section with the rule that came out of it: Master Chief has no last turn, so nothing about it may grow without bound.

Measured on Its Second Day

The numbers were small enough to look harmless and steep enough to be alarming:

the conversation's ground-truth log was one 16.4 MB file of 47,775 lines;
its transcript, as the API served it, was 2.9 MB, and the Telegram bot read all of it every five seconds to see whether anything new had arrived;
Claude's input per turn had grown from 146k tokens to about 314k, roughly 85k a day (measured by the next day's cold review, when the Chief was about 43 hours old);
the daily conversation archive had written a whole copy of the Chief on each of its first two days: 174,067 bytes, then 327,243.

None of these is a crisis at 43 hours. Each becomes one on a schedule you can calculate, and the calculation is the point of this lesson. A poller that reads 2.9 MB every five seconds reads about 50 GB a day, and the 2.9 MB is itself growing. An archive that stores a whole copy every day stores one day of growth, then two, then three: it grows with the square of the conversation's age. The second sample below does that arithmetic, and its archive line lands at about 10 GB a year, the same estimate the cold review wrote down.

Six Things Grow, and Each Got Its Own Bound

What grows	What breaks if it never stops	The bound it got	Lesson
The ground-truth log (JSONL)	one file every reader has to open whole	sealed segments of 8 MiB or more, plus a small active file	2
The model's replay	the brain's context window, and the cost of every turn	compaction between turns; an emergency digest when that is not enough	3, 4
The display transcript	a phone that refuses an oversized page	paged windows of at most 1,000 messages and 512 KiB of JSON; a single row larger than that comes alone	5
Sync (Telegram's poll, a WebUI refresh)	re-reading everything on every check	read `(epoch, version)` first; fetch a 100-message window only when it moved; join the newest page to what is held	5
The daily archive	quadratic disk growth	parts, not copies	5
GET-time repairs	decrypting the whole history on the event loop for one reply	newest-first reads in a thread that stop as soon as they have what they need	here

Notice what the table does not say: that any of this is one feature. Each row is its own subsystem, written, tested and then reviewed. The first versions shipped the day the Chief was born (commit 5467e2b1: segmented JSONL, an archiving compaction, a paged transcript, version-gated Telegram sync). The next morning an independent cold review found that several of those first bounds were themselves wrong. Compaction deleted the rows it took. The archive still copied the whole conversation. The WebUI's held window re-downloaded everything since the tab opened. The tool-history repair decrypted the whole segmented log on the event loop, about 0.3 seconds per 16 MB, for every reply that had used no tools. A bound is code, and code has bugs. That is why the rest of this track exists.

Where It Stands Now

Measured read-only on 2026-10-12, counts only: about two thousand message rows, 1,184 of them compacted out of the replay by two compactions, and about 36 MB of encrypted JSONL in three sealed segments plus the active file. Look at the shape. The live replay is around 800 rows, not 40, because compaction is triggered by token pressure, not by row count. The record keeps every row; only what the model is handed each turn is bounded.

First review question for any feature: what grows without bound, and when does it break? Dad's rule, written down the day of the cold review. Ask it before you ask whether the feature works, because a growth bug passes every test you will write in its first week.

Code

The Chief's growth, as measured (counts only)·text

Day 2 (2026-10-08, about 43 hours old)
  ground-truth JSONL     16.4 MB, 47,775 lines, one file
  transcript per poll    2.9 MB, read by Telegram every 5 s
  Claude input per turn  146k -> ~314k tokens (~85k a day)
  live messages          424
  daily archive          whole copy each day: 174,067 B, then 327,243 B

2026-10-12
  message rows           ~2,000 (1,184 compacted, by 2 compactions)
  JSONL                  ~36 MB = 3 sealed segments + the active file
  replay                 ~800 live rows (bounded by tokens, not rows)

A minimal sketch you can run: what two of the Chief's growers cost over a year if nothing bounds them·python

# What "grows without bound" costs, for two of Master Chief's growers.
ARCHIVE_GROWTH = 153_000     # bytes/day of archive text (cold review: 174,067 B, then 327,243 B a day later)
TRANSCRIPT_GROWTH = 1_450_000  # bytes/day of transcript JSON (assumed: 2.9 MB after two days)
POLL_SECONDS = 5
DAYS = 365

polls_per_day = 24 * 3600 // POLL_SECONDS
archive_size = transcript_size = 0
copies = parts = 0
for day in range(1, DAYS + 1):
    archive_size += ARCHIVE_GROWTH
    transcript_size += TRANSCRIPT_GROWTH
    copies += archive_size        # a whole copy every day: 1 + 2 + ... + n days of growth
    parts += ARCHIVE_GROWTH       # only what the archive does not hold yet
    if day in (2, 30, 365):
        read = transcript_size * polls_per_day
        print(f"day {day:>3}: transcript {transcript_size / 1e6:7.1f} MB; "
              f"a poller reading all of it every {POLL_SECONDS}s reads {read / 1e9:8.1f} GB that day")

print(f"archive after {DAYS} days, whole copy daily: {copies / 1e9:5.1f} GB")
print(f"archive after {DAYS} days, parts only:       {parts / 1e9:5.2f} GB")

Exercise

Pick one long-lived thing in your own project: a log file, a chat or events table, a cache directory, a poll loop. Measure it today and again in a few days (bytes, lines or rows). Then list every reader: what it reads, how often, and whether it reads everything or only what changed. Multiply size by frequency for day 30 and day 365, and name the first thing that breaks and roughly when.

Hint

Measure, do not guess: du, wc -l and a row count with a date beside it are enough. Quadratic growth hides in two phrases: 'copies the whole thing each time' and 'reads again from the start'. If a reader does either, it is your first candidate.

A Conversation With No Last Turn

Measured on Its Second Day

Six Things Grow, and Each Got Its Own Bound

Where It Stands Now

Code

External links

Exercise

Progress

Comments 0