DEV Community: Naveen Gopalakrishna

SpendLens: Private, On-Device Bank-Statement Analysis — No Login, No Cloud, No LLM

Naveen Gopalakrishna — Thu, 30 Jul 2026 07:13:08 +0000

Day 17 of #AI4Good. I used an AI coding agent to build a personal-finance app — and the single most important design decision was to keep AI, the cloud, and the network completely out of it. Your bank statement is read, parsed, and reconciled on your own device. Nothing is uploaded. Nothing is stored anywhere but your phone.

I'm Naveen Gopalakrishna — an AI Global Black Belt at Microsoft, a compulsive builder after hours. Most #AI4Good builds put AI in the product. SpendLens is the opposite, on purpose: the "good" here is financial privacy, so the intelligence lives in the parser, not in a model, and your money never leaves the device.

▶️ Try it in the browser (nothing retained): naveenneog.github.io/SpendLens
📦 Android APK: github.com/naveenneog/SpendLens/releases/latest
💻 Source: github.com/naveenneog/SpendLens

What it is

SpendLens reads a bank-statement PDF and turns it into an honest picture of where your money went — without a bank login, an OTP, a screen-scrape, or an upload.

Import a PDF through the native Android/iOS document picker (or drag one into the browser version). Password-protected statements are supported; the password is used in memory and never kept.
Reconciled summary — total spent, total received, opening and closing balance, and date range, in Indian digit grouping with tabular figures.
Spend by category, daily-spend trend, and largest spends, each with an accessible table/list equivalent and labels that never rely on colour alone.
Searchable, filterable transactions with editable categories. Correct a category once and SpendLens remembers the merchant rule for next time.
Saved statement history on-device, and a one-tap delete everything that really deletes everything.
Detection for 78 RBI scheduled retail banks — public-sector, private, small-finance, payments, and regional-rural — by official name, known aliases, and IFSC prefixes.

The cover image is the browser version analysing a fully synthetic Axis sample: an Axis Bank Ltd. statement, marked Verified, Active only in this tab, spend broken out by category, and a daily-spend chart — all rendered without a single network request leaving the page.

How it was built

The whole app is Flutter (Dart) with a thin layer of native platform code, and it was built with GitHub Copilot CLI in autopilot mode — the agent researched Indian statement formats, wrote the parser and tests, ran the builds, and drove an Android emulator smoke test end to end.

On-device PDF text extraction. Rather than ship a commercial PDF SDK, SpendLens calls the platform's own engine on a worker thread: PDFBox-Android (Kotlin) on Android and PDFKit (Swift) on iOS, over a method channel. Image-only / scanned PDFs are rejected explicitly (on-device OCR is a future module) instead of pretending they parsed.

A deterministic parser — no ML, no LLM. This is the heart of the trust model. The generic parser:

recovers multiline transaction descriptions and handles the common Indian date formats;
infers debit vs credit from the direction of consecutive running balances;
checks the opening + credits − debits = closing equation, and, when the statement declares its own debit/credit totals, validates those too — in the detected column order;
preserves DR, leading-minus, and zero-crossing overdraft balances;
and returns an explicit Verified, Needs review, or Incomplete verdict with the diagnostic attached.

It never converts a parse error into a success-shaped empty dashboard. If the numbers don't reconcile, the UI says so.

Money is integer paise, never floating point. Every amount is stored and summed as an integer so ₹0.01 rounding drift can't creep into a total.

Explainable categorization. Categories come from transparent keyword rules with token-boundary matching, so "Zuber" doesn't get filed under the ride brand "Uber," and your own merchant corrections always override the built-ins.

Local persistence. Statements, edited categories, merchant rules, and settings live in SQLite (analyses stored as JSON documents for schema agility). Category-rule updates and full data deletion are atomic transactions, and concurrent first-access is serialised through a single database-open future so startup can't race.

A custom native document picker. file_picker didn't compile cleanly against Flutter 3.44 / AGP 9, so SpendLens ships its own Storage Access Framework / UIDocumentPickerViewController picker — which also avoids asking for broad storage permissions.

A zero-retention web twin. The GitHub Pages version does the same parsing in the browser with self-hosted PDF.js and a Content-Security-Policy of connect-src 'none' — no cookies, local storage, IndexedDB, service worker, analytics, or upload endpoint. A static verify_web_privacy check runs in CI to keep it that way, and the analysis auto-clears after 15 minutes.

Verified before shipping. 40 automated tests (parser, bank registry, categorization, SQLite, controller, privacy, concurrency, widgets), a clean flutter analyze, the web-privacy verifier, and a scripted Android emulator smoke that imports a synthetic statement, checks reconciliation, and confirms that "delete everything" survives a relaunch.

The good

Most "see where your money goes" apps ask you to connect your bank — handing a third party your credentials, or trusting an aggregator to hold your transaction history. SpendLens is a bet that you shouldn't have to. Everything happens on the device you already trust with the statement. No account, no analytics SDK, no remote parser, no generative-AI dependency; Android backup/transfer is disabled and the iOS database is excluded from backups.

And it's built for Indian statements specifically — the date formats, the digit grouping, and coverage across 78 banks including the small-finance and regional-rural banks that mainstream tools ignore. When a layout is unfamiliar it degrades honestly to Needs review rather than inventing certainty.

The meta-point is the one I like most: an AI agent built a finance tool whose entire value proposition is that AI and the network never touch your money. That's a version of #AI4Good worth keeping in the toolkit — using the agent to ship privacy, not to harvest it.

Try it

▶️ Live (zero-retention browser analyzer): naveenneog.github.io/SpendLens
📦 Android APK: github.com/naveenneog/SpendLens/releases/latest
💻 Source: github.com/naveenneog/SpendLens

naveenneog / SpendLens

Privacy-first Flutter app that turns Indian bank-statement PDFs into on-device spending insights - no bank login, cloud upload, analytics, or LLMs.

SpendLens

SpendLens is a privacy-first Flutter app that turns Indian bank-statement PDFs into understandable spending summaries without bank logins, cloud uploads, or LLMs.

Version 0.2

On-device PDF text extraction and deterministic parsing
Detection registry for 78 RBI scheduled retail banks
Reconciliation and partial-parse diagnostics
Editable categories and remembered merchant rules
Category, daily-spend, and large-spend views
Searchable transactions and saved statement history
Adaptive Android/iOS layouts, light/dark themes, and accessible chart alternatives
Native Android and iOS document pickers with no broad storage permission
Password-protected PDF handling
Local SQLite persistence and complete data deletion
Zero-retention GitHub Pages analyzer in docs/
Self-hosted PDF.js with a CSP that forbids authored network connections
Explicit browser-memory clear and 15-minute inactivity clearing

Development

Flutter is installed at C:\Users\navg\flutter.

& "C:\Users\navg\flutter\bin\flutter.bat" pub get
& "C:\Users\navg\flutter\bin\flutter.bat" analyze
& "C:\Users\navg\flutter\bin\flutter.bat" test
& "C:\Users\navg\flutter\bin\flutter.bat" run

The current sideload artifact is:

artifacts\SpendLens-v0.2.0.apk

It follows…

View on GitHub

Part of the #AI4Good series — one build at a time, from a single laptop, with the "who does this help?" chosen first. GitHub · LinkedIn. #AI4Good

Overdrive: An Open-Source Skill That Makes Your Coding Agent Stop Settling for Correct

Naveen Gopalakrishna — Wed, 29 Jul 2026 08:51:47 +0000

Most of the gap between a mediocre answer and an exceptional one from the same model isn't capability. It's standards. Overdrive is the standards, written down and installed.

npx github:naveenneog/overdrive

I'm Naveen Gopalakrishna — an AI Global Black Belt at Microsoft, a compulsive builder after hours. This #AI4Good release is a tool rather than an app: an open-source agent skill that changes how hard your coding agent works.

💻 Source (MIT): github.com/naveenneog/overdrive
⚡ Install: npx github:naveenneog/overdrive
🤖 Works with: GitHub Copilot CLI · Claude Code

Where it came from

I'd collected a handful of those "show me the absolute ceiling of what you can do" prompts that get used to evaluate frontier models against each other. Five of them, in five completely unrelated domains:

Advanced web design
Real-time 3D
Motion graphics
A playable game
A private-wealth investment deck

A deck and a shader have nothing in common. But reading the five side by side, the shape of them was identical. Every one of them:

framed the ceiling, not the requirement — "the best thing you can produce", explicitly compared against other models, explicitly credited to you by name
told the model to decide and commit rather than ask which direction you'd prefer, and said the ambition of that choice was itself part of the score
named the boring, obvious, median answer up front so it could be ruled out
demanded research, not memory
offered a non-exhaustive buffet of advanced techniques and asked for several, integrated
held one dominant success criterion above everything else — fun in thirty seconds; timing; 60fps; taste; defensibility
required original assets rather than borrowed ones
ended with "QA it by actually using it"

That's not five prompts. That's one prompt wearing five costumes. So I extracted the skeleton and made it a skill.

What it actually is

Overdrive is a judgement layer, not a domain skill. It doesn't know how to build a game or write a deck. It changes how hard and how well the agent attacks whatever it was already going to do.

Ten rules override the agent's normal defaults when it's on. The two that change the most behaviour:

Decide and commit — never ask. Where the task leaves a choice open — concept, subject, genre, stack, angle — you choose. The ambition of that choice is part of the score. Asking "which would you like?" is a wasted turn.

QA by actually using it. Run it, play it, scroll it, watch it, read it end to end, stress it. An unrun deliverable is an unfinished deliverable.

The rest: frame the ceiling, name the median answer and refuse it, research instead of recalling, stack techniques rather than bolting one on, hold one dominant criterion, generate rather than borrow, survive inspection past the first screen, and red-team your own work then fix what the attack found.

Seven phases

The skill runs the work through: set the bar (write DOMAIN / CEILING / DOMINANT in three lines) → commit to a concept in one sentence → research → choose amplifiers → build with the dominant criterion in front → red-team → QA for real.

A rubric it has to report

Before declaring done, the agent scores itself 1–5 and shows you the scores:

Dimension	5 =
Ambition of the choice	The concept is impressive before a line is written
Dominant criterion	The one thing that matters is genuinely nailed
Technical depth	Multiple advanced techniques, composed — not bolted on
Craft / finish	Nothing default; deliberate typography, timing, naming, structure
Coherence	One clear point of view carried through every part
Originality	Assets, analysis and structure are yours, not borrowed
Robustness	Runs clean: no errors, no stutter, no overflow, no dead link
Honesty	Claims are sourced; estimates are labelled; limits are stated

Anything scoring ≤3 gets another pass. Scoring in the open is a forcing function — it's uncomfortable to hand someone a 3 you've written down yourself.

What's in the box

File	What it does
`SKILL.md`	The contract, the seven phases, the rubric, the failure modes, and when not to use it
`references/amplifiers.md`	Nine domain packs — web, real-time 3D, motion graphics, games, audio, research & decks, systems, data viz, writing. Each with its dominant criterion, technique buffet, library shortlist and QA moves
`references/red-team.md`	Five questions, an inversion pass, a contrast pass, how to delegate the red team to a sub-agent, and the bar for what must get fixed
`references/qa-protocol.md`	Per-domain "actually use it" QA, a browser harness, and the ship checklist
`references/research-protocol.md`	What always needs looking up, sourcing rules, and how to label an estimate as an estimate
`references/prompt-templates.md`	Paste-ready Overdrive prompts for when you are the one prompting a model
`scripts/qa_web.mjs`	Playwright harness — console/page errors, failed requests, horizontal overflow per viewport, FPS sampling, screenshots

Installing it

One command, zero runtime dependencies — the installer is plain Node and copies seven files:

# everywhere it finds an agent
npx github:naveenneog/overdrive

# or pick one
npx github:naveenneog/overdrive --claude
npx github:naveenneog/overdrive --copilot

# per-repo instead of your home directory
npx github:naveenneog/overdrive --project

# what's detected, what's already installed
npx github:naveenneog/overdrive --list

It lands in ~/.copilot/skills/overdrive and ~/.claude/skills/overdrive. There's --force, --dry-run, --dir <path> and --uninstall too.

Then start a new agent session and say "overdrive" — or "go all out", "show me the ceiling", "don't hold back", "make it a portfolio piece", "this is going public".

Does it actually do anything?

Fair question, and the honest answer is that a prompt-shaped tool is easy to fool yourself about. So here's the concrete case.

The ANTIKYTHERA title sequence — written up here — was built under Overdrive from a single prompt. A 29-second documentary title sequence in one self-contained HTML file: procedural bronze gear geometry at authentic Antikythera tooth counts, a hand-written post-processing chain, a fully synthesised Web Audio score, no assets of any kind.

But the output isn't the interesting part. Phase 7 is.

QA by actually using it is trivial for a human and structurally impossible for an agent — it can't watch a film. So it built itself an eye: installed Playwright, exposed a transport API from the piece, captured 90 frames across the runtime, assembled them into a contact sheet, and looked at the whole edit as one image.

That caught seven defects that reading the code never would have:

a wrapper div's z-index created a stacking context that isolated mix-blend-mode from the canvas — film grain rendered as raw grey static over everything
GSAP read a CSS translateY(112%) back as resolved pixels into its y cache, so the later yPercent tween animated a different axis and the title never appeared — while the tween reported progress: 1
the eclipsing moon's circles sat at SVG origin instead of the orrery centre, so totality never happened
the title wrapped onto two lines mid-animation
flash frames held 0.35s and read as an error rather than a cut
the corona quad's square edge was visible against the starfield
point-light intensities were in physical units on a renderer defaulting to legacy lighting, blowing an entire act to white

Every one of those is invisible in source and obvious in a screenshot. Without the "actually use it" clause, that piece ships broken and looks finished in the diff.

That's the mechanism. Not better code generation — better standards, and a refusal to declare done without evidence.

When not to use it

The skill says this itself, which I think matters more than the feature list. Overdrive costs time and tokens, and it explicitly tells the agent not to apply it to:

trivial mechanical edits — renames, version bumps, typos
anything you've said you want quick, minimal or throwaway
hotfixes under time pressure, where correctness and reversibility beat ambition
work with a hard external spec — an API contract, a compliance form — where invention is the enemy

A capability amplifier that fires on everything is just an expensive way to over-engineer a typo fix.

The good

Skills are the most underrated part of the current agent tooling, and they're just markdown in a folder. No SDK, no plugin API, no build. Which means the thing that separates a good agent session from a great one is largely writing down what "great" means — and that's a skill anyone can author, read, disagree with, and fork.

Overdrive is MIT. If your standards differ from mine, rewrite the rubric — that's the point. The interesting artifact isn't my eight dimensions. It's that eight dimensions written down at all beats infinite capability with no bar.

Try it

⚡ Install: npx github:naveenneog/overdrive
💻 Source (MIT): github.com/naveenneog/overdrive
🎬 Built with it: ANTIKYTHERA · the write-up

ANTIKYTHERA: A 29-Second Title Sequence in One HTML File — No Assets, No Build Step

Naveen Gopalakrishna — Sun, 26 Jul 2026 14:56:43 +0000

One prompt. No assets. No build step. No server. One index.html you can open by double-clicking it — and 29 seconds of motion design comes out.

I'm Naveen Gopalakrishna — an AI Global Black Belt at Microsoft, a compulsive builder after hours. This #AI4Good build is a little different from the app-a-day entries: it isn't an app at all. It's a film. And it's the most interesting capability test I've run at an AI coding agent so far.

▶️ Watch it: naveenneog.github.io/Antikythera
💻 Source (MIT): github.com/naveenneog/Antikythera

The prompt

This is the whole brief, verbatim. Nothing else was specified — not the subject, not the concept, not the look:

Build one motion graphics piece that demonstrates the absolute ceiling of your
motion design capability. You choose the subject and the concept. That decision
is part of what's being evaluated.

Context you should know: this is going into a video comparing you against other
frontier models, shown to a large audience, and your work will be credited to you
by name. Every model gets this exact prompt. So go nuts and show people what
you're actually capable of.

Requirements:

1. You pick it. A title sequence, a product spot, a data story, an explainer, a
   brand identity in motion, a piece of pure abstract choreography — anything.
   Decide and commit. The ambition of the choice is part of the score.

2. It plays automatically on load, runs roughly 15-30 seconds, and holds on a
   final frame. Add a replay control. It must read as a finished, edited piece —
   not a looping animation demo.

3. Choreography is the whole test. Pull from whatever best showcases you —
   including but not limited to: kinetic typography and per-character animation,
   variable font animation, staggered reveal systems, easing with real authored
   weight, overshoot and anticipation, masking and reveal wipes, SVG path drawing
   and morphing, shape transitions, mix-blend-mode compositing, particle and
   physics-driven motion, 3D layers and camera moves, depth and parallax,
   shader-based transitions, displacement and distortion, grain and optical
   treatment, match cuts between scenes, sound-design-driven timing.

4. You have free reign to look up how to use any of these, and to pull in open
   source animation libraries freely — GSAP, anime.js, Three.js, Lottie, shader
   libraries, anything on a CDN. Add any other technique you think demonstrates
   more. The list is a starting point, not a boundary.

5. Timing is what separates real motion design from animation. Beats should land
   with intent, moments should breathe, and the piece should build. If everything
   moves at the same speed with the same easing, it has failed.

6. Single self-contained index.html. Any library via CDN. No build step, no server,
   no API keys.

7. No hotlinked video or stock footage. Everything generated in-browser.

8. QA it by watching it. Play it start to finish several times. Check that beats
   don't collide, nothing pops in unstyled, timing reads, and it holds 60fps
   throughout.

Note requirement 1: the choice of subject is part of the score. That's the genuinely interesting part of the test. Anyone can animate a logo. Picking what deserves 29 seconds is a design judgement.

Why the Antikythera mechanism

Copilot picked the Antikythera mechanism — the bronze geared analog computer built around 150 BCE, lost in a shipwreck off the island of Antikythera around 60 BCE, and dredged up by sponge divers in 1901. It predicted eclipses, tracked the Metonic and Saros cycles, and modelled the motion of the sun and moon. Nothing of comparable mechanical complexity appears again in the archaeological record for over a thousand years.

The reasoning it gave for the choice is the bit I actually care about, because it's a motion design argument rather than a "cool topic" argument:

It hands you two opposing motion vocabularies to choreograph against each other.

Register	Behaviour	Where
Organic	slow, sine-driven drift, long eases, nothing ever stops hard	the sea floor
Mechanical	quantised, staccato, hard `expo` landings, overshoot and settle	the machine

The edit then cuts between those two registers. The subject isn't decoration — it generates the grammar of the piece. That's the difference between choosing a topic and choosing a concept.

The edit

Five acts, ~29 seconds, then it holds on the final frame.

t	Act	What happens
0.0s	The Dark	The frame closes to 2.39:1. Marine snow drifts through three parallax depth bands, light shafts sway, coordinates type on in the corner.
3.0s		A raking light travels across frame and uncovers a corroded bronze fragment — the light and the reveal mask are driven by the same value, so the light is physically the thing revealing the object.
5.55s	The Find	Hard cut. Register change to cold cyan. Corner reticles snap in with overshoot, data readouts stagger, a counter races to 82.
6.5s		A scan bar crosses the artifact and the gear line-art draws in exactly where the bar has already passed. Greek inscription glyphs flicker on around the rim in random order.
9.45s	The Machine	Hard cut. Eight bronze gears fly forward out of the dark and land hard. A beat of anticipation — a tiny backwards creep — and the train starts to turn.
11.2s		Four cycle cards cut over the mechanism: METONIC · SAROS · CALLIPPIC · EXELIGMOS, each with a different entrance, each with its number counting up.
15.7s		Everything accelerates, then slams to a dead stop with a prismatic radial smear.
16.5s	(silence)	Cut to black. 0.36 seconds of nothing.
16.85s	The Sky	The great gear's rim becomes the outer orbit. An orrery runs at real relative periods.
20.0s		The moon crosses the sun. Time decelerates. The light goes out, the stars come up — as they really do at totality.
22.0s		Totality. The piece stops moving for about a second.
23.85s	Title	The corona ring is squashed on one axis until it is the rule under the title. ANTIKYTHERA reveals per character.

Three match cuts carry the structure

This is the part I'd point at if someone asked what "editing" means in a piece with no footage.

The artifact becomes its own X-ray. Same SVG path, same position, same size — only the render register changes. The eye reads continuity, the brain reads a new way of seeing the same object.
The great gear's rim becomes the outer orbit. The camera lands at exactly z = 43.7 so the 223-tooth wheel's rim measures ~298px on screen; the outer orbit circle is 300px. For most of a second both are on screen at once while the machine dissolves out from under the circle. The machine doesn't cut to the sky — it becomes the sky.
The corona ring becomes the title rule. One property: scaleY → 0.0035. A circle with no height is a line. That line then slides down and is the rule under the title.

One circle, three meanings, across three acts.

How the graphics were made

Nothing is loaded. No image files, no video, no models, no HDRIs, no textures. Here's what that actually required.

Gear geometry from real tooth counts

The gears aren't decorative cog shapes. Each is a THREE.Shape whose outline is generated tooth by tooth, then extruded with THREE.ExtrudeGeometry and bevelled. The tooth counts are the real surviving Antikythera counts — 223 (the Saros wheel), 127 (Metonic), 64, 53, 48, 38, 32, 27 — laid out on a shared module, so every pitch radius is m · teeth / 2 and the gears genuinely mesh when placed tangentially:

const GEAR_SPEC = [
  {t:223, z: 0.00, abs:true, th:.46, arms:4},   // the great Saros wheel
  {t:127, z:-1.90, abs:true, th:.40, arms:3},   // Metonic, on a layer behind
  {t: 64, z: 0.98, p:0, ang: 58, th:.34, arms:3},
  {t: 53, z: 0.98, p:0, ang:  4, th:.34, arms:3},
  ...
];
// meshing distance is just the sum of the two pitch radii
const d = parent.rP + rP;
px = parent.mesh.userData.hx + Math.cos(a) * d;

Angular velocity is then ω · (223 / teeth) with alternating direction — so the train turns at true ratios. The little 27-tooth gear whirs; the great wheel barely creeps. You can feel the gearing without being told about it. Spoke cutouts are THREE.Path holes punched into the same shape, which is why you can see the Metonic wheel turning through the Saros wheel behind it.

The bronze surface, computed in JavaScript

There's no texture file, so the corrosion is a value-noise heightfield evaluated in JS at load:

An integer hash → smooth-interpolated value noise → 5-octave fBm heightfield.
Screen-space normals taken from the heightfield's neighbours.
A Lambert term against a fixed key direction, plus a tight specular power.
A second low-frequency noise field distributes verdigris patches (bronze → green patina).
A third, higher-frequency field carves pits, which also self-shadow — that's what sells the relief rather than making it look like printed noise.

It's rasterised once into three canvases and reused three ways: as an SVG <pattern> fill for the artifact, and as the map + roughnessMap + bumpMap on the gear material. One noise pass, one look, two rendering technologies.

An environment map with nothing to load

Metal needs reflections, and hotlinking an HDRI was off the table. So the environment is painted: a canvas gradient with a warm key blob and a cold cyan kicker, marked as an equirectangular texture and run through PMREMGenerator. That's where the bronze's specular life comes from.

A hand-written post-processing chain

No EffectComposer — the whole chain is written out, which keeps the cost controllable:

scene → half-float render target
      → bright pass (threshold 1.15)
      → two-scale separable gaussian bloom (¼ and 1/14 res, ping-pong)
      → one composite pass

That single composite pass does barrel distortion, prismatic radial smear, chromatic aberration, colour grade, ACES tonemap, sRGB encode and vignette. The expensive smear/aberration path — 8 taps × 3 channels — sits behind a uniform branch, so it costs nothing except on the two or three beats that actually use it (the slam, the cuts).

Optical treatment: grain and gate weave

Two details that do a disproportionate amount of work:

Film grain is eight pre-baked frames of gaussian noise (three uniforms averaged — flat Math.random() reads as video noise, not film) cycled at 24fps, not 60, with a randomised offset each swap, composited in mix-blend-mode: overlay.
Gate weave — sub-pixel translation and a fraction of a degree of rotation applied to the whole frame, because projected film never sits perfectly still. It's almost subliminal and the piece feels dead without it.

Three layers, one frame

#gl    <canvas>  Three.js — particles, gears, starfield, corona, post chain
#vec   <svg>     line art — artifact, X-ray gears, orbits, the title rule
#type  <div>     DOM      — all typography
       grain / scanlines / halation / vignette / flash / letterbox

Typography deliberately stays in the DOM: real font rendering, real variable-font axes, and it stays razor sharp regardless of the WebGL render scale. The title animates font-variation-settings from 'wght' 900 down to 420 as the letters land — the letterforms visibly cool from black to book weight while tracking in. That's a variable font doing something a static font simply cannot.

How the audio was made

Also no files. Every sound is synthesised with the Web Audio API at runtime.

Cue	How it's built
Sub drone (the bed)	Two detuned sawtooth oscillators at 40 / 40.35 Hz plus two sines, through a lowpass whose cutoff sweeps 110 → 340 → 150 Hz across the whole piece. A 0.09 Hz LFO on the gain gives it a slow tape-like breathing.
Impacts (the cuts)	A sine with a pitch envelope from 150 Hz down to 32 Hz in 0.34s, plus a band-passed noise transient for the click.
Gear ticks	50ms noise bursts through a narrow band-pass (Q = 9) at 2.4 kHz, pitch-scaled per gear so the eight gears landing sound like eight different pieces of metal.
Data blips	Short square-wave pings through a lowpass, one per readout row.
Riser (into the slam)	White noise through a band-pass sweeping 300 Hz → 7 kHz exponentially, doubled by a sawtooth sweeping 70 → 430 Hz.
Celestial pad (the sky)	Five sine partials on a minor voicing, each doubled and detuned by 0.4%, with a long 1.9s fade in.
Reverse swell (into the title)	Band-passed noise with an exponentially rising gain envelope, so it sounds like a reversed cymbal.

Reverb is a synthesised impulse response — 3.4 seconds of stereo noise shaped by an exponential decay curve, fed into a ConvolverNode. A plate reverb with no plate and no sample.

The important part isn't the synthesis, though. It's that every cue is fired from the same GSAP timeline that drives the picture:

tl.call(() => SND.hit(1.15), null, A3 - 0.050);   // the impact IS the cut
tl.call(() => SND.riser(0.95), null, A3 + 5.30);  // riser into the slam
GEARS.forEach((g, i) => {
  tl.call(() => SND.tick(0.55 + i*0.16, 0.20), null, at + 0.55);  // per gear landing
});

Sound and picture can't drift, because there's only one clock. Sound is off by default, and the piece says so rather than hiding it: a speaker icon sits in the corner from the first frame, reading turn on sound — headphones recommended. That click is the gesture that unlocks the AudioContext, so no autoplay policy is ever fought. Turn it on part-way through and the drone joins at the point in its envelope the picture has already reached, rather than restarting its five-second fade underneath Act III. The invitation steps back to a bare toggle after about eleven seconds, so it isn't sitting over the film for all 29 of them.

It's still designed to read perfectly silent — the sound is a layer on top of timing that already works.

Timing: the actual test

Requirement 5 said it plainly: if everything moves at the same speed with the same easing, it has failed.

So nothing in the piece uses a default ease. There are ten hand-authored CustomEase bezier curves, each with a job:

CE.create('cinema' ,'M0,0 C0.62,0 0.05,1 1,1');        // long filmic settle
CE.create('slam'   ,'M0,0 C0.04,0.92 0.09,1 1,1');      // hard mechanical stop
CE.create('settle' ,'M0,0 C0.12,0.86 0.18,1.045 1,1');  // land + micro overshoot
CE.create('punch'  ,'M0,0 C0.02,1.18 0.28,0.99 1,1');   // big overshoot
CE.create('antic'  ,'M0,0 C0.34,-0.30 0.18,1 1,1');     // pull back, then go
CE.create('choke'  ,'M0,0 C0.86,0.02 0.98,0.62 1,1');   // slow start, late rush

antic is the one I like best: it dips below zero before moving, so when the gear train starts turning it creeps backwards a few frames first. Classic animation anticipation, expressed as a bezier control point at y = -0.30.

And the single most effective beat in the whole piece costs nothing at all: after the mechanism slams to a stop, there is a hard cut to black and 0.36 seconds of absolutely nothing before the sky fades up. Silence and stillness, used as a beat. That's an editing decision, not an animation one.

Everything is placed on one gsap.timeline() at absolute times, so cut points are authored rather than accumulated. GSAP writes to a plain state object; the renderer only ever reads it. Picture logic and draw logic never touch each other.

How it was actually built — and what it says about capability

The whole thing was built in a single session with GitHub Copilot CLI in autopilot mode. The genuinely notable part wasn't the code generation. It was requirement 8: QA it by watching it.

An agent can't watch. So it built itself an eye:

Installed Playwright, exposed a small transport API (SEQ.seek(), SEQ.play()) from the piece.
Captured 90 frames across the runtime — every 0.5s, plus extra samples clustered on the cut points.
Assembled them into a contact sheet and looked at the whole edit as one image.
Measured frame pacing across a full real-time run (p50/p95/p99).

That loop caught seven real defects that reading the code would never have surfaced:

Bug	Why it mattered
A wrapper `div`'s `z-index` created a stacking context that isolated `mix-blend-mode` from the canvas — the film grain rendered as raw grey static over everything.	Structurally invisible in code. Obvious in one screenshot.
GSAP read a CSS `transform: translateY(112%)` back as resolved pixels into its `y` cache, so the later `yPercent` tween animated a different axis — the title never appeared at all.	The tween existed, was correctly positioned, and reported `progress: 1`. Only the picture showed it was wrong.
The eclipsing moon's circles sat at SVG origin instead of the orrery centre — it flew off-screen and totality never happened.
The title wrapped onto two lines mid-track-in.
Flash frames held ~0.35s — read as an error, not a cut. Now 2–3 frames.
The corona quad's square edge was visible against the starfield.
Point-light intensities were in physical units on a renderer defaulting to legacy lighting — the entire third act blew out to white.

Two of those were in the QA harness rather than the piece, which is its own lesson: waitForFunction's rAF polling stalls under a software rasterizer, and GSAP's seek() suppresses onUpdate by default, so scrub-based screenshots silently missed every onUpdate-driven write. Both were diagnosed by instrumenting rather than guessing.

Then, because the environment had no GPU at all (a software rasterizer — 15fps), it added adaptive resolution: if rolling frame time exceeds 21.5ms the render scale steps down, at most three times, never changing composition, timing or colour. That doubled throughput on the bad machine and stays at full resolution on real hardware.

That's the capability worth pointing at. Not "it wrote some Three.js." It made a design decision with a defensible rationale, built its own verification instrument when the requirement demanded one it didn't have, believed the evidence over its own code, and fixed things it could not have known were broken without looking.

The good

Two things, honestly.

The first is access. A 29-second title sequence of this kind is normally After Effects, Cinema 4D, a plugin stack, licences, and a render farm's worth of patience. This is one text file, three CDN links, and a browser. A student anywhere can open it, read every line, change the tooth counts, and watch what happens. There's no pipeline standing between curiosity and the thing.

The second is the subject. The Antikythera mechanism is a reminder that the ancient world was not simple, and that knowledge is genuinely fragile — this machine existed, worked, and then the entire idea of it vanished for a millennium. If a few thousand people watch 29 seconds and go and read about the Saros cycle afterwards, that's a good use of a title sequence.

Try it

▶️ Watch it: naveenneog.github.io/Antikythera — plays on load, ~29s; click the speaker to turn the score on (headphones recommended)
💻 Source (MIT, one file): github.com/naveenneog/Antikythera
🛠 Built with: Three.js r149 · GSAP + CustomEase · Web Audio API · Bodoni Moda / Archivo / JetBrains Mono · GitHub Copilot CLI

One note if you go poking: it pins Three.js r149 on purpose. r149 is the last release that ships a real UMD build/three.min.js. Everything after it is ES-module only, and module CORS blocks file:// — which would have quietly broken the "no build step, no server" constraint the moment anyone double-clicked the file.

Cast in Bidri Metal: Four Ancient Karnataka Board Games, Reborn in 3D

Naveen Gopalakrishna — Tue, 21 Jul 2026 17:27:06 +0000

Before Ludo, before Snakes & Ladders left the subcontinent and came back Anglicised, our grandmothers drew boards in rice-flour on the courtyard floor and played games older than most kingdoms. This is an attempt to give four of Karnataka's own games a home that honours where they came from — and looks good enough to keep on your phone.

I'm Naveen Gopalakrishna — an AI Global Black Belt at Microsoft, a compulsive builder after hours. This #AI4Good build is four games shipped together, each its own free web app and Android APK:

Game	What it is	Play	Get the APK
ಸಾಲು ಮನೆ ಆಟ · Saalu Mane Ata	Nine Men's Morris — align three, break one	play	APK
ಆಡು ಹುಲಿ · Aadu Huli	Goats & Tigers — the asymmetric hunt	play	APK
ಚೌಕಾ ಬಾರಾ · Chowka Bara	The cowrie-and-tokens race	play	APK
ಅಳಗುಳಿ ಮನೆ · Alaguli Mane	Pallanguzhi — the sowing & counting game	play	APK

The games, and where they come from

None of these are inventions. They're games with centuries — sometimes millennia — of continuous play across South India.

Saalu Mane Ata (Nine Men's Morris) is a mill game — three nested squares, nine seeds a side. Form a connected line of three ("a mill") and you break a rival seed. Pure strategy, no dice: the same family of game scratched into the stone floors of temples at Aihole. A game of foresight.
Aadu Huli (Goats & Tigers) is an asymmetric hunt on a triangular board — a few tigers leap to capture goats, while a herd of goats tries to hem the tigers in until they cannot move. The South Indian cousin of Bagh-Chal.
Chowka Bara (Ashta Chamma) is a race game played with cowrie shells for dice on a cross-and-circle board, with safe squares. The ancestor Ludo forgot.
Alaguli Mane (Pallanguzhi) is a mancala — two rows of pits, seeds sown counter-clockwise, pits of four captured. No luck, just counting ahead. The carved wooden board is a genuine heirloom in Kannada and Tamil homes.

Each game ships with multiple "worlds" — a Realistic heritage board, an Original glowing-3D reading, a Modern interpretation, sometimes a Fable world — and the one this post is really about.

The Bidri world — the reason this build exists

The spark for the whole project was a single question: what would these games look like if a master craftsman of Bidar made them?

Bidriware is a 14th-century metal craft from Bidar, Karnataka. A zinc-and-copper alloy is cast, engraved with floral and geometric tarkashi patterns, inlaid with pure silver wire, then blackened with a special soil from the Bidar fort — a soil that darkens the alloy to deep matte black but leaves the silver brilliant. The result is unmistakable: jet-black metal, glowing silver inlay. A GI-tagged craft, and one of the most striking in the world.

So every game got a bespoke Bidri board — not a generic skin, but a mat whose inlay is designed around that game's geometry:

How we matched real artisan work

Getting AI-generated art to actually read as Bidri — and not as "generic ornate black-and-gold" — took a tight loop:

Study first. Real Bidri is matte black, not glossy, the inlay is silver, not gold, the motifs are floral tarkashi and geometric bands, and the craft lives in the contrast. Those became hard constraints.
Prompt to the constraints. Every render was pushed toward "near-black blackened-brass ground, brilliant pure-silver inlay, delicate floral tarkashi engraving, museum-quality metalwork, soft studio light with rich reflections" using Azure gpt-image-2. Gold only as a thin rim highlight.
Align the board to the mat. The generated ornament had to sit around the playable geometry — central design centred on the board, surrounding tarkashi filling the field, the way a craftsman composes a real tray. The mat and a seamless table tile were rendered as a set.
Iterate on light & reflection. Several passes went purely into how the silver catches light and how the black holds shadow, until each board looked photographed, not textured.

The same pipeline produced each game's app icon — this game's own board, cast in Bidri. The Bidri work was distilled into a reusable "Bidri style" skill so the look stays consistent across future builds.

How it was built

The whole suite is deliberately boring where it counts so it can live forever for free:

Pure static, mobile-first, Kannada-first. No backend, no accounts, no tracking. Each game is a folder of HTML/JS/assets on GitHub Pages. Kannada is the first language, English second.
3D in the browser. A shared Three.js core (game3d) renders boards, pieces and worlds, tuned for a mid-range phone. Each game is a thin ruleset on top.
Four games, one drift-locked core. ~36 shared modules stay byte-identical across all four, enforced by a custom rc-gate that fails the build on any drift and runs the full unit-test matrix (668 tests: AH 206 · AM 161 · CB 152 · SMA 149), i18n coverage, JSON-schema contracts, language/voice-pack freshness, and an asset budget.
Six languages, packaged. Kannada + English core; four more ship as downloadable text & voice packs (an "asset diet" with a default-core build that fetches optional packs on demand).
Narration via Azure Speech neural voices, later repacked to cut size.
APKs from the same web build. Capacitor wraps each web/ folder; GitHub Actions builds a debug APK on every release (JDK 21, cap add android, gradlew assembleDebug) and attaches it automatically. Push to main → Pages redeploys; publish a release → the APK builds itself.
Art & icons: Azure gpt-image-2. Everything is open source.

What I learned

Constraints make AI art authentic. "Ornate Indian" gets you tourist-shop clip-art. "Matte-black blackened alloy, pure-silver tarkashi, no gold except a rim highlight" gets you something a Bidar artisan would recognise. Research the craft, then encode it as non-negotiables.
A drift gate is worth more than a test suite alone when shipping four near-identical apps. The most valuable script in the repo is the one that refuses to let the four codebases diverge silently.
Ship the culture first, the translation second. Kannada-first (not "English with a toggle") changed how the whole UI reads.
Static + Capacitor is a superpower for heritage software. One web/ folder becomes a free website and an installable app, zero servers — exactly right for something meant to outlast any hosting bill.
A tiny asset budget forces good decisions. Packing optional languages/voices and fetching on demand kept the base app small without cutting features.

Try it

Free, offline, no account, open source:

Saalu Mane Ata — play · APK · source
Aadu Huli — play · APK · source
Chowka Bara — play · APK · source
Alaguli Mane — play · APK · source

If you have grandparents who played these on a courtyard floor, show them the Bidri board. That reaction is the whole point.

cordless v0.8: Tab Groups, Custom Launchers & Bring-Your-Own Copilot

Naveen Gopalakrishna — Mon, 13 Jul 2026 14:51:24 +0000

TL;DR — cordless is a CLI-first tool that manages your remote terminal / coding-agent sessions and puts them on your phone. v0.8 is about organising the swarm: Chrome-mobile-style tab groups, custom launchers (bring any command as a profile), a built-in GitHub Copilot CLI profile, renameable tabs, and persisted scrollback history so a reopened session after a reboot shows what it was doing. There's also a proper cordless setup installer. Six features, each on its own branch — designed with GPT-5.6 Sol, built with GitHub Copilot CLI.

v0.7 taught cordless to tell me which of my eight agent sessions needs me. v0.8 is the next problem: once you're running that many, they stop fitting on the screen. You need to organise them — like browser tabs, because that was the whole metaphor from day one. So this release is six features that make a big session swarm manageable.

Tab groups

The headline. Sessions can now live in named, colored groups — think "API migration", "Website", "Flaky tests" — exactly like Chrome mobile's tab groups.

In the terminal dashboard, groups render as collapsible headers with a live per-group waiting/session count:

── Sessions (6) ──
▼ API migration          2 waiting · 3 sessions
  ! claude   build pipeline            waiting
  ● codex    api tests                 working
  ○ shell    api ~/src/api             idle
▶ Website                              2 sessions
▼ Ungrouped                            1 session
    ○ copilot scratch                  idle

Press g for the group menu (new / assign / ungroup / collapse / rename / delete), and f to cycle a smart-view filter — All · Attention · Claude · Codex · Copilot · Shell. Those filters are views, not groups; collapse state is per-device. On the phone you get the same idea as a chip strip above the tabs (All · Unread · one chip per group, with counts and color dots) plus rename/move in the details sheet.

The design decision I kept going back and forth on — and where Sol was firm — was manual groups over continuous auto-grouping. Auto-sorting your tabs by directory sounds clever until a session changes cwd and silently jumps groups. So groups are something you choose; deleting one never kills its sessions, it just ungroups them.

Custom launchers (and a built-in Copilot)

Until now cordless had three profiles: shell, claude, codex. v0.8 makes profiles yours. Drop this in ~/.cordless/config.json:

"profiles": {
  "api": { "command": "pwsh", "args": ["-NoLogo"], "cwd": "C:/src/api" },
  "notes": { "command": "nvim", "args": ["~/notes.md"] }
}

…and cordless new api spawns it directly (resolved against the daemon's PATH, not a shell string — no sh -c injection surface). A missing executable doesn't crash anything; it shows as unavailable with a reason, and cordless profiles lists every launcher with its source and availability.

And because the agent world moved, v0.8 ships a built-in copilot profile — the standalone GitHub Copilot CLI — right next to claude and codex. The nice part: attention detection is now preset-driven, so copilot (and any custom profile you tag attentionPreset: "agent") gets the same waiting / finished heuristics the other agents get, for free.

Rename tabs

Small feature, big daily quality-of-life. cordless rename <id> "API migration", or the dashboard e key, or a long-press on the phone. Titles are Unicode-normalized, control-stripped and length-capped, an empty title restores the generated default, and the change broadcasts live to every connected client (with a monotonic revision so a stale update can't clobber a newer one).

Persisted history — survive the reboot

This is the one that turned into a proper engineering story. A cordless session already survives a daemon restart (it reopens the same shell in the same directory). But it came back blank — you lost the scrollback. v0.8 fixes that: the daemon persists a capped, plain-text copy of each session's scrollback (2000 lines / 512 KB, gzipped, user-only) and, on restore, shows it as frozen context above the reopened session with a ── session reopened after system restart ── banner.

A couple of decisions worth calling out:

Normalized text, not raw bytes. Sol talked me out of persisting a truncated ANSI stream (it can start mid-escape-sequence and depends on terminal state you've discarded). We store logical lines from the headless terminal buffer instead.
Don't write it into the fresh terminal. My first version injected the old scrollback into the reopened shell — which promptly wiped it, because a shell like PowerShell clears its own screen on startup. So restored history is kept beside the live session and rendered above it.
Save periodically, not just on shutdown. A reboot doesn't send you a polite shutdown signal, so history is flushed every few seconds while the session runs.

The bug that only failed on Linux

Here's the part I'm glad CI caught. My persisted-history tests were green on Windows and I shipped v0.8.0. The Linux and macOS CLI builds went red on the exact same test.

The cause is a lovely cross-platform trap. On a graceful stop, the daemon catches SIGTERM and runs shutdown(): it saves each session's history, then kills the PTYs. Killing a PTY fires its exit handler — and that handler deleted the just-saved history and rewrote the "reopen these on restart" manifest without the now-exited session. So on Linux the session came back with no history; on macOS it didn't come back at all.

Why did Windows pass? Because on Windows SIGTERM from another process is an uncatchable hard-kill — shutdown() never runs, the exit handler never fires, and the periodically-flushed history file just… survives. The platform that "worked" only worked by accident.

The fix is a _shuttingDown flag so the exit handler preserves history and the manifest during a graceful stop. What I like about it: I reproduced the Linux-only failure on Windows by driving shutdown() directly in a unit test (the harness's SIGTERM can't), so the regression is now locked shut on every platform. Re-tagged, rebuilt, and v0.8.0 went out clean with the full asset set.

How it was built

Same loop, tightened further: me on GitHub Copilot CLI, GPT-5.6 Sol as the design partner — and this time with a rule I'm keeping for good: every feature on its own branch, merged --no-ff, with clean well-documented code. The v0.8 program was six branches (feature/persisted-history, feature/custom-profiles, feature/copilot-profile, feature/session-rename, feature/session-groups, feature/group-ui-phone) plus a fix/history-shutdown. The daemon's test harness grew to 24 suites — the pure profile/attention/render checks, live rename + groups over the WebSocket, the dashboard-driven resume regression, and persisted-history across a real restart — and CI runs all of it on Windows, Linux and macOS before building and smoke-testing the self-contained binary.

The good

The feeling I was chasing: open cordless with a dozen agents running and not feel underwater. The waiting ones surface (v0.7); the rest are filed into groups you named, launched from profiles you defined, titled how you think about them — and if the box reboots overnight, each one comes back with its history intact. It's the browser-tabs promise, finally delivered for a swarm of terminals.

Try it

▶️ Live / docs: naveenneog.github.io/cordless
💻 cordless CLI (Windows / Linux, no Node needed): github.com/naveenneog/cordless/releases/latest — then cordless setup
📦 Android APK: github.com/naveenneog/cordless/releases/latest
🧑‍💻 Source: github.com/naveenneog/cordless

Part of the #AI4Good series. Built one day at a time. — @naveenneog

cordless v0.7: Attention State — Know Which of Your 8 Agent Sessions Needs You

Naveen Gopalakrishna — Sat, 11 Jul 2026 18:26:03 +0000

TL;DR — cordless is a CLI-first tool that manages your remote terminal / coding-agent sessions and puts them on your phone. v0.7 adds the thing that actually matters when you're juggling many agents: per-session attention state. The daemon watches each session's output and infers whether it's working, idle, or waiting for you — then badges it, sorts attention-first, and can push a notification (ntfy / webhook) so you get pinged instead of babysitting. Also new: scrollback search, copy last output, and named workspaces. Designed with GPT-5.6 Sol, built with GitHub Copilot CLI.

Here's the real problem with running eight coding agents at once: they keep stopping to ask you things. "Apply these edits? (y/n)". "Run the tests?". One finishes; another hits an error; a third is still churning. You can't watch eight terminals. So you tab through them, and half the time you're staring at a session that's happily working while another has been blocked on a yes/no for four minutes.

v0.7 is my answer to that.

Attention state

cordless now tracks, for every session, two things:

activity — working, idle, or exited
attention — waiting (a prompt), bell, finished, or nothing

The daemon infers this purely from the session's PTY output — no shell integration, no hooks required. In the dashboard, sessions are badged and sorted attention-first, so the one that needs you floats to the top with a !:

── Sessions (3) ──  1 need attention
▸ ! claude  review PR #1284            waiting
      Apply these edits to src/api? (y/n):
  ○ codex   codex ~/src/api            idle
  ○ shell   tests ~/src/app            idle

Press c to mark it handled; sending input clears it automatically (answering is handling it). On the phone you get the same badges. cordless sessions --attention lists just the ones asking for you.

The hard part: what counts as "waiting"?

This is where I leaned on Sol the most, because naive detection is a false-positive machine. A silent build looks "stuck". A shell sitting at its prompt looks "ready" but isn't asking anything. vim and htop repaint constantly. The rules we landed on are deliberately conservative:

A trailing shell prompt ($, #, >, ❯) is readiness, not attention. Never notify on it.
A silent session is idle, not waiting — a paused agent, a long build, and a sleeping process all look the same, so we don't guess.
We only raise waiting on high-confidence confirmation/agent prompts — (y/n), "Continue?", "Do you want me to…?", "Enter your password:" — matched against the last non-empty line after a short quiet window.
Alternate-screen apps (vim/htop/less) suppress prompt heuristics entirely — better to miss a full-screen prompt than to cry wolf.
BEL (^G) is an explicit signal, so it's trusted — but ignored during a session's first few seconds and right after a keypress (startup and invalid-key beeps).
finished is heuristic and scoped to claude/codex: back at a shell prompt after real activity. It's labelled low-confidence and can be turned off.

The whole classifier is a pure, unit-tested module — 41 fixture checks across shells, pagers, and Claude/Codex-style prompts. And QA earned its keep: I caught a bug where a prompt appearing within two seconds of a keypress was silently dropped (the input-grace guard also skipped the whole quiet cycle). A cross-platform live test now locks that path shut.

Get pinged — without any cloud

Badges are great when you're looking. When you're not, v0.7 can notify you. Point it at an ntfy topic (the ntfy phone app pushes it) or a generic webhook (Slack/Discord/automation) in config.json, and cordless POSTs when a session transitions to waiting / bell / finished. cordless notify test validates it.

cordless owns no cloud for this, and the anti-spam is strict (Sol was insistent): one notification per state revision, a 60-second per-session cooldown, a 5-per-minute global cap, optional quiet hours, and no terminal output in the payload by default (it can contain code or secrets). Topic and webhook URLs are treated as secrets and never logged. Delivery is async with a short timeout — a broken webhook can never stall your terminal.

Three more coder niceties

Copy last output: cordless output <id> --lines 50 --copy grabs a session's recent output to your clipboard (cross-platform).
Scrollback search: cordless search <id> "TypeError" scans a session's retained buffer.
Workspaces: cordless workspace save api-feature snapshots your running sessions (profile + cwd + title); cordless workspace open api-feature relaunches the whole layout — "Claude on api, Codex on web, a tests shell" — in one command.

How it was built

Same loop, sharpened: me on GitHub Copilot CLI, Sol as the design partner — and this sprint I kept it honest about version control. Each feature was built on its own branch (feature/attention-state, feature/notifications, feature/output-search, feature/workspaces), tested, and merged as a unit. The daemon's test harness grew to 16 suites — pure attention heuristics, live prompt/idle detection, notifier anti-spam + delivery (injected fetch, no network), scrollback, workspaces, plus the existing protocol/security/restore coverage — and CI runs all of it on Windows and Linux, then builds and smoke-tests the self-contained binary.

The good

The feeling I was after: glance at cordless (in the terminal or on my phone) and instantly know which agent needs me — not by tabbing through eight sessions, but because the one waiting is at the top with a ! and, if I've wandered off, my phone buzzed. Everything else — search, copy, workspaces — is in service of the same thing: running a lot of agents without drowning in them.

Try it

▶️ Live / docs: naveenneog.github.io/cordless
💻 cordless CLI (Windows / Linux, no Node needed): github.com/naveenneog/cordless/releases/latest
📦 Android APK: github.com/naveenneog/cordless/releases/latest
🧑‍💻 Source: github.com/naveenneog/cordless

Part of the #AI4Good series. Built one day at a time. — @naveenneog

cordless v0.6: Going CLI-First — Run It, Scan the QR, You're Paired

Naveen Gopalakrishna — Sat, 11 Jul 2026 17:17:06 +0000

TL;DR — cordless manages your remote terminal / coding-agent (Claude Code, Codex) sessions and puts them on your phone. v0.6 makes it CLI-first: run cordless and it opens a full-screen terminal dashboard whose starting screen shows a live pairing QR — scan it, done. No separate cordless pair, no GUI to babysit. And it now ships as one self-contained binary (its own Node runtime and node-pty baked in), so there's nothing to install first. Designed in a running debate with GPT-5.6 Sol, built with GitHub Copilot CLI.

Every version so far treated cordless as "a daemon plus a phone app." Then the owner said something that reframed the whole thing:

"cordless should be a **CLI first. Look at the design of a terminal app and get the features from that. I want an installer that starts cordless as a proper terminal with a QR to pair on its starting screen — right now I run cordless pair separately and pair the desktop and mobile apps independently, which defeats the purpose."

That's a redesign, not a tweak. So I opened a long debate with Sol and rebuilt the front door.

cordless is the terminal now

Run cordless with no arguments and you get the screen on that card: a brand banner, daemon + Tailscale status, your session list, and — front and center — a single-use pairing QR with a countdown. Scan it with the phone app and you're paired. Press p for a fresh code. No second command, no separate terminal.

Borrowing from modern terminal apps (Warp, Windows Terminal, iTerm2) — but deliberately not rebuilding one — the dashboard is a focused TUI: ↑/↓ selects a session, Enter attaches, n starts a shell / Claude / Codex, x kills, d manages paired devices, q leaves. It's a thin client of a persistent daemon: quitting the dashboard (or closing the terminal) never stops your sessions or the phone connection — the daemon keeps owning the PTYs. Sol was firm on that boundary, and it's the right one.

Attach right there in your terminal

Enter (or cordless attach <id>) streams a session straight into your host terminal — no xterm.js, no second renderer. Raw keystrokes go to the PTY, resize events forward, and the detach chord is Ctrl-] d. It's a tiny tmux-like attach that reuses the exact replay/snapshot protocol the phone uses. The host terminal is the renderer; cordless just pipes bytes.

Pairing is daemon-owned now

The old cordless pair minted a secret by writing a file directly. Sol flagged that: two processes minting into the same store invites races and inconsistent limits. So in v0.6 there's one authenticated pairing.create over the WebSocket, and it can only be called by a loopback-scoped credential from a real loopback socket — the local machine's owner, never a remote phone. It's single-use, 256-bit, five-minute TTL, rate-limited, and capped. Both the dashboard and cordless pair call the same path. A stolen phone token can't enroll new devices; only you, at the machine, can.

One binary, no Node required

The biggest ask hiding in "an installer that just works" is: don't make me install Node first. So v0.6 ships a self-contained executable built with Node's Single Executable Application support:

esbuild bundles the whole CLI into one file (with node-pty marked external).
Node generates a SEA blob from that bundle.
The blob is injected into a copy of the Node runtime → cordless.exe.
node-pty and the built web client ship beside the exe under resources/, and a small loader resolves the native module from there.

The trick that made it painless: node-pty ships node-api prebuilds, which are ABI-stable across Node versions — so there's no fragile per-version native rebuild. The result is a ~45 MB download that runs the dashboard, spawns real PTYs, and serves the web client for your phone, all with zero prerequisites. CI builds and smoke-tests it (start → spawn a PTY → stop) on Windows and Linux; macOS is built the same way but still has a runner-specific node-pty spawn quirk I'm chasing, so it's flagged as pending for now.

How it was built

The same loop as the whole project — me on GitHub Copilot CLI, Sol as the design partner — but this time the pivot leaned hard on Sol's judgment: run the daemon in-process or as a persistent service? (service). How interactive should the TUI be for v0.6? (dashboard + minimal attach, not a pane framework). pkg or Node SEA? (SEA, with node-pty external). Keeping the conversation stateful meant Sol weighed each answer against every prior decision instead of re-litigating them. Ten test suites — protocol E2E, security headers, loopback-scope enforcement, daemon-owned pairing, the CLI client, dashboard rendering, and restore-across-restart — stay green on every push.

The good

The onboarding is finally one motion: install cordless, run it, scan the QR. No Node, no npm install -g, no separate pairing step, no GUI to keep open. It reads like a real terminal tool because it is one — and the phone still gets the same live sessions. Turning a "daemon + app" into "a command you run" is exactly the kind of course-correction that only lands when you actually live with the thing.

Try it

▶️ Live / docs: naveenneog.github.io/cordless
💻 cordless CLI (Windows / Linux, no Node needed): github.com/naveenneog/cordless/releases/latest
📦 Android APK: github.com/naveenneog/cordless/releases/latest
🧑‍💻 Source: github.com/naveenneog/cordless

Part of the #AI4Good series. Built one day at a time. — @naveenneog

cordless v0.5: A Desktop App, a >_< Logo, and QR-First Security

Naveen Gopalakrishna — Sat, 11 Jul 2026 09:14:05 +0000

TL;DR — cordless manages many remote terminal / coding-agent (Claude Code, Codex) sessions like browser tabs, with sessions that survive disconnects. v0.5 adds a hardened Electron desktop app (Windows .exe, macOS .dmg, Linux .AppImage/.deb), a proper >_< brand logo made with gpt-image-2, and a security course-correction: QR pairing stays the only default way in, and the desktop's one-click "Connect to this computer" uses a loopback-only credential that a Tailscale or LAN address is rejected for. As always — designed with GPT-5.6 Sol, driven with GitHub Copilot CLI.

_< logo">

I shipped cordless, then made it livable in v0.4 — seamless resume, an in-app QR scanner, no more truncation. v0.5 is about the two things a "real" tool needs that a phone app alone can't give you: a proper desktop experience, and an identity. And it's where a security instinct paid off.

A face for the project: the `>_<` logo

cordless needed a mark. I generated one with gpt-image-2 on my Azure AI Foundry deployment — a small Python script (tooling/gen_logo.py) that POSTs a prompt and writes back the base64 PNG. After iterating on a few concepts, the winner was almost too obvious: >_< — a shell prompt >_ that doubles as a happy little face — set in a blue→violet gradient inside a terminal-window frame.

One gotcha worth remembering: gpt-image-2 won't render a transparent background (you get an HTTP 400 if you ask). So I generated the mark on a dark background and luminance-keyed it transparent with Pillow (tooling/apply_logo.py) — the same script then resizes it into every size the project needs: PWA icons (icon-192/512, a maskable variant, apple-touch, favicons), the landing-page hero, and the full set of Android launcher / adaptive-icon / splash assets.

A subtle bug fell out of this: the repo's .gitignore had a blanket *.png rule (to keep Playwright screenshots out), and it was silently swallowing the new app icons. The APK and PWA would have shipped with missing icons. Two lines fixed it — !client/public/*.png, !desktop/build/*.png — a good reminder to always check git status after adding binary assets.

The desktop app — a hardened Electron shell

The headline feature. When you're at your dev box (or remoted into it), a phone is the wrong tool — you want a real window with a real keyboard. So v0.5 ships a desktop app for Windows, macOS, and Linux.

I designed the architecture in my running conversation with Sol, and we landed on the pragmatic choice: the Electron window loads the daemon's own served page at http://127.0.0.1:<port>. Because it's same-origin to the daemon, there are zero CORS/CSP changes — it's the exact same UI, sessions, tabs, and replay you already have, just in a window.

The interesting part is the security hardening, straight from Sol's review:

contextIsolation: true, nodeIntegration: false, sandbox: true, webSecurity: true.
Navigation is pinned to the trusted loopback origin — will-navigate and setWindowOpenHandler reject anything else; all new windows, <webview>s, and permission requests (camera, mic, geolocation…) are denied.
The renderer gets a tiny preload bridge and nothing else: { platform, getLocalCredential, startDaemon, retry }. No fs, no shell, no openExternal.
Every IPC call validates that the sender is one of our own trusted pages. startDaemon accepts no path, command, or argument from the page — it resolves the installed CLI itself.
If the daemon isn't running, the app shows a Start daemon / Retry screen instead of a blank window.
The port is resolved with a strict precedence — the credential's server, then the daemon config, then 7443 — and every candidate is validated to be loopback http (no https, no userinfo, no path, no localhost name ambiguity).

That last bit of parsing is security-critical, so I pulled it into a pure module (desktop/lib/resolve.js) and wrote 24 unit tests for it. It runs in CI on every push.

QR-first security — the course-correction that mattered

Here's the moment I'm most glad about. While wiring the desktop app, I built a convenient "auto-connect on localhost" path. It worked. It was also wrong — it quietly bypassed pairing. The rule for cordless is: QR / pairing-code is the one true way in.

So I tore the auto-connect out and rebuilt it as an explicit, opt-in button. The daemon now writes a desktop-credential.json (mode 0600; it stores only the token's hash) tied to a device with scope: "loopback". The authenticate() path accepts that token only when the socket peer is 127.0.0.1 / ::1 — checked against the real socket address, never a spoofable header. A Tailscale 100.x or LAN address is rejected outright. In the UI, the 🖥️ Connect to this computer button only appears when the Electron bridge actually hands over a credential; open the same page in a plain browser and you see QR/code only.

I verified it with a test that asserts exactly this: loopback IPs authenticate, and 100.64.x.x (Tailscale's range) does not. It's a local convenience that is structurally incapable of being a remote bypass.

ok    ip=127.0.0.1        authed=true   (expected true)
ok    ip=::1              authed=true   (expected true)
ok    ip=203.0.113.5      authed=false  (expected false)
ok    ip=100.64.1.2       authed=false  (expected false)   <- Tailscale, still rejected
=== LOOPBACK-SCOPE ENFORCEMENT PASS ===

Prerequisites & Tailscale, documented properly

A fair complaint about the earlier docs: the prerequisites and Tailscale setup weren't written down clearly. Fixed. The README and landing page now spell out, with Sol's help:

Prerequisites — Node.js 22, the platform build tools node-pty needs, Tailscale, and (on Windows) PowerShell 7, with download links.
Tailscale setup — tailscale up / status / ip -4, an optional device tag, a copy-pasteable tailnet ACL that locks TCP 7443 to your own identity, and a Windows Firewall rule that only opens 7443 on the Tailscale adapter (100.64.0.0/10).
Resume your sessions — cordless install once, then open the desktop app or http://localhost:7443; your tabs reattach, and after a reboot the daemon reopens them from its restore manifest.

How it was built

Same loop as the whole project: me on GitHub Copilot CLI, Sol as the design partner and reviewer — and this time I kept the conversation stateful, so Sol remembered every prior decision instead of re-litigating them. The desktop architecture, the Electron hardening checklist, and the loopback-credential rules all came out of that back-and-forth. CI does the heavy lifting: pushing a v* tag builds the Android APK and the three desktop installers on native GitHub runners and attaches them to the release. And npm test is now a self-contained harness that boots an isolated daemon and runs every suite — protocol E2E, security headers, the new desktop-credential + loopback-scope checks, and session-restore across a daemon restart. Seven suites, green.

The good

v0.5 is the version where cordless stopped feeling like a phone experiment and started feeling like a product: it has a name and a face, it runs as a real desktop app, and — the part I care about most — the convenience features were built without weakening the security model. The one-click local connect is genuinely handy, and it cannot be turned into a remote hole. That's the bar.

Try it

▶️ Live / install the PWA: naveenneog.github.io/cordless
🖥️ Desktop app (Win/macOS/Linux): github.com/naveenneog/cordless/releases/latest
📦 Android APK: github.com/naveenneog/cordless/releases/latest
💻 Source: github.com/naveenneog/cordless

Part of the #AI4Good series. Built one day at a time. — @naveenneog

cordless v0.4: Seamless Resume, an In-App QR Scanner, No More Truncation — and a Proper Install Guide

Naveen Gopalakrishna — Sat, 11 Jul 2026 07:01:52 +0000

TL;DR — cordless is a phone app that manages many remote terminal / coding-agent (Claude Code, Codex) sessions like browser tabs. v0.4 adds the three things that were stopping it from being a daily driver: seamless resume (sessions reopen when you turn your dev box on), a built-in QR scanner in the Android app, and a mobile fix so long output wraps instead of truncating — plus font zoom and a copyable session-details sheet. This post is also a proper install guide: dependencies and all.

A couple of days ago I shipped cordless — a Node daemon on my dev box that owns real PTY sessions, plus a phone app that attaches to them like tabs, with sessions that survive disconnects and replay on reconnect. Then I actually used it for two days and hit three rough edges. v0.4 fixes all three. As with the whole build, I designed each fix in a running conversation with GPT‑5.6 Sol and drove the work with GitHub Copilot CLI.

What's new in v0.4

1. Seamless resume — your tabs come back

The daemon's PTYs die when the machine reboots (they're real OS processes). So "open my laptop and my agents are still there" needs two things: the daemon must auto-start, and it must reopen what was running.

cordless install registers the daemon to start hidden at login — Windows Task Scheduler, systemd --user, or a macOS LaunchAgent, whichever you're on. There's a single-instance PID lock, and cordless stop / status to manage it.
On start, the daemon reads a small manifest of the sessions that were running and relaunches them — fresh shells in the same directories, keeping the same session ids so your phone's tabs re-match. Each restored session gets a new generation id, which the client uses to cleanly reset its replay state (a subtle but important detail Sol flagged: without it, an old client sequence number can be larger than the restored session's, and replay breaks).

It's "reopen your tabs," not "resume the process" — shell state and running child processes are gone — but combined with the app's auto-reconnect, turning your machine on brings your workspace back.

2. An in-app QR scanner (Android)

Pairing prints a QR. In the browser PWA you scan it with the phone camera and it just opens. But the packaged Android app is a different origin, so a system-camera scan wouldn't open it. The fix is the obvious one: scan from inside the app.

Tap Scan QR, point at the code, confirm the host, done. It's built on @capacitor/barcode-scanner (MLKit, bundled — no Play Services model download), with a strict URL parser that rejects anything that isn't a cordless pairing link. There's also a cordless:// deep link registered, so a cordless://pair?... link opens the app directly. (One gotcha: the scanner library needs minSdkVersion 26, so the app now targets Android 8.0+.)

3. Long text no longer gets truncated

This was the most annoying one: on a narrow phone, long lines ran off the right edge with no way to read them. The root cause was a classic flexbox trap — a flex/grid child defaults to min-width: auto, so it refuses to shrink below its content's intrinsic width, and the terminal got clipped. The fix:

min-width: 0 on the terminal's flex ancestors (the fix for the clip), plus a per-active-pane ResizeObserver that re-fits xterm whenever the pane changes size (rotation, keyboard show/hide). Now the terminal always matches the visible width and soft-wraps — no horizontal scrolling, which (per Sol) is the right call for a column-based terminal.
Font zoom — A− / A+ in the top bar, remembered per device.
A session details sheet (tap ⓘ) showing the full title, working dir, host, state, and session id, each tap-to-copy — because tab titles have to be short.

Dependencies

Nothing exotic. On the dev box (the machine your sessions run on):

Node.js ≥ 20 (LTS) and git. Windows, macOS, or Linux.
The daemon builds one native module, node-pty — it ships prebuilds, but if yours has to compile you'll want the platform build tools (VS Build Tools on Windows; build-essential + Python on Linux; Xcode Command Line Tools on macOS).

On your phone: just a browser (for the PWA) or Android 8.0+ (for the APK).

For remote access (optional): Tailscale on both devices.

Only if you want to build the APK yourself: Node ≥ 22, JDK 21, and the Android SDK (platform 34+, build-tools 34+). Most people just download the prebuilt APK from Releases.

The npm dependencies npm run setup pulls: daemon — node-pty, ws, zod, @xterm/headless, @xterm/addon-serialize, qrcode-terminal; app — @xterm/xterm (+ fit), react/vite, and @capacitor/* (core, app, barcode-scanner).

Install, properly

1 · On your dev box / laptop

git clone https://github.com/naveenneog/cordless
cd cordless
npm run setup      # installs the agent + client dependencies
npm run build      # builds the web app the daemon serves
npm start          # starts the daemon on :7443

# optional — run it automatically at every login (seamless resume):
node agent/src/index.js install

2 · Pair your phone

# in another terminal:
npm run pair       # prints a QR + a pairing code

PWA: scan the QR in your phone's browser (or open the printed URL) — it pairs automatically; then Add to Home Screen.
Android APK: download cordless-vX.Y.Z.apk, install it, open the app, tap Scan QR (or type the server URL + code).

3 · From anywhere

Install Tailscale on both devices and lock port 7443 to your own devices with a tailnet ACL. Then cordless pair prints a stable *.ts.net URL. Never expose 7443 to the public internet.

Manage it any time: cordless status · cordless stop · cordless devices · cordless uninstall.

The good

Two days of real use turned "neat demo" into "thing I actually reach for." Seamless resume means my machine rebooting overnight is a non-event — the tabs are back in the morning. The scanner removed the one annoying step in onboarding a new phone. And the wrap fix means git status, ls -la, and a chatty claude session are finally readable on a 6-inch screen. Small fixes, big difference — and every one of them came out of the builder-plus-reviewer loop (me on Copilot CLI, Sol reviewing) that's been the theme of this whole project.

Try it

▶️ Live / install the PWA: naveenneog.github.io/cordless
📦 Android APK: github.com/naveenneog/cordless/releases/latest
💻 Source: github.com/naveenneog/cordless

naveenneog / cordless

Manage many remote terminal & coding-agent (Claude Code, Codex) sessions from your phone — like browser tabs. Node agent + PWA/Android client.

cordless

Manage many remote terminal / coding-agent sessions from your phone — like browser tabs.

cordless runs a small daemon on your dev box or laptop that owns real PTY sessions (a shell, or claude / codex), and a mobile web app that attaches to them like browser tabs. Sessions keep running when you disconnect; reconnecting replays exactly where you left off.

Site: naveenneog.github.io/cordless · Download: latest APK

Persistent sessions — PTYs survive phone disconnects, network switches, and app backgrounding Reconnect replays from your last-seen byte (or a full-screen snapshot if you were away too long).
Tabs for terminals — run several Claude Code / Codex / shell sessions at once, switch instantly.
Touch-first — an on-screen key bar (Esc, Tab, Ctrl/Alt, arrows, Ctrl-C/D, pipes, paste), pinch-free font zoom (A−/A+), soft-wrapping so long lines never truncate, and a details sheet for the full cwd / session id. The Android…

View on GitHub

Part of the #AI4Good series. Built one day at a time. — @naveenneog

cordless: Managing Remote Terminals & Coding Agents From My Phone, Like Browser Tabs

Naveen Gopalakrishna — Fri, 10 Jul 2026 18:45:34 +0000

TL;DR — cordless is a tiny Node daemon on your dev box that owns real terminal sessions (a shell, or claude / codex), plus a phone app that attaches to them like browser tabs. Close the app, switch networks, come back later — your sessions are still running and replay exactly where you left off. I designed it in a running conversation with GPT-5.6 Sol on Azure, built it with GitHub Copilot CLI, and verified it in a real browser and a real Android emulator. Live: naveenneog.github.io/cordless.

I keep leaving long-running coding-agent sessions on my dev box — a claude chewing through a refactor, a build, a shell mid-task — and then walking away from the keyboard. I wanted to check on them and steer them from my phone, the way I flip between browser tabs. Not SSH-in-a-box; something that treats each agent session as a first-class tab that keeps living when my phone sleeps. So I built cordless.

What it is

Persistent sessions. The PTYs live in the daemon. Your phone disconnecting, backgrounding, or hopping from Wi‑Fi to cellular doesn't kill anything. Reconnecting replays from your last-seen byte — or a full-screen snapshot if you were away a while.
Tabs for terminals. Run several Claude Code / Codex / shell sessions at once and switch instantly, with an unread dot when a background session produces output.
Touch-first. A real terminal is unusable with thumbs without help, so there's an on-screen key bar: Esc, Tab, Ctrl/Alt (one-shot latches), arrows, Ctrl‑C/D, pipes, and paste.
Reach it from anywhere. Tailscale is the recommended path; same‑Wi‑Fi LAN also works. No ports exposed to the internet.
Web or native. Install the PWA straight from your phone browser, or grab the Android APK.

How it was built

Designed in tandem with GPT‑5.6 Sol

The interesting part of this build is that I didn't architect it alone. I kept a stateful conversation with GPT‑5.6 Sol (deployed on my Azure AI Foundry) open the entire time — not one-off prompts, but a running transcript so it stayed consistent with every prior decision. Sol produced the initial architecture, and then, crucially, reviewed my actual code. That review earned its keep.

The agent: node-pty, not tmux

Each session is a real pseudo-terminal spawned with node-pty (ConPTY on Windows — which, pleasingly, built on Node 26 first try; a Unix PTY on macOS/Linux). I deliberately did not use tmux: the daemon is already the multiplexer, and tmux adds nested-terminal state, sizing quirks, and a Windows install problem. Every session is a PTY plus a headless @xterm/headless mirror (for snapshots) plus an 8 MiB replay ring.

The subtle bug Sol caught here: @xterm/headless's write() is asynchronous, and reset() is not ordered behind queued writes. So I route every terminal write and every snapshot through one per-session op queue, and assign a batch's sequence number inside the write callback — which keeps the replay ring, the sequence counter, and serialize() perfectly consistent. Output is coalesced into ~16 ms / 32 KiB batches, one sequence number per batch.

// one op queue per session; seq assigned only after the bytes are parsed
this._queueOp(() => new Promise((resolve) => {
  this.term.write(batch, () => {
    const seq = this._nextSeq++;
    this._pushRing(seq, batch);   // ring, counter and headless mirror advance together
    this._broadcast(seq, batch);
    resolve();
  });
}));

That consistency is what makes reconnect-with-replay honest: attach with your last seq, and the server either replays the ring from there or, if it's rolled past, serializes the headless terminal into a single reset snapshot. tmux-style survival, without tmux.

The client, and the 12 bugs the review caught

The app is Vite + React + xterm.js, served by the daemon itself so the PWA is same-origin. I wrote the connection layer, thought it was solid… and handed the whole file to Sol for review. It came back with twelve real issues — not style nits, actual races:

stale-epoch writes duplicating output after a reconnect,
the duplicate-frame check gating on the wrong counter (applied vs received seq),
duplicate-attach and detach-during-attach races,
an ack timer that leaked across reconnects and cleared a fresh ack,
Ctrl/Alt latches that could get stuck,
"close tab" silently undone by the next session-list poll.

The fix pattern throughout: give every socket a connection epoch that every handler, timer, and promise verifies; serialize each tab's writes through an apply-chain; and use generation counters for attach/detach and resize. Boring, correct, and exactly the kind of thing a fresh reviewer spots that the author's brain has already glossed over.

Security, baked in from the start

Because a paired device gets shell access to my machine, security couldn't be an afterthought:

Per-device tokens, only their SHA‑256 hashes stored on the box; revoke any device by id.
Single-use, rate-limited QR pairing — and the pairing secret rides in the URL fragment, so it's never sent to (or logged by) the server.
An Origin allowlist on the WebSocket and pairing endpoints (blocks malicious web pages / DNS-rebinding), a strict CSP (script-src 'self', no inline JS), and no-store on every credential-bearing response.
The daemon warns if you run it as root/Administrator and binds with a clear least-privilege note.

There's a small automated suite that asserts all of this (cross-origin pairing → 403, cross-origin WebSocket → rejected, headers present) so it can't quietly regress.

The bug only a real emulator could find

Here's my favorite part. Everything worked perfectly as a PWA — because the browser served the app and the agent from the same origin. Then I packaged the Android APK with Capacitor and installed it on an emulator. Pairing failed instantly: "Failed to fetch."

The cause was genuinely educational. Inside a Capacitor WebView the app's origin is http://localhost, so talking to the agent is cross-origin — which triggers a CORS preflight my server had never needed to handle, because the same-origin PWA never sent one. The fix was to add CORS scoped to the existing Origin allowlist (echo Access-Control-Allow-Origin for allowed origins, answer the OPTIONS preflight, and — Sol's catch — answer the Private Network Access preflight that Chromium sends when reaching a LAN/Tailscale address). A bug that would have broken every native-app user, invisible until I drove the real APK.

After the fix, the emulator paired, connected over WebSocket, attached a session, rendered PowerShell output, and replayed full session history on reconnect — the whole loop, natively.

Shipping it

The Android APK is built by GitHub Actions on every v* tag (debug-signed, androidScheme: http + cleartext so ws:// to a Tailscale IP works) and attached straight to the release. The landing page is GitHub Pages. Networking is Tailscale-first: WireGuard encrypts the hop, you get a stable *.ts.net name, and port 7443 never touches the public internet.

The good

Sessions that outlive the client turn a phone from a read-only status screen into a real remote control for long-running agents. Check a claude refactor from the sofa, unstick a build on the train, tap Ctrl‑C on a runaway process — then walk back to your desk and the exact same sessions are there in the browser. And because the whole thing is token-gated, Tailscale-scoped, and never exposed publicly, it stays yours.

The meta-lesson: pairing a builder (me, via Copilot CLI) with a dedicated reviewer (GPT‑5.6 Sol) in a persistent conversation produced noticeably better engineering than either alone — the 12-bug review and the CORS catch are things I'd have shipped without. And testing on a real emulator, not just a browser is what turned "looks done" into "actually works."

Try it

▶️ Live / install the PWA: naveenneog.github.io/cordless
📦 Android APK: github.com/naveenneog/cordless/releases/latest
💻 Source: github.com/naveenneog/cordless

naveenneog / cordless

Manage many remote terminal & coding-agent (Claude Code, Codex) sessions from your phone — like browser tabs. Node agent + PWA/Android client.

cordless

Manage many remote terminal / coding-agent sessions from your phone — like browser tabs.

Site: naveenneog.github.io/cordless · Download: latest APK

Persistent sessions — PTYs survive phone disconnects, network switches, and app backgrounding Reconnect replays from your last-seen byte (or a full-screen snapshot if you were away too long).
Tabs for terminals — run several Claude Code / Codex / shell sessions at once, switch instantly.
Touch-first — an on-screen key bar (Esc, Tab, Ctrl/Alt, arrows, Ctrl-C/D, pipes, paste) makes a real terminal usable with thumbs.
Reach it from anywhere — Tailscale is the recommended path; same-Wi-Fi LAN also works.
Secure by…

View on GitHub

Part of the #AI4Good series. Built one day at a time. — @naveenneog

AI4Good: I Shipped an AI-for-Good App Every Few Days — Here's the Build Story

Naveen Gopalakrishna — Fri, 10 Jul 2026 08:14:57 +0000

#AI4Good started as a dare to myself: can I use AI to build and ship something genuinely useful — for kids, for health, for our culture — one build at a time? Eighteen days later there were eight live apps, each free, each on GitHub Pages. This is the story of how they came to be, in the order they were born — and each has its own deep-dive post on the AI4Good blog.

I'm Naveen Gopalakrishna — an AI Global Black Belt at Microsoft by day, a compulsive builder by night. The tooling that made this pace possible was GitHub Copilot CLI in autopilot mode (the agent researches, writes code, runs builds, and renders assets autonomously) on top of Azure AI — gpt-image-2 for art, Azure Speech for narration, and open models from Hugging Face for the heavy lifting. But tools are just tools. The thread that ties these eight together is a question I kept asking: who does this help?

Let's walk the timeline.

Jun 22 — PrimeBeats: your music, beautifully local

Where it started. PrimeBeats is an Amazon-Prime-Music-style player for the songs already on your phone — background playback, lock-screen controls, playlists, an on-device Smart Radio, and a real equalizer. No account, no ads, 100% offline. Built with React Native + Expo.

The good: ownership and privacy — your music, zero data, zero tracking, zero cost.

Jun 23 — ActionCut: put a pro video studio in everyone's pocket

The next build set the tone: take something normally locked behind subscriptions and make it free and open. ActionCut is a CapCut-class Android video editor — a real multi-track timeline, LUT color filters, GPU effects, audio mixing, and one-tap export presets for every platform. Built in Kotlin + Jetpack Compose + Media3.

The good: creators on entry-level Android phones get studio-grade editing without a paywall or a watermark. Storytelling shouldn't require a subscription.

Jun 26 — KidKat: only the good stuff, for curious kids

This is the app that named the whole campaign. KidKat plays a finite, parent-approved stream of short educational videos — inside the official YouTube player, using the official Data API, fully ToS-compliant. No infinite feed. No algorithmic rabbit holes. No doomscroll. A parent allowlist decides what's on the menu. Built with Flutter for Android and iOS.

The good: it turns the most anxiety-inducing part of modern parenting — handing a child a screen — into something calm and intentional. AI for good starts with protecting the youngest users.

Jun 27 — NeoFit: health that speaks your language

"Sehat, simple banayi." NeoFit is a science-informed Indian health and fitness app in 22 Indian languages — calorie tracking that actually knows dosa, biryani, and gulab jamun, on-device food recognition, AI-generated food photos, AI exercise videos, and Health Connect sync. Offline-first, powered by Azure AI, Kotlin/Compose.

The good: most fitness apps assume you eat like the West and read English fluently. NeoFit meets 1.4 billion people where they are — in their language, with their food. Inclusion is a health outcome.

Jul 04 — GpsCamera: proof you can trust

GpsCamera is a fast, native Android camera that burns your exact location and a live mini-map onto every photo, writes standards-compliant GPS EXIF, and files each shot into its own album. Kotlin, Compose, CameraX.

The good: field engineers, insurance surveyors, community reporters, and site inspectors need verifiable, tamper-evident documentation. A trustworthy timestamped-and-geotagged photo is a small tool that quietly protects people.

Jul 05 — The Lamp & the Machine: shadow-puppet theatre as an AI film studio

The Lamp & the Machine turns Karnataka's 500-year-old leather shadow-puppet theatre, Togalu Gombeyaata, into an AI film studio — cinematic scenes from Sora 2, narration from Azure AI, finished with Demucs + FFmpeg, retelling the story of Kempegowda, the founder of Bengaluru.

The good: generative AI as a preservation tool — putting a fading folk art in front of a new generation.

Jul 06 — Sopāna: a Snakes & Ladders that teaches

Sopāna reclaims the game the West calls Snakes & Ladders and restores its origin — the ancient Indian Moksha Patam, where every snake is a vice and every ladder a virtue. Land on one and the game animates and reads its meaning aloud. Play three ways (a 2D board, a 2.5D cinematic mode, and a 3D camera), across four worlds, with up to four players on one screen. A web PWA plus an Android APK.

The good: it turns a children's game back into what it was designed to be — a gentle lesson in ethics and consequence, wrapped in cultural heritage. AI narration and art make an 800-year-old teaching tool feel alive again.

Jul 09 — Chaturanga: ancient chess, reborn in glowing 3D

Chaturanga is the ancient Indian "game of the four divisions," played with modern chess rules but authentic piece identities — Raja, Mantri, Gaja, Ashva, Ratha, Padati — carved in real-time glowing 3D. It ships with a teaching AI (five levels), a coach that reviews your blunders, an openings trainer, a rotating piece inspector, and a Warrior's Eye camera. Four worlds, each teaching a moral lesson.

The pieces themselves are an AI-for-good story: I generated each one from a single concept image using a free Hugging Face Space and headless Blender — the full image-to-3D pipeline is its own post here.

The good: a free, offline, no-sign-in chess tutor that also carries culture — learning and heritage in one board.

What #AI4Good actually means

Look at all eight together and a pattern appears — not "AI apps," but apps that use AI to do something good:

Day	App	Who it serves	The good
Jun 22	PrimeBeats	Listeners	Own your music — offline, ad-free
Jun 23	ActionCut	Creators	Studio-grade editing, free
Jun 26	KidKat	Kids & parents	Safe, finite, educational screen time
Jun 27	NeoFit	1.4B Indians	Health in 22 languages
Jul 04	GpsCamera	Field workers	Verifiable documentation
Jul 05	The Lamp & the Machine	Culture	Preserving a folk art with AI
Jul 06	Sopāna	Families	Values + heritage, playfully
Jul 09	Chaturanga	Learners	Free chess tutor + culture

The method: one build at a time, from a single laptop, with Copilot CLI autopilot doing the heavy lifting and Azure AI + Hugging Face models supplying the intelligence. The mission: put that capability toward education, health, culture, and trust — and give it away.

This is just the beginning of the campaign. Next up the runway: Indian Tales, a multilingual Togalu Gombe (shadow-puppet) storytelling app to keep a fading folk art alive.

If you build things, I'd gently challenge you to the same dare: pick the "who does this help?" first, then let AI help you ship it. That's #AI4Good.

Follow the journey — GitHub · LinkedIn. Built one day at a time.

Carving a Glowing 3D Army from Single Images: Hugging Face + Blender, driven by Copilot CLI Autopilot

Naveen Gopalakrishna — Fri, 10 Jul 2026 07:54:18 +0000

TL;DR — One gpt-image-2 concept image per piece → a free Hugging Face Space (tencent/Hunyuan3D-2) turns it into a raw 3D mesh → headless Blender projects the concept back on as texture → a web-ready GLB that glows in Three.js. No local GPU. All of it — the research, the scripts, the Hugging Face calls, the Blender runs, and this very post and its auto-publish to DEV — was orchestrated by GitHub Copilot CLI in autopilot mode.

I've been building Chaturanga — the ancient Indian "game of the four divisions," played with modern chess moves but authentic piece identities (Raja, Mantri, Gaja, Ashva, Ratha, Padati). The board above is the payoff. The hard part was the pieces: carved-ivory war figures with real silhouettes, in four themed armies, that spin in a WebGL inspector — built for free, on a laptop with no GPU, in a fully scriptable way.

Here's how that pipeline came together, including the parts that didn't work.

The pipeline at a glance

Four stages, each free and headless:

Concept — Azure gpt-image-2 renders a carved-ivory concept per piece (front 3/4, plain background).
Image → 3D — the concept goes to a Hugging Face Space that runs image-to-3D on donated GPU and returns a mesh.
Texture — Blender 5.1, headless on CPU, projects the concept image onto the mesh.
Ship — export a decimated, textured GLB and load it in Three.js with a little emissive glow.

Step 2 is the heart: image → 3D on a free Hugging Face Space

Instead of buying GPU time, I call tencent/Hunyuan3D-2 through its Gradio API. The Space runs the heavy diffusion-to-mesh step on free ZeroGPU; I just pull back a .glb:

from gradio_client import Client, handle_file

client = Client("tencent/Hunyuan3D-2", hf_token=HF_TOKEN)   # token optional; helps rate limits
result = client.predict(
    image=handle_file("refs/raja.jpg"),
    steps=30, guidance_scale=5.0, seed=1234,
    octree_resolution=256, check_box_rembg=True,
    num_chunks=8000, randomize_seed=False,
    api_name="/shape_generation",     # geometry only — fast; texture done later in Blender
)
# result -> a raw .glb mesh, generated on someone else's GPU, for free

No-signup fallback: for a path that needs zero accounts, I keep stabilityai/TripoSR (MIT) running locally on CPU — the only open image-to-3D model I found that's genuinely CPU-feasible on Windows.

Discovering Spaces from the terminal

Copilot CLI has the Hugging Face MCP server wired in, so I search the Hub without leaving my shell. Asking for image-to-3D Spaces returns the exact shortlist this project lives on: microsoft/TRELLIS.2 (⭐1.7k), tencent/Hunyuan3D-2 (⭐3.3k, what I use), TencentARC/InstantMesh (⭐1.6k).

From flat concept to spinning figure

The gpt-image-2 concept on the left, the Hugging Face + Blender result on the right:

And on the turntable (Raja · Ashva · Gaja):

Step 3 — Where Blender earns its keep (and where it fights back)

The Hugging Face mesh has a correct silhouette but a soft surface. The crisp carving detail lives in the concept image. So Blender's job is concept-texture projection: orient the mesh, frame an orthographic camera on its front, and set each vertex's UV to that camera's projection — so the concept becomes the surface.

blender -b --python tooling/blender/texture_project.py -- \
    raw/raja_hunyuan.glb refs/raja.jpg web/raja.glb preview.png
# headless CPU: orient -> project concept as texture -> decimate to ~28k faces -> export GLB

The honest limitations I hit:

Back faces get a mirrored projection. Single-camera projection is perfect head-on; the reverse is a mirror. For board pieces seen from above, an acceptable trade — but a trade.
Blender 4 → 5 broke my material scripts. Principled BSDF sockets were renamed: Subsurface Weight not Subsurface, Specular IOR Level not Specular. KeyError until I re-bound each one.
Eevee Next won't render headless on Windows. blender -b with new Eevee crashes with an access violation — it wants a GPU context a background process lacks. Cycles on CPU renders fine; every image here is Cycles-CPU.
No native build allowed. Marching cubes runs via PyMCubes, not a compiled extension, to stay laptop-reproducible.

The detour: I first tried Blender-only procedural modeling (skin modifier, geometry nodes, baked PBR). Fully scriptable, GPU-free… and it produced primitive blobs after hours. Great for finishing, wrong tool for creating organic figures. That failure is why the Hugging Face step exists.

The tools I tried — and where they hit a wall

Constraints on purpose: free, Windows, no GPU, scriptable.

Tool	Route	Verdict under my constraints
Hunyuan3D-2 (HF Space)	image→mesh, free ZeroGPU	✅ Winner — GPU-quality geometry, no local GPU
TripoSR (local)	image→mesh, CPU	✅ Fallback — only CPU-feasible local model
Meshy AI	REST API, 200 credits/mo	⚠️ Great, but ~6 textured pieces/mo, CC-BY
Tripo AI	REST API, 300 credits/mo	⚠️ Good, but 15 downloads/mo
Rodin (Hyper3D)	REST API, pay-on-export	⚠️ Best detail, but credits burn on download
InstantMesh / TRELLIS / Wonder3D	local	❌ Not CPU-feasible — CUDA-only

The pattern: hosted APIs are excellent but metered; the best local models need a GPU I don't have. The escape hatch is a community-hosted Hugging Face Space — the model runs on donated GPU and I pay nothing but a queue wait.

The meta-story: built in Copilot CLI autopilot mode

I didn't hand-write most of this. I drove GitHub Copilot CLI in autopilot mode — where the agent runs shell commands, scripts, and tools autonomously, multi-step, without stopping for approval each move:

a research sub-agent fanned out across 13 image-to-3D tools and returned a sourced comparison;
the agent wrote and ran the batch driver, called the Hunyuan3D-2 Space, and retried on ZeroGPU hiccups;
headless Blender runs for texture and the turntables above — it caught the Eevee-headless crash and switched to Cycles itself;
and this post — rendered GIFs, diagram, prose — plus the GitHub Actions workflow that auto-published it to DEV on push.

Results & what's next

A full four-world army — Kurukshetra, Ramayana, Kalinga, Devasura — each piece a real 3D figure with a themed material and emissive bloom.

Try it: the game is live at naveenneog.github.io/Chaturanga.

naveenneog / Chaturanga

Chaturanga — the ancient Indian four-army game in real 3D: a teaching chess AI with levels, an openings trainer, a piece inspector, a Warrior's Eye camera, and two themed worlds. Web + Android.

Chaturanga — the four-army game of dharma

Chaturanga is the ancient Indian ancestor of chess — the game of the four army divisions. This is a real-3D, mobile-first take on it: authentic Chaturanga piece identities (Raja, Mantri, Ratha, Gaja, Ashva, Padati) that move by modern chess rules, where every world teaches a moral through its pieces, and a teaching AI explains the game as you play.

▶ Play: https://naveenneog.github.io/Chaturanga/ · ⬇ Android APK: see Releases

Features

Play the Guru — an alpha-beta chess AI with 5 difficulty levels (Padati → Mantri) running in a Web Worker so it stays smooth on phones.
A coach — a Hint that names the best move and why, and a blunder review that gently flags mistakes and shows the stronger move.
Openings trainer — six classic openings (Italian, Ruy López, Sicilian, French Queen's Gambit, King's Indian) walked move-by-move with a narrated…

View on GitHub

Steal the pipeline: gpt-image-2 → tencent/Hunyuan3D-2 Space → Blender projection → GLB. Free, no GPU, every step a script. For game assets, product mockups, or avatars, a free Hugging Face Space is the cheat code — and Copilot CLI autopilot stitches it all together.

Built one day at a time. — @naveenneog

DEV Community: Naveen Gopalakrishna

SpendLens: Private, On-Device Bank-Statement Analysis — No Login, No Cloud, No LLM

What it is

How it was built

The good

Try it

naveenneog / SpendLens

Privacy-first Flutter app that turns Indian bank-statement PDFs into on-device spending insights - no bank login, cloud upload, analytics, or LLMs.

SpendLens

Version 0.2

Development

Overdrive: An Open-Source Skill That Makes Your Coding Agent Stop Settling for Correct

Where it came from

What it actually is

Seven phases

A rubric it has to report

What's in the box

Installing it

Does it actually do anything?

When not to use it

The good

Try it

ANTIKYTHERA: A 29-Second Title Sequence in One HTML File — No Assets, No Build Step

The prompt

Why the Antikythera mechanism

The edit

Three match cuts carry the structure

How the graphics were made

Gear geometry from real tooth counts

The bronze surface, computed in JavaScript

An environment map with nothing to load

A hand-written post-processing chain

Optical treatment: grain and gate weave

Three layers, one frame

How the audio was made

Timing: the actual test

How it was actually built — and what it says about capability

The good

Try it

Cast in Bidri Metal: Four Ancient Karnataka Board Games, Reborn in 3D

The games, and where they come from

The Bidri world — the reason this build exists

How we matched real artisan work

How it was built

What I learned

Try it

cordless v0.8: Tab Groups, Custom Launchers & Bring-Your-Own Copilot

Tab groups

Custom launchers (and a built-in Copilot)

Rename tabs

Persisted history — survive the reboot

The bug that only failed on Linux

How it was built

The good

Try it

cordless v0.7: Attention State — Know Which of Your 8 Agent Sessions Needs You

Attention state

The hard part: what counts as "waiting"?

Get pinged — without any cloud

Three more coder niceties

How it was built

The good

Try it

cordless v0.6: Going CLI-First — Run It, Scan the QR, You're Paired

cordless is the terminal now

Attach right there in your terminal

Pairing is daemon-owned now

One binary, no Node required

How it was built

The good

Try it

cordless v0.5: A Desktop App, a >_< Logo, and QR-First Security

A face for the project: the >_< logo

The desktop app — a hardened Electron shell

QR-first security — the course-correction that mattered

Prerequisites & Tailscale, documented properly

How it was built

The good

Try it

cordless v0.4: Seamless Resume, an In-App QR Scanner, No More Truncation — and a Proper Install Guide

A face for the project: the `>_<` logo