Projects

▶ View the repo here!

When I use Claude Code, I like to have my CC terminal share a screen with my IDE, and use my secondary screen for browser/research/documentation. But as my CC usage became more sophisticated (more tabs, such sophistication!) the need for at-a-glance orchestration became more salient. As it happened, I had an Adafruit LED board lying around unused from an old hobby project, and this seemed like a great way to make use of it.

I settled on an 8-session dashboard, where each section shows the last several turns, code changes, and context switches for that session. This naturally led to a histogram view. White bars with varying heights depending on token usage, red/green bars representing code changes, and full-height light blue/violet bars for compacting and clearing, respectively. Best of all, when a session is actively working on a request, the white bar shows as chugging up and down. The sessions are MRU-ordered, so I can easily remind myself where I am, what needs attention, and what's being worked on now.

What I love about this set up is it's simple but packs a lot of easy-to-grok information, so the signal-to-noise ratio is very high!

The path the data takes is another interesting part. My usual coding setup is: 1: An always-on cloud devbox running Claude, which I tunnel to via 2: my home laptop. Add in the S3 for the CircuitPy and you have 3 pieces of hardware at play. So the data flow goes: ClaudeCode (with shell hooks) runs on devbox and reaches out to a Flask state server on my home laptop over Tailscale only; the laptop drives an S3 Matrix Portal on the home LAN (CircuitPython) which renders to the HUB75 panel. Internal by design. Tailscale for cross-host traffic and a LAN-scoped Defender firewall rule for panel access, so there's no public auth surface. When I shut my laptop, the Flask server goes down and the panel shuts off, which is fine -- I'm not viewing anything and the devbox can chug away in the cloud. When I open my laptop back up, the Flask server auto restarts and S3/board come back on line.

Parts I'm especially happy with:

• Color leases, not hash-mod-8. An 8-color palette with a birthday-paradox-aware lease system that guarantees distinct colors across concurrent sessions, instead of hashing the GUID into 8 buckets and praying.
• Transcript reconstruction. Per-turn token and code-change counts are recovered by parsing the session transcript.
• High signal-to-noise ratio in the end-hardware. Doesn't take up any of my precious screen real estate, and all it takes is a quick side glance to remind myself what just finished and what's in progress.

Ideas for future improvements:

• More advanced orchestration visual design language. Sessions are treated as unique and independent, and there's no view into subagents. As development becomes more agentic, this gap gets more critical. Consider subagent view and inter-session relationship mappings. (Though keep this within reason, part of the appeal is the system's simplicity and I don't want to lose that either).
• "Waiting on Permissions" signal. One of the most common waiting signals doesn't have coverage. There's not a straightforward CC hook for this state (yet) to key off of.
• Reduce devbox/flask drift. When the Flask server goes down and comes back up, the state of the server doesn't update until one turn later. Not a huge deal because I usually need some time at this point to re-orient myself, which is usually better spend in the TUI than staring at the dashboard, but this would be nice polish.

▶ View the repo here! (pip install asexec).

This is the project on the site that sits closest to the thesis the whole site is built around: engineering-enforced AI accountability. Most of that work is about making a claim checkable by construction rather than trusting the party making it. asexec points that idea at a specific, load-bearing problem: selective disclosure in AI safety evaluations.

The framing borrows from clinical trials. There, "pre-registration" (AsPredicted, ClinicalTrials.gov) fixes what you said you'd measure before you have results, so you can't quietly bury the runs that came out badly. asexec is the "as executed" counterpart: an evaluator commits, publicly and cryptographically, to running an eval before the results are known, then publishes tamper-evident, offline-verifiable receipts of what actually happened. The reason an honest lab would want this is the interesting part: it turns "we test our models responsibly" from a claim you take on faith into one anyone can verify offline. A tester that pre-registers and then discloses gets independently-checkable credit for it; the commitment is what makes the later disclosure legible instead of merely asserted.

The cycle is four commands: keygen a pseudonymous keypair, preregister the harness + a disclosure deadline before the run, seal a receipt of the inputs and transcript after each run, and verify, which anyone can do, fully offline, with no involvement from you. Publish the pre-registration and receipts to a public git repo and a third party clones it and checks the whole chain themselves.

The part I'm most deliberate about is what it does not prove, and that the tool says so in its own verify output, not just in the docs. It proves manifests weren't altered after signing, that a receipt chain wasn't silently truncated or reordered, and (via an optional drand anchor) that a manifest is no older than a public moment. It pointedly does not prove identity (keys are pseudonymous; binding one to a real entity is a separate, optional .well-known check; asexec is not a CA), nor that the transcript is genuinely the output of the named model, nor that a lab pre-registered every eval it should have. Overclaiming is the exact failure mode an accountability tool can't afford, so the honesty is engineered in.

A design choice I like: it's a primitive, not a platform; a signing/verification library plus a thin CLI, no hosted service, no leaderboard, nothing to trust but the math and the files. And the "pre" in v1 is deliberately social, not cryptographic: the pre-registration is published to a watched public repo before the run, so the town square is the trust anchor rather than a certificate authority. The whole model leans that way: pseudonymous keys, offline verification, and identity built up by web of trust instead of blessed by a central registry.

Tentative additions I'm planning:

• An --ots mode; an OpenTimestamps/Bitcoin anchor that upgrades "pre" from a social claim to a cryptographic ceiling provable to a non-observer.
• Multi-party co-signing for a pre-registration (optional, not required), so a second party can countersign a commitment for extra weight without it becoming a gate.
• A re-execution/determinism mode, to attack the provenance gap.
• Hash-log anchoring and key transparency/web-of-trust for the identity layer.

It's v0.1, alpha. The primitive works end-to-end today.

▶ Play it here! - it runs in your browser. Great on desktop, and half-decent on mobile, too.

I always like training tools that measure your performance against optimal play. Craps is a losing proposition, EV-wise, unless you're the house. That gave me the idea for a "game" where you could play on either side of the table. Being a dealer is challenging, too. Perhaps more so, since you have to keep many payout tables in your head and deal with many bets simultaneously. So, while you can play as the player like an ordinary craps app, try out the dealer mode. That's where the real challenge lies!

Ideas for future improvements:

• Per-role timer or Time Attack mode
• A real, visual UI

Built in TypeScript and bundled with esbuild - no framework, just the DOM and a hand-rolled console UI.