Three rhythms, never one score

Build Rhythm

Build Rhythm reveals when my making bunches up and when it goes quiet. It cannot tell me whether a busy day was productive, whether a large change was good, or whether agent use caused code activity. Those limits are the reason the page keeps three clocks—and their exact tables—separate.

Reading question What can an activity trace help me notice without pretending to measure the quality of the work?

Build Rhythm token panel showing a rounded cumulative site estimate above a rounded daily increase chart
Annotated site-token chapter; interface anatomy, not live data. The image shows the cumulative site estimate above rounded daily growth. Its original viewport, theme, and interaction state were not retained. Visual field: Paper Shaders' Waves by Paper.

The conclusion

The shape is useful; the score would be fiction.

Bursts can help me remember a release, a deadline, or a long iteration loop. Quiet stretches can prompt a question. Neither one ranks the work. I use the charts to find a moment worth inspecting, then use the tables and source record to see what was actually counted.

Three questions, three clocks

Each chart answers one question at the reading speed its evidence can support. The live explorer keeps the exact, keyboard-readable table immediately behind the visual summary.

  1. Code cadence

    When did the code work bunch up?

    Reported commits mark active calendar labels. The quiet outer line is the reported total across visible sources. The crisp inner line is authored commits, and the soft band between them is merges and deploys. Added and deleted repository-text lines use only that authored subset's first-parent diffs.

    It cannot establish: time spent, difficulty, quality, or whether a large diff mattered more.

  2. Site-token rhythm

    How did this website's retained build record grow?

    Deduplicated retained logs attributed to this repo become rounded daily cumulative points. Differences between adjacent rounded points are estimates of rounded growth, not exact daily token use, and the history can change when the retained record changes.

    It cannot establish: account lifetime, a bill, causal impact on code, or tokens that are no longer retained.

  3. Personal agent days

    What does the widest completed-day agent record show?

    The tracker stacks Codex and Claude family totals on its own date domain. The shared exact family window begins July 29, while earlier Codex usage remains in the Codex baseline. This completed personal agent usage stays separate from the site estimate.

    It cannot establish: per-account activity, the content of a session, or a relationship to any particular commit.

Why the pacing changed

John Thompson shared The Rhythm of Food during a design session on balancing performance, interactivity, and effort across SVG, Canvas, and WebGL. The lesson I carried over was pacing: make one relationship legible, then let the reader inspect the record. I used that principle without copying its visual language or implementation.

Receipts: why I separated the clocks

An earlier version put GitHub activity and source-linked token history in one workbench. They looked like one story even though they used different evidence and clocks. The current version admits code history only after every declared source window validates, keeps the combined personal agent series on its own evidence boundary, and leaves this site's retained-log estimate separate.

  1. First version

    I started with GitHub weeks.

    The GitHub-only workbench at b4203f3ea made ordinary weeks visible: commits for cadence, line changes for scale. 71b8f4c89 then placed Codex history beside it.

  2. What went wrong

    The side-by-side view blurred two different clocks.

    ed0d3ba40 pulled the GitHub and Codex views apart. At 7e224db12, the public account view became one rounded checkpoint instead of a history that could expose its sources.

  3. Current version

    Each clock now carries only observations.

    6edea07f4 brought back this site's rounded daily rhythm without folding it into account usage. The explorer keeps completed personal agent days in an independently dated inset that begins with its first observed day instead of stretching that shorter record across the lifetime code domain.

Receipts: full data and revision record

Hero evidence: the current screenshot asset was committed July 16 at c613c7b0f. Its original viewport, theme, and interaction state were not retained, so it documents interface anatomy.

Data contract: Three signals, never one score. Code history appears only after exact schema-5 source-calendar coverage validates for every named source. Personal uses GitHub profile author-date labels completed in America/Los_Angeles; contributed feeds use UTC labels, so matching labels do not pretend to be one shared 24-hour window. The personal agent layer accepts only sanitized family-conserving completed-day totals with a valid provenance tuple, and deduplicated retained logs attributed to this repo form the separate site rhythm.

  1. b4203f3eaIntroduced the activity view with keyboard inspection, an exact table, and a privacy-safe fallback.
  2. 71b8f4c89Added Codex token history beside the GitHub view, creating the crowded state that the next revision separated.
  3. ed0d3ba40Separated the Codex and GitHub horizons after one overview implied a relationship the data could not support.
  4. d3f13be35Removed causal and cost clutter so the evidence returned to cadence and change.
  5. 1b07cea4cRestored additions and deletions with readable and literal scales plus stronger responsive evidence.
  6. 6b4b7bd59Added a scroll-led reading that teaches cadence, magnitude, scale, and the separate Codex clock before handing control to the exact explorer.
  7. 7e224db12Replaced source-level account history with one identity-free direct checkpoint.
  8. 6edea07f4Restored the rounded repo-scoped token rhythm within the current public boundary.

Credits

The Rhythm of Food was made by Google News Lab and Truth & Beauty. Thanks to John Thompson for sharing it and starting the conversation about storytelling across web rendering systems.