DEV Community: Ronak Parmar

I Ran a 284B-Parameter LLM From 3.2GB of RAM — in Plain C

Ronak Parmar — Fri, 21 Aug 2026 13:54:48 +0000

DeepSeek-V4-Flash has 284 billion parameters and takes up about 160GB on disk. My laptop does not have 160GB of RAM. It doesn't even have 32GB.

It ran the model anyway. Peak memory: 3.23GB. With a GPU and a bit more headroom, it generates at 1.6–1.7 seconds per token. No quantizing the model down to fit, no renting a multi-GPU box. Just C99, streaming weights off NVMe as they're needed.

This post is about how deepseek-v4-in-c actually works, and — more usefully — about three bugs I hit building it that taught me more than the parts that went smoothly.

The trick that makes this possible at all

DeepSeek-V4-Flash is a mixture-of-experts model: 256 experts per layer, 43 layers, but only the top 6 experts per layer actually fire on any given token. That's the whole game. You don't need 160GB resident in memory — you need whatever fraction of the checkpoint this specific token's routing decisions touch, which works out to about 3.2GB per forward pass.

So instead of loading the model, I stream it. Every token, the router decides which experts it needs, and the engine pulls just those off disk into an LRU cache. Give it more RAM and the cache gets bigger and hits more often; give it almost none and it still runs correctly, just slower, re-reading more from disk each time.

I didn't build the streaming layer from nothing — it's ported from Fareed Khan's kimi-k3-in-c, which does the same thing for Kimi K3. The safetensors reader, the disk streamer, the memory planner, roughly 40% of the codebase — that transfers directly. The other 60% doesn't: DeepSeek-V4 and Kimi K3 don't share any math, so every kernel had to be written fresh against DeepSeek's own reference implementation.

Why I didn't trust it until I could prove it

Here's the uncomfortable truth about hand-writing inference kernels: a model with a swapped nibble or a misindexed scale factor will still produce text that reads fine. Fluent output is not evidence of a correct implementation. It just means the bug isn't catastrophic enough to break language modeling entirely.

So before I believed any of my own benchmark numbers, I checked correctness at three levels against PyTorch:

Per kernel — 14 kernels, checked individually, agreeing to 5e-7
Per block — three layer types, 46 positions, same tolerance
End-to-end — a real (tiny) deepseek_v4 checkpoint run through the actual C loader and actual inference path, matching PyTorch to 2.9e-6 with identical argmax at every single position The PyTorch side is a from-scratch reimplementation of DeepSeek's inference/model.py, not derived from my C code. If I'd built the reference from my own implementation, both could quietly agree on the same misunderstanding.

I went one step further for the C code itself: bit-exactness between the scalar path, the OpenMP path, and the AVX2 path. Not "close enough" — byte-identical, enforced with a fixed 16-accumulator reduction tree and -ffp-contract=off, checked at runtime by literally running both paths on the same input and diffing the bits. The GPU can't join that club — warp-level reduction order isn't deterministic the same way — so it gets held to relative error plus argmax match instead, and the CPU stays the ground truth.

The optimization that was actually silent corruption

This is the bug I'm most annoyed I shipped, and most glad I caught.

Reading experts off disk uses O_DIRECT, which demands the file offset, read length, and destination buffer all land on 4096-byte boundaries. The checkpoint's tensors don't naturally align that way, so my first version widened every read to the nearest aligned window, landed it in a staging buffer, then memcpy'd the actual payload into the cache slot. A 12.75MB copy, roughly 5,000 times per run. I'd written it off as cheap — "~1ms against the ~10ms the unbuffered read saves" — without actually measuring it.

I measured it. The read itself was 2.81ms. The copy was costing 3.60ms total per expert. The copy wasn't a rounding error, it was 22% of the cost.

The fix seemed simple: allocate cache slots 4096-aligned with a little slack, and place each read at the offset whose alignment residue matches the actual tensor, so the widened window lands exactly where the data belongs — no copy needed. My first attempt at that fix was wrong. It placed each read at the next offset with a matching residue, without accounting for the fact that an aligned window can begin up to 4095 bytes before the actual payload starts. So a second tensor's "aligned" read could reach backward and silently overwrite bytes belonging to the tensor before it.

Every existing test passed. Every one. Here's why: my correctness gates compared the cache against itself — serial mode against concurrent mode — and both were corrupting the data identically, so the comparison found nothing wrong. Worse, the corrupted version looked like a huge win: cache hit rate jumped from 52.6% to 95.5%, because the corruption had collapsed routing onto a tiny handful of experts. Disk reads dropped from 61GB to 5.76GB. It looked like I'd found a 5x speedup. The only thing that gave it away was that the generated token IDs were wrong.

I fixed it two ways: a new gate that compares the fast path against a plain buffered pread sharing no code with it (so it can't fail the same way), and a test fixture that actually mirrors how the real checkpoint splits an expert's tensors — three scale tensors in one disk region, three weight tensors ~341MB away at a different alignment residue. My synthetic fixture had been storing everything contiguously, which meant the bug's trigger condition literally never came up in testing. Real fix, properly verified: disk time down 16%, wall clock down 12%.

Lesson I'm keeping: if two things you're comparing can fail identically, your test proves nothing. I needed a reference path with zero shared code.

A 30x slowdown with the wrong explanation

Turning on --gpu moves the dense trunk's FP8 matrices into VRAM. Naively, that should be free for anything still running on CPU — the GPU does its thing, the CPU does its thing. It wasn't. I benchmarked a CPU-only FP4 matmul while the GPU was busy and watched throughput fall from 119 GF/s to 3.9 GF/s. A 30x collapse.

My first theory: CUDA's default sync mode spins the calling thread instead of sleeping it, so that thread competes for CPU cycles with my OpenMP workers. I switched to cudaDeviceScheduleBlockingSync, which sleeps instead of spinning. It should have fixed it.

It didn't, really — 5.0 GF/s instead of 3.9. Still a 25x collapse.

What actually fixed it: reserving one CPU core for the thread driving the GPU, and letting OpenMP use the rest. That removed the collapse completely, in either sync mode. My best guess now is DMA traffic from the GPU contending with a memory-bandwidth-bound kernel for DRAM bandwidth — but I haven't measured that, so I'm not claiming it in the README as fact. The fix works. The explanation I originally reached for was wrong, and I'd rather say that than pretend I nailed it on the first guess.

One caveat I want to be honest about: this collapse is much bigger in the microbenchmark than in the real model. The synthetic benchmark keeps the GPU saturated back-to-back; the actual model only touches it a few times per layer. On real generation, holding back a core is worth 10–15%, not 3x. An earlier draft of my README overstated this based on a heat-soaked benchmarking session, and I want to flag that explicitly rather than let an inflated number stick around.

Thermal state matters more than I expected

Speaking of that heat-soaked session — this is the correction I'm least proud of needing to make, and the most useful thing in this whole post if you benchmark anything disk-bound.

I re-ran every number in the README on a freshly rebooted, idle machine on AC power. The gap versus numbers taken after 24+ hours of sustained load was not the ±20% I'd assumed:

config	heat-soaked	cold	ratio
`--budget 1`	13.7 s/tok	4.64 s/tok	2.95x
`--budget 16`	2.65 s/tok	2.21 s/tok	1.20x
`--budget 16 --gpu`	1.81 s/tok	1.74 s/tok	1.04x

The pattern makes sense in hindsight: the more disk-bound a configuration is, the more it suffers when the machine is hot, because sequential O_DIRECT throughput itself drops under thermal load (5.3 GB/s cold vs 4.4 GB/s heat-soaked, measured directly). Low---budget runs are almost pure disk I/O, so they took the worst of it.

I now treat any single timing as ±20% at a fixed thermal state and up to 3x across states — and I resolve actual kernel changes with a dedicated microbenchmark (bench/matmul_bw.c) rather than by timing a full generation run, because a 70-second end-to-end run just can't resolve a 12% kernel improvement through that much noise.

The `--budget` flag is the one that actually matters

If you try this yourself, the flag to understand is --budget — it sets total RAM for the trunk plus the expert cache, and getting it wrong doesn't just make things slow, it can make the cache mathematically incapable of ever hitting.

One forward pass touches 258 experts across all layers — about 3.21GB. Below that, an LRU cache evicts every entry before its layer comes back around, so it can never hit. I measured this directly at an old default: 10,320 requests, 0 hits, 128GB pulled from disk for one run.

--budget    expert cache    hit rate    disk read
8 GB        1.6 GB          0%          128 GB
12 GB       5.6 GB          ~40%        ~80 GB
16 GB       9.6 GB          53%         61 GB

The engine now prints a warning naming the threshold if you're under it, because I hit this myself before I understood why my "optimized" cache was doing nothing.

Trying it yourself

make            # CPU-only build
make test       # 20 gates, no model weights required

# pack the checkpoint once
python3 tools/pack_trunk.py ~/models/dsv4-flash ~/dsv4-trunk
python3 tools/pack_tokenizer.py ~/models/dsv4-flash ~/dsv4_tok.bin

./bin/dsv4 ~/models/dsv4-flash \
    --trunk ~/dsv4-trunk \
    --tok   ~/dsv4_tok.bin \
    --prompt "The capital of France is" \
    --gen 25 --budget 16 --gpu

--chat applies DeepSeek-V4's real prompt format — I had to pull it from the checkpoint's own encoding_dsv4.py, because it isn't where most tokenizer tooling looks (tokenizer_config.json). --think opens a reasoning block before the model answers. CUDA is auto-detected; without nvcc, the build still succeeds and --gpu just reports no device found instead of failing.

What's still open

DeepSeek-V4-Pro (61 layers, 384 experts, ~865GB checkpoint) is gated and planned in the test suite but never actually run — I don't have the disk for it. The planning gate already caught a real bug: a shape-validation rule that happened to compute the right answer for Flash by coincidence (both sides of the equation collapse to 4096) but would silently fail on Pro's dimensions. A Flash-only test suite would never have caught that.
Batched prefill doesn't exist yet. Prompt tokens go through one at a time, same as generated ones, at roughly 1 second each — so a long prompt dominates latency far more than generation speed does. I've measured the expert-reuse ceiling that batching would unlock (up to ~8x weight reuse at 200+ tokens of prompt), but implementing the batched kernels is future work, not something I've shipped.
Tool-calling loop. The model correctly emits its tool-call format, but actually driving an agent loop on top of it is a layer above this CLI that I haven't built.

What I'd tell someone doing something similar
Fluent output from a hand-written kernel is not proof it's correct. Get an independently-written reference and check bit-level agreement, not vibes.
If your test compares two things that can fail the same way, it proves nothing. I needed a reference path with zero shared code to catch my worst bug.
Measure the thing you think is expensive before you "optimize" it. My memcpy was 22% of cost, not the 1ms I'd assumed.
Report the thermal state your benchmarks ran under, or don't trust them.
Code's here, Apache-2.0: github.com/ronak-create/deepseek-v4-in-c

We tested "tokenize before you compress" against 452 configurations, and it mostly held up

Ronak Parmar — Fri, 21 Aug 2026 01:37:16 +0000

A few weeks ago my friend @u84u and I (@ronak-create) had a simple, slightly annoying question: if LLMs get 30-45% smaller representations of text by tokenizing it into subwords instead of raw bytes, why don't we tokenize text before handing it to a byte-level compressor like LZMA or zstd?

It felt like the kind of idea someone must have already tried and quietly dropped. So instead of writing a blog post about the idea, we built the harness to actually test it, and the result is parmar — a subword-tokenization pre-filter for byte-level compressors, plus a fairly paranoid benchmarking rig to check whether the idea holds up at scale.

Short version: it works, but for a narrower reason than we expected, and the harness told us that just as clearly as it told us the headline number.

The hypothesis

Byte-level compressors like LZMA2 and zstd find repeated patterns inside a fixed-size sliding "dictionary window," measured in bytes. Our premise: if you replace UTF-8 prose with BPE token IDs — the same tokenization used to feed LLMs — before compressing, the token stream is roughly 45% smaller than the source text. A 64 MiB dictionary window that normally covers ~64 MB of prose can now cover roughly twice as much prose once that prose has been pre-shrunk.

The catch is that this only becomes testable once your corpus is bigger than the compressor's window. On a 5 MB file, everything already fits inside the window, so there's no expansion to measure and pre-tokenization buys you basically nothing. That's why a single ratio number on a small test file is close to meaningless here — what actually matters is the curve of (parmar ratio − raw-byte ratio) as corpus size grows, and whether that curve keeps climbing.

So that became the deliverable: not "does it compress smaller," but "does the advantage widen with scale, and if so, why."

What we actually built

parmar is two things bolted together:

The pipeline (parmar_core.py, parmar.py) — tokenize text with tiktoken, pack the token IDs (LEB128 or a fixed 2-byte width), and stream the result straight into an xz/zstd/gzip/bzip2 subprocess. Nothing is ever fully materialized in memory — chunks are read, tokenized, packed, and piped into the compressor's stdin, and its stdout is the archive.
The harness (matrix.py, run_cell.py, analyze.py) — a matrix runner that sweeps tokenizer × packing × backend × transport × chunking × threading, on a real corpus, across four size tiers.

The corpus is PG-19 (Rae et al., 2019's long-range-sequence-modelling dataset), built out to four tiers from 64 MB to 4 GB, about 10,600 documents. A literal cartesian product of every axis is on the order of 8,000+ valid cells per tier — weeks of runtime — so we split it into a 51-cell "ratio grid" that isolates the axes that actually move compression ratio, and a separate one-factor-at-a-time sweep for the axes that should only affect speed. Ratio is still logged on every OFAT cell too, so if a "speed-only" axis quietly moves the ratio, that shows up as a contradiction instead of getting averaged away.

Every single decompression is actually executed and checked against a sha256 written into the archive footer. If that check fails, the cell's ratio is thrown out and reported separately, not folded into the averages. Across 452 matrix cells: 452 verified round trips, zero failures.

What we found

The gap does widen with corpus size — but only for backends with a big enough window, and it plateaus. On gzip's tiny 32 KiB window, the +15% advantage is completely flat from 64 MB to 4 GB, because the window is already saturated at every tier — that's pure "denser representation," no window effect at all. On LZMA and zstd variants with multi-megabyte windows, the gap climbs from 64 MB up through roughly 1 GB and then flattens out once the corpus is well past the dictionary size. One backend, zstd --long with its 2 GiB window, was still climbing at the 4 GB tier — because 4 GB is only 2x its window, so it hadn't left that regime yet.

Having gzip in the matrix as a tiny-window control turned out to be the thing that separated two effects we'd originally lumped together: raw representation density (tokens are just a denser way to write English than UTF-8) versus window expansion (a smaller stream lets the same window cover more source text). Without that control we'd have credited window expansion for gains that were actually just density.

On bzip2, pre-tokenization is a flat loss (about -3.9%), at every corpus size. bzip2's Burrows-Wheeler transform is exploiting byte-level structure in the prose that tokenization destroys, so it's simply the wrong backend to pair this with.

It is usually not a size-for-speed tradeoff. On 5 of the 7 backends tested, parmar is smaller and faster than compressing raw bytes, at every tier, simultaneously — because the compressor is handed ~45% fewer bytes, and the time saved compressing them outweighs the time spent tokenizing. The two exceptions are informative rather than just noise: zstd at its fastest level is quick enough that tokenization itself becomes the bottleneck above a couple hundred MB, and bzip2 loses on both size and speed for the structural reason above.

Multithreading interacts with this in a way we hadn't anticipated. xz -T splits input into independent blocks once the stream is at least twice the dictionary size, and speedup tracks the resulting block count almost 1:1 until you run out of cores. Because pre-tokenization shrinks the stream fed to xz, it also shrinks the block count at a fixed block size — on a 1 GB corpus, raw bytes got 8 blocks and a 7.5x speedup from threading, while the tokenized version got 5 blocks and only 5x. So parmar was quietly giving up close to a third of the available multithreaded speedup in exchange for its ratio win, in the regime where block count sits below the core count. Interestingly, zstd's multithreading doesn't cost any ratio at all — it doesn't reset its window between jobs the way xz's independent blocks do, which is a concrete reason to prefer zstd if you need both threading and no ratio penalty.

One negative result we were happy to get: we'd built a hand-rolled worker pool (manual_pool) on the theory it might beat tiktoken's built-in batch tokenization. It won in exactly 8 of 16 comparable configurations — chance — with swings from -6.8% to +44% and no pattern by thread count, backend, or corpus size. Digging in, tiktoken's batch encode already releases the GIL and parallelizes internally in Rust, so there's no headroom left for Python-side coordination to claw back, and the swings we saw were mostly measurement noise on a step that only takes 1-3 seconds. The honest conclusion: the extra complexity isn't worth it, and we kept the negative result in the writeup instead of quietly deleting the code path.

Where this is actually useful

Grounded in the measurements rather than vibes:

Archiving large prose corpora with LZMA or high-level zstd — smaller archive, shorter compression run, no downside.
Anything stuck on gzip/deflate — the +15% gain shows up at every corpus size, including small ones, because gzip's window is always saturated. If you can't swap the compressor but can change what feeds it, this is the cleanest win in the whole project.
Text that's getting tokenized anyway — LLM training shards, eval sets, retrieval corpora — since a reader can skip re-tokenization on the way back out.
Cold storage, write-once/read-rarely — decompression carries a detokenization cost that compression doesn't, so the asymmetry favors data you don't read often.

And where it explicitly isn't a fit: it's untested on non-prose (code, JSON, logs), it's not a general-purpose archive format (the archive stores the tokenizer's name, not its vocabulary, so you need the exact same tiktoken encoding available to decompress), and it has no encryption or authentication — the sha256 in the footer is an integrity check, not a MAC.

Try it

python -m venv venv
./venv/Scripts/python.exe -m pip install tiktoken numpy zstandard psutil matplotlib pandas

# smoke test
python matrix.py smoke --corpus ./corpus/pg19_64mb.txt

# or run the whole programme end to end
bash run_all.sh

Full results, the matrix-generation logic, and FINDINGS.md (a running list of everything that turned out to be wrong once the code could actually be run — including a fun one about the PG-19 dataset no longer being loadable the documented way) are all in the repo:

github.com/shallowbyte/parmar

There's also an auto-generated code walkthrough on DeepWiki if you want to navigate the codebase rather than the results.

Open questions we'd like help on: sweeping dictionary size directly instead of corpus size (should isolate the plateau mechanism much more cheaply), frequency-remapping token IDs before packing to close the gap between LEB128 and the fixed-width packing on large-vocabulary tokenizers, and testing this on source code instead of prose. Issues and PRs welcome.

I turned my phone into a remote deck for my Windows laptop — no cloud, no accounts, one npm start

Ronak Parmar — Wed, 22 Jul 2026 15:52:01 +0000

It started with the dumbest problem in computing: I'm in bed, a movie is
playing on my laptop across the room, and pausing it requires physically
getting up.

Every existing fix annoyed me in some way. Remote desktop apps are overkill
and route through someone's cloud. Remote-control apps want accounts,
subscriptions, or a native app install. I just wanted my phone to poke my
laptop over my own Wi-Fi.

So I built LapDeck: one Node.js
process on the laptop, a PWA on the phone. Scan a QR code once and your
phone becomes an app launcher, touchpad, keyboard, live screen viewer, and
media/power remote. MIT licensed, plain JavaScript, no build step.

This post is about the four problems that turned out to be more interesting
than I expected.

The architecture in one line

Phone (PWA) ── WebSocket + MJPEG over Wi-Fi ──► Node.js agent (Windows)

The agent serves the PWA, exposes a WebSocket for commands, and streams the
screen as MJPEG. The protocol is deliberately dumb JSON envelopes — no
protobuf, no RPC framework — so a native Android client or a CLI script can
speak it in an afternoon. Windows-specific glue (volume, brightness, power,
capture) is isolated in src/win/, so a macOS/Linux port only has to
reimplement that layer.

Problem 1: mobile keyboards lie to you

The obvious way to build a remote keyboard is to listen for keydown and
forward key codes. On mobile, this collapses immediately: swipe typing,
autocorrect, and IME composition don't emit per-key events. Android will
happily tell you every key is keyCode 229.

The fix: stop listening to keys entirely. I keep a hidden input, and on
every input event I diff the field's value against the last known
state — compute the common prefix, then emit "delete N chars, type this
string" to the laptop. Swipe-type a whole word and the laptop receives one
clean text insertion. IME composition, autocorrect rewrites, emoji — all
just become diffs.

The lesson generalizes: on mobile web, treat the text field as the source of
truth, never the key events.

Problem 2: streaming a screen without WebRTC

I wanted live screen view with tap-to-click. WebRTC would be the "correct"
answer, but it drags in a signaling dance and a pile of dependencies for
what is fundamentally "pictures, quickly."

MJPEG turned out to be embarrassingly good for this. The agent runs a
capture loop (screenshots via nut.js, resize + JPEG encode via sharp) and
pushes frames as multipart/x-mixed-replace — a <img> tag on the phone
renders it natively, zero client code. Quality presets just change fps,
width, and JPEG quality.

Latency is fine for "tap where you want to click," but a raw MJPEG stream
makes the cursor feel laggy. So the phone renders its own client-predicted
cursor overlay on top of the stream — your finger drives a local cursor
instantly, and the real cursor catches up underneath. The perceived latency
of the whole feature is the latency of that overlay, not the stream.

Problem 3: the security model for "my phone can shut down my laptop"

Giving a web page on the network the power to inject input and kill your
machine deserves paranoia. The rules I settled on:

A 256-bit random token, generated on first run, embedded in the QR link. You scan once; the phone stores it. Every WebSocket command and the MJPEG stream require it. Comparison is constant-time.
First WebSocket message must authenticate within 3 seconds or the socket drops.
Feature switches are enforced server-side. If you disable screen view in settings, the agent refuses those commands — it doesn't just hide the button.
Destructive actions are opt-in and abortable. Sleep/shutdown/restart each need to be enabled in settings, require an explicit confirm flag, and shutdown/restart honor a grace period during which one tap aborts. (I have fat-fingered shutdown. The abort window has paid for itself.)

Transport is plain HTTP/WS, which is fine for a home LAN you trust — and
explicitly not fine for the open internet. Which leads to:

Problem 4: remote access without running a server

"Control your laptop from anywhere" usually means either port forwarding
(no) or somebody's relay cloud (also no). The answer that costs nothing and
required surprisingly little code: detect Tailscale.

If the agent sees a Tailscale interface, it prints a second "remote" QR and
the UI offers a one-tap switch to the tailnet URL. WireGuard gives you
end-to-end encryption, MagicDNS + tailscale cert gives you a real HTTPS
URL (which also makes the PWA installable from anywhere), and I run zero
infrastructure. Any VPN that puts your phone on your home network works —
Tailscale is just the zero-config path.

Things I deliberately didn't do

No TypeScript, no build step. Plain ESM on Node ≥ 20. Clone, install, run. Contributors can read every line that executes.
No Electron, no tray app. It's a console process; a PowerShell script installs a hidden autostart launcher into the Startup folder if you want it permanent (no admin needed).
No cloud component, period. There is nothing to sign up for, nothing that phones home, and the whole thing works with Wi-Fi and no internet.

Try it

Windows 10/11, Node ≥ 20, phone on the same Wi-Fi:

git clone https://github.com/ronak-create/LapDeck.git
cd LapDeck
npm install
npm start

Scan the QR, add to home screen, done.

Repo: https://github.com/ronak-create/LapDeck — the WebSocket protocol
is documented in docs/PROTOCOL.md if you want to build your own client.
macOS/Linux ports, multi-monitor support, and code roasts all welcome.

What's the laziest problem you've ever over-engineered a solution for?

pretty interesting stuff!!

Ronak Parmar — Wed, 22 Jul 2026 14:07:37 +0000

shekhar

Jul 22

I built a CLI so I'd stop typing ImageMagick flags wrong.

#cli #javascript #opensource #ai

2 min read

The project file is the interface: letting AI agents drive a video editor

Ronak Parmar — Thu, 09 Jul 2026 15:54:17 +0000

Last week I open sourced FableCut,
a Premiere-style video editor that runs in the browser and that AI agents can
operate. It hit the front page of Hacker News
(thread), and the questions
there made me realize the interesting part isn't the editor. It's one design
decision: the project file is the interface.

The usual way, and why I flipped it

Most AI video tools hide the edit behind an API. You call addClip(),
applyFilter(), and the tool owns the state. If you want a human to touch the
result, you build a whole collaboration layer.

FableCut does the opposite. The entire timeline lives in one JSON document,
project.json: media, clips, tracks, keyframes, transitions, markers. The
editor UI reads it. The export renders it. And anything that can write JSON
can edit video: Claude Code through MCP, a Python script, jq, or you with a
text editor.

{
  "id": "c_title", "kind": "text", "track": "V3",
  "start": 0, "duration": 2.2,
  "props": { "text": "HANDMADE", "font": "Bebas Neue",
             "glow": 45, "textAnim": "letter-pop" }
}

That clip is a glowing kinetic caption. There is no API call that creates it.
Writing it into the file IS creating it.

SSE as a doorbell, not a data channel

The first question on HN was "what's the benefit of SSE here?" Fair question,
because the SSE channel does almost nothing, and that's the point.

The server watches the project file with fs.watch, debounces 150ms, and
pushes the literal string change to the browser. No payload. The browser
re-fetches the project and re-renders. The whole mechanism is about 15 lines
on a bare node:http server.

Why not WebSockets? Because the data only flows one way. Everything that
writes (the UI, an agent, a shell script) goes through REST or the
filesystem. The browser only ever needs to hear "something changed, go look."
An event with no payload can't arrive out of order, and a missed event costs
nothing because the next fetch has the latest state anyway.

The revision counter, or: how a human and an agent share a timeline

The file carries an integer revision. Every write must bump it. If a write
arrives with a revision that isn't newer than what's on disk, the server
rejects it with a 409.

This one integer is the entire concurrency model. If I drag a clip in the UI
while an agent is mid-edit, the agent's stale write bounces, it re-reads,
re-applies its change on top of mine, and writes again. No operational
transforms, no CRDTs, no lock files. It works because edits are coarse
(a whole document) and rare (human speed), so last-writer-wins with a
staleness check is enough.

The trick I'm proudest of: frame-accurate CSS animations

FableCut has animated SVG overlays (lower thirds, confetti, sparkles) that
are plain .svg files animated with CSS @keyframes. The problem: a video
compositor needs to render the animation state at an exact time, and export
isn't realtime. You can't just let the animation play.

The solution: pause every animation and drive time by hand. The compositor
sets animation-delay: calc(var(--d, 0s) - t) where t is the clip's local
time. A negative delay means "you started in the past," so a paused animation
with delay -1.3s displays exactly its 1.3 second frame. Deterministic,
scrubbable, identical in preview and export. The only rule for SVG authors is
to never hardcode animation-delay and use the --d custom property for
staggering instead.

"You can just give Claude access to ffmpeg"

Someone said this on HN and it deserves a straight answer. For trims,
concats, and batch transcodes: yes, absolutely, do that.

The difference is the creative loop. ffmpeg is write-only. The agent builds a
filter graph, renders for minutes, and cannot see what it made. You give
feedback, everything re-renders. In FableCut an edit is a JSON diff, the open
browser updates in 150ms, and the timeline stays editable instead of being
baked into a filter string. It's not a replacement for ffmpeg anyway: the
export pipeline renders frames in the browser and pipes them to ffmpeg for
encoding. FableCut is the state and preview layer between the agent and
ffmpeg.

Honest limitations

The compositor is the browser, so export needs a browser open (headless
export is not there yet). It's Chromium-first. And an AI can misjudge a cut
just fine, which is why the human-in-the-loop part matters more than the AI
part: the agent does the labor, you do the taste.

Full disclosure since HN asked: Claude helped write the README, and large
parts of the editor were built in collaboration with it. That felt fitting
for a tool whose primary user is an AI agent, but the architecture decisions
above are the ones I'd defend in person.

Repo: https://github.com/ronak-create/FableCut. It's MIT, zero dependencies,
one node server.js. If you build something weird with it, I want to see it.

Why I Reimplemented 22 Unix Tools in Go for AI Agents

Ronak Parmar — Mon, 06 Apr 2026 14:12:20 +0000

I spent three weeks rebuilding ls, grep, cat, find, stat, diff, and 16 other Unix coreutils in Go. Not because the originals are broken — they're masterpieces of systems programming that have survived decades of use. I rebuilt them because AI coding agents are terrible at reading their output.

The Problem Nobody Talked About

Every time an AI agent runs ls src/, it receives something like this:

-rw-r--r--  1 user  staff  2048 Apr  6 12:00 main.go
drwxr-xr-x  3 user  staff    96 Apr  6 11:00 internal
lrwxr-xr-x  1 user  staff    12 Apr  6 10:00 link -> main.go

The agent has to figure out which column is the filename. Which is the size. Whether that d at the start means directory. Whether Apr 6 means this year or last year. It guesses. Sometimes it guesses wrong. And every wrong guess costs tokens, introduces errors, and degrades the quality of the code it writes.

Now multiply that by every grep, every cat, every find the agent runs in a single session. The token waste is staggering. The parsing fragility is a constant source of subtle bugs.

The Insight

AI agents don't need pretty terminal output. They need structured data. They need to know that main.go is 2048 bytes, was modified 3600 seconds ago, is written in Go, has MIME type text/x-go, and is not a binary file. They need this information labeled, unambiguous, and machine-readable.

So I asked: what if ls returned XML?

<ls timestamp="1712404800" total_entries="3">
  <file name="main.go" path="src/main.go" absolute="/project/src/main.go"
        size_bytes="2048" size_human="2.0 KiB"
        modified="1712404800" modified_ago_s="3600"
        language="go" mime="text/x-go" binary="false"/>
  <directory name="internal" path="src/internal"/>
  <symlink name="link" target="main.go" broken="false"/>
</ls>

Zero ambiguity. Zero parsing. The agent reads the attributes and knows exactly what it's looking at. No regex to extract filenames from column-aligned text. No heuristic to determine if something is a directory. No guesswork.

Why XML and Not JSON?

Good question. JSON is the lingua franca of APIs. But XML has a structural advantage that matters for AI context windows: attributes.

Compare these two representations of the same file:

<file size_bytes="2048" language="go" mime="text/x-go"/>

{"size_bytes": 2048, "language": "go", "mime": "text/x-go"}

The XML version is 40 characters. The JSON version is 60. That's a 33% difference. When you're listing 1,000 files, that's tens of thousands of tokens saved. AI context windows are expensive and limited. Every character counts.

That said, aict supports --json for every tool. The schema is identical. Use whatever your pipeline prefers.

Why Go?

Three reasons:

Single binary. Go compiles to a static binary with zero runtime dependencies. aict is one file you drop on a system and it works. No pip install, no npm install, no shared libraries to manage. For a tool that's supposed to replace coreutils, this is non-negotiable.

Standard library only. Every feature — regex matching, MIME detection, filesystem walking, XML encoding — uses Go's standard library. Zero external dependencies means zero supply chain risk, zero version conflicts, and the ability to audit the entire codebase in an afternoon.

Performance is good enough. Yes, aict grep is slower than ripgrep. Yes, aict ls is slower than eza. But we're talking 15ms vs 2ms for listing 1,000 files. The overhead comes from language detection, MIME sniffing, and structured output — features that are the entire point of the project. For normal codebases, the difference is imperceptible.

What I Built

Twenty-two tools across five categories:

File inspection: cat, head, tail, file, stat, wc
Directory & search: ls, find, grep, diff
Path utilities: realpath, basename, dirname, pwd
Text processing: sort, uniq, cut, tr
System & environment: env, system, ps, df, du, checksums

Plus a git subcommand suite (status, diff, log, ls-files, blame) and an MCP server that exposes every tool as a callable function to AI assistants like Claude and Cursor.

Every tool supports three output modes: XML, JSON, and plain text. Every error is structured data in stdout, never stderr. Every path is absolute. Every timestamp is a Unix epoch integer.

The MCP Server

This is where it gets interesting. aict ships with an MCP (Model Context Protocol) server binary called aict-mcp. You configure it in Claude Desktop or Cursor, and suddenly every tool becomes a typed, callable function.

The AI agent doesn't shell out to run aict ls src/. It calls the ls function with {path: "src/"} and receives structured JSON. No shell spawning. No output parsing. No ambiguity.

This is the future of how AI agents interact with filesystems. Not by typing commands into a terminal and reading the output like a human would. By calling typed functions and receiving typed responses.

What I Didn't Build

I intentionally excluded write operations: cp, mv, rm, mkdir, chmod, chown. These are dangerous when called by AI agents without human confirmation. aict is a read-only tool. It observes, it doesn't modify.

I also didn't try to match GNU coreutils flag-for-flag. Where a flag made sense for the AI use case, I added it. Where it didn't, I skipped it. The goal is not compatibility — it's utility for AI agents.

The Honest Benchmark

I benchmarked aict against GNU coreutils. Here are the results:

Tool	GNU	aict	Ratio
`ls` (1,000 files)	~2ms	~15ms	7×
`grep` (100k lines)	~1ms	~100ms	100×
`find` (deep tree)	~2ms	~9ms	5×
`cat` (100k lines)	~1ms	~23ms	17×
`diff` (1,000 lines)	~1ms	~10ms	10×

grep and cat are slow because every file is MIME-typed and language-detected. Use --plain to skip enrichment when you only need content. The trade-off is intentional: more tokens spent on parsing vs. more semantic information returned.

Is This Actually Useful?

I've been using aict with Claude and Cursor for two months. The difference is noticeable. The agent makes fewer mistakes about file types. It doesn't confuse directories with files. It correctly identifies binary files before trying to read them. It understands the structure of a codebase faster.

The token savings are real. A directory listing that used to cost 2,000 tokens in plain text now costs 800 in XML with three times the information density. Over a typical coding session with dozens of tool calls, that adds up.

Open Source

The project is MIT licensed and on GitHub. It's written in Go with zero external dependencies. You can audit the entire codebase in an afternoon. I'd love contributions — new tools, performance improvements, bug fixes.

If you build AI agents that interact with codebases, give it a try. Your agent will thank you. And if it doesn't work for your use case, that's fine too. GNU coreutils aren't going anywhere.

The repo is at github.com/synseqack/aict.

I got tired of configuring the same stack over and over, so I built a modular project assembler

Ronak Parmar — Wed, 25 Mar 2026 13:26:48 +0000

Every side project I started followed the same ritual.

Find a starter. Clone it. Realize it doesn't have the exact
combination I need — say, Next.js with Express as a separate
backend, PostgreSQL, JWT auth, and Tailwind. Start adding things.
Watch the tsconfig break. Spend 45 minutes on Stack Overflow.
Finally start actually building at 11pm, mentally exhausted.

I did this enough times that I started keeping a folder of
"my personal starters." Which worked until I had six of them and
they were all slightly different and none of them had the latest
versions of anything.

So I built Foundation CLI instead.

What it is

Foundation CLI is a dependency-aware project assembler. You describe
your stack — frontend, backend, database, auth, UI, deployment — and
instead of copying static template files, it:

Resolves the full module dependency graph
Detects and handles conflicts automatically
Merges configs intelligently (deep merge for package.json, key-dedup for .env, semver intersection for requirements.txt)
Commits everything atomically — or not at all

npx @systemlabs/foundation-cli create

The part that was interesting to build

The dependency resolver was the core challenge. Modules don't
conflict by name — they conflict by capability. "Auth JWT" and
"Auth OAuth" are different implementations of the same capability.
The resolver uses capability tokens, not module IDs, to detect this.

Then it runs Kahn's algorithm to build a topological sort of the
module execution order — because if Tailwind needs to run after
Next.js (to patch the config correctly), that dependency needs to be
explicit and enforced.

Conflicts come in two tiers:

Hard conflicts — two auth modules, two frontends. Block the entire scaffold.
Advisory conflicts — Express + Cloudflare Workers (Express doesn't run on the edge). Warn, but don't block.

The config merge problem

This is the part that template copiers get wrong. When you add
Tailwind to a Next.js + Express project, three different files need
to change:

package.json — new devDependencies
tailwind.config.js — new file
globals.css — Tailwind directives
Possibly next.config.mjs — PostCSS config

A static template can't do this. You either have a template per
combination (exponential), or you have a module system that knows
how to merge.

Foundation CLI's merge engine handles this per file type. JSON files
get deep-merged with conflict detection. .env files get
key-deduplicated. docker-compose.yml gets service-merged.
requirements.txt gets semver-intersected.

Zero partial scaffolds

Every write goes through a FileTransaction. Files are staged to a
temp directory. If anything fails — a template render error, a
missing dependency, a hook failure — the temp dir is deleted and
the output directory is left completely untouched.

You either get a complete, working project or you get nothing. No
mystery half-generated directories.

What's in it

28 built-in modules across 7 categories
8 project archetypes (SaaS, AI App, E-commerce, API Backend, etc.) with pre-filled smart defaults
Plugin SDK — third-party modules publish to npm with foundation-plugin keyword
TypeScript throughout, strict mode, all generated projects pass tsc --noEmit

Try it

npx @systemlabs/foundation-cli create

Repo: https://github.com/ronak-create/Foundation-Cli

I'd love feedback — especially if you've built something similar
and solved the config merge problem differently. The current
approach works but I'm not convinced it's the best design.

Open-sourcing Foundation CLI — a dependency-aware project scaffolding tool

Ronak Parmar — Mon, 16 Mar 2026 10:06:11 +0000

I’ve been experimenting with a CLI tool for my own workflow that tries to simplify starting new projects.

The idea is that instead of manually wiring frameworks, databases, auth, etc., you describe the stack you want and the CLI generates the project structure.

For example something like:

"I want a SaaS with Next.js, Express, PostgreSQL and JWT auth"

The tool resolves dependencies, merges configs, and sets up the integration code automatically.

I'm curious if people here actually find tools like this useful, or if most devs prefer starting projects manually.

Would love to hear how others approach bootstrapping new projects.

Github

DEV Community: Ronak Parmar

I Ran a 284B-Parameter LLM From 3.2GB of RAM — in Plain C

The trick that makes this possible at all

Why I didn't trust it until I could prove it

The optimization that was actually silent corruption

A 30x slowdown with the wrong explanation

Thermal state matters more than I expected

The --budget flag is the one that actually matters

Trying it yourself

What's still open

What I'd tell someone doing something similar

We tested "tokenize before you compress" against 452 configurations, and it mostly held up

The hypothesis

What we actually built

What we found

Where this is actually useful

Try it

I turned my phone into a remote deck for my Windows laptop — no cloud, no accounts, one npm start

The architecture in one line

Problem 1: mobile keyboards lie to you

Problem 2: streaming a screen without WebRTC

Problem 3: the security model for "my phone can shut down my laptop"

Problem 4: remote access without running a server

Things I deliberately didn't do

Try it

pretty interesting stuff!!

I built a CLI so I'd stop typing ImageMagick flags wrong.

The project file is the interface: letting AI agents drive a video editor

The usual way, and why I flipped it

SSE as a doorbell, not a data channel

The revision counter, or: how a human and an agent share a timeline

The trick I'm proudest of: frame-accurate CSS animations

"You can just give Claude access to ffmpeg"

Honest limitations

Why I Reimplemented 22 Unix Tools in Go for AI Agents

The Problem Nobody Talked About

The Insight

Why XML and Not JSON?

Why Go?

What I Built

The MCP Server

What I Didn't Build

The Honest Benchmark

Is This Actually Useful?

Open Source

I got tired of configuring the same stack over and over, so I built a modular project assembler

What it is

The part that was interesting to build

The config merge problem

Zero partial scaffolds

What's in it

Try it

Open-sourcing Foundation CLI — a dependency-aware project scaffolding tool

The `--budget` flag is the one that actually matters