DEV Community: cuculhart

I built a cell-less spreadsheet where you count by enclosing — free, runs in your browser

cuculhart — Tue, 13 Oct 2026 11:11:28 +0000

I built Sethera Piece — a calculation board with no cells. You drop
text and number "pieces" anywhere on a canvas, draw a zone around them,
and it aggregates them live. MIT-licensed, fully local, and it runs in
your browser with no install.

Repo: https://github.com/cuculhart/sethera-piece
Live demo: https://cuculhart.github.io/sethera-piece/

The idea

A lot of what people do in Excel isn't actually spreadsheet work. We
use cells as graph paper: laying out forms, sticking notes, summing
things by hand. The grid is a constraint the job never asked for.

Sethera Piece removes the grid entirely. Objects live anywhere. If you
want a total, you draw a zone around the pieces — spatial layout is
the formula.

What it feels like

Pieces — text / number / sticky-note+number. Multi-line, alignment, colors, sizes, borderless display.
Σ zones — aggregate enclosed pieces with Sum / Count / Avg / Max / Min. Drag a piece in or out and every zone's total updates instantly. A piece that only partially overlaps a zone gets a red dashed warning so it can't silently escape aggregation.
Calc pieces — + − × ÷ with rounding modes. Wire a zone's output handle into a calc's inputs and you get chains like subtotal × tax rate → total with zero syntax.

The screenshot above is a US-style estimate built on an A4 paper
frame: the AMOUNT column sits inside a Σ zone (subtotal 4,800), a tax
piece and the zone feed a calc piece that shows the total (5,196).
Printing/PDF export captures the paper frame.

Color = category (SumIf / CountIf)

The 1.0 feature I'm happiest with: pick a zone, choose a piece color
in the inspector, and only pieces of that color are counted. Eight
usable colors = eight categories. To mark items, multi-select them
and batch-change the color — that's the whole workflow. No label
matching, no strings to typo.

Everything else in the box

Lines, rects, ellipses, arcs, curves, diagonals — table frames, flowchart connectors; grid snapping makes adjacent edges land exactly
Custom pieces — group any combination into a reusable unit; template library saves named selections across documents
CSV/TSV round-trip with Excel — paste a range or import a file (auto-detects UTF-8/UTF-16/Shift_JIS/EUC-JP); number columns become number pieces that aggregate immediately
Paper & print — A4/B5/A3 portrait/landscape, print/PDF capture
Fonts — bundled Noto Sans JP / Shippori Mincho / BIZ UDP Gothic / monospace, or a custom font name with a missing-font warning
Japanese / English UI — toggle in one click, auto-detects from the browser
Fully local — localStorage + JSON files only. Nothing is sent anywhere. No telemetry

Why the name

"Sethera" comes from Yan Tan Tethera, a counting rhyme shepherds
in northern England used to tally sheep — probably one of humanity's
oldest aggregation functions. Enclosing pieces to count them is the
modern version.

(The other image in my head: a general moving pieces on a sand table.
Move a piece and the situation changes — a board that recalculates
when you move it.)

Tech stack

React 19 + TypeScript + Vite, canvas on
@xyflow/react (React Flow, MIT).
I picked React Flow over tldraw because tldraw's license charges for
production use; React Flow is MIT. The aggregation core is just
rect-containment + a filter predicate — the spatial model does the
rest.

Honest limitations

Single-player. Real-time collaboration is still only an idea on the
drawing board — the local-first version comes first. Editing is
mouse-first; a phone can view but won't enjoy it.

License

MIT. Feedback and issues welcome:
https://github.com/cuculhart/sethera-piece/issues

Tokens arrived on time — the renderer didn't: measuring a 90x display lag in local-LLM streaming (and how Ollama fixed it)

cuculhart — Sun, 11 Oct 2026 01:48:08 +0000

I built a local-LLM coding IDE, and I noticed something odd: giving
the model all the CPU cores made the app feel slower. Tokens
were arriving at the same speed, but the UI lagged behind. So I
measured it — and then, mid-verification, a new Ollama release
changed the whole story.

TL;DR — On Ollama 0.21.0, running inference on all 6 cores vs. 4
produced the same token rate but 90x worse display lag (P95 181ms →
2ms) and 6x worse UI click response (929ms → 158ms). On Ollama
0.40.2 the gap nearly vanished, because the runner internals changed.
I shipped the thread-cap setting anyway — here's why.

What I actually wanted to measure

Not generation speed. API tok/s is easy to measure, but my question
was "how fast does what the API returned get onto the screen?"

Hypothesis: with all cores allocated, the LLM saturates the CPU, the
renderer is starved, and incoming tokens can't be painted in time.
With fewer cores, generation speed is nearly identical but the display
stays smooth — so it feels faster.

To quantify "feel," I split the clocks:

Wire arrival time — a thin proxy between the IDE and Ollama timestamps every NDJSON chunk. Accurate even when the renderer is starving.
DOM render time — a MutationObserver records streaming text length over time, giving per-chunk arrival→paint lag.
Event-loop delay — drift of a 100ms setTimeout.
Effective FPS — requestAnimationFrame fire count.
UI click probe — actually clicking a real UI button during generation and timing the response.
Fixed conditions — temperature 0, fixed seed, num_predict 600, think: false.

Environment: Ryzen 5 4500U (6 logical cores), CPU inference, Windows.
Compared "all cores" vs "4", median over a 60s window. The harness is
e2e/bench-threads.mjs (Playwright + measurement proxy) in the
repo.

Part 1: Ollama 0.21.0 — same speed, 90x more invisible

Metric	All 6 cores	4 cores
Wire-arrival speed (≈ generation)	4.6 chars/s	4.7 chars/s
Display lag P95 (arrival→DOM)	181 ms	2 ms
Display lag Max	553 ms	6 ms
Event-loop delay P95	70 ms	13.6 ms
Effective FPS	55.9	60.0
UI click response (real click)	929 ms	158 ms

Three takeaways:

Generation speed was identical — decode is memory-bandwidth bound, so cutting 6→4 threads didn't slow token production.
Display lag diverged ~90x at P95 — on all cores, tokens waited up to half a second to appear. Streaming output "backs up."
One UI click took 929ms vs 158ms (~6x) — a proxy for "can you still do light work while the LLM runs."

On the old engine the runner occupied ~5.7 cores continuously during
generation. "4 cores feels faster" wasn't an illusion — it existed as
real delay in the display pipeline.

Part 2: Ollama 0.40.2 — I upgraded, and the premise changed

Before publishing, I wondered "isn't 0.21.0 old?" and re-ran on
0.40.2. The gap nearly disappeared:

Metric	num_thread=6	num_thread=4
Wire-arrival speed	7.6 chars/s	7.5 chars/s
Display lag P95	13 ms	3 ms
Event-loop delay P95	14.2 ms	13.9 ms
Effective FPS	59.9	59.9
UI click response	123 ms	114 ms

Same story on a 9.6GB model (lagP95: 5ms vs 3ms). Inspecting the
runner process showed why:

	Ollama 0.21.0	Ollama 0.40.2
Runner	`ollama runner` (old engine)	`llama-server` (llama.cpp)
Threads, unspecified	all cores (=6)	n_threads=3 (measured)
Actual CPU at num_thread=6	~5.7 cores saturated	~4.3–4.6 cores, no saturation

The default changed: unspecified now means 3 threads — it never grabs all cores in the first place.
Even explicit num_thread=6 doesn't saturate — decode is memory- bound and the new engine's threads simply wait instead of spinning.
Headroom exists now: 1.5–2 spare cores at all times, so the renderer/OS/other apps can preempt. UI starvation doesn't happen.
Prefill behaves the same way — UI response stayed 90–180ms during prompt processing.

The "all cores make it stutter" experience was a real property of the
old engine's design, and the new engine fixed it internally.

So is a thread cap useless? Not quite

Two reasons to keep the setting:

Guarantee, not tuning. Engine internals change per version — the unspecified default moved 6→3 in one release. num_thread is an explicit ceiling that stays put regardless of version, model, or whatever else is running on the machine.
API reach. The option only exists on Ollama's native /api/chat.

Bonus finding: the "thinking" switch

While measuring, I noticed the model (qwen3.5:4b, a thinking model)
produced a long reasoning trace — input analysis, greeting candidates,
style polish — before answering a plain "hello." On a modest PC that
trace alone costs tens of seconds to minutes. Ollama's native API has
a think flag; think:false suppresses it (verified: zero
pre-content chunks in our runs). For practical local-LLM speed it's as
effective a switch as the thread cap.

Where this becomes a tooling difference

Here's the part that turned this into a product feature: these
options only exist on Ollama's native /api/chat.

What you want	Ollama `/api/chat`	OpenAI-compatible `/v1`
Cap CPU cores	`options.num_thread`	No way to pass it
Thinking on/off	`think`	No way to pass it
Output length / seed	`options.*`	Partially

Most VS Code-extension agents don't expose "CPU core count for local
LLM" as a setting — with an OpenAI-compatible client there's simply no
channel to send it through. To run a local LLM without killing the
host PC, you need a design that reaches the native API's options.

I shipped this in Teaspoon IDE v1.2.0 — a free, standalone
Electron AI coding IDE I maintain — as "CPU Threads" and "Thinking"
settings, plus the IDE's Ollama path moved to /api/chat. It's BYOK
(bring your own Gemini key) or fully offline via Ollama, and
source-available under FSL-1.1-MIT.
Product page: https://cuculhart.com/teaspoon.en.html

Lessons

tok/s explains only half the experience — same generation speed, but starved rendering changed perceived speed by a measured 90x.
"Use everything" isn't always optimal — and "how much to use" depends on engine internals that change between versions.
Re-verify on the latest environment — re-testing on the new release showed the phenomenon was engine-dependent, which made the article stronger, not weaker.
UI responsiveness is measurable — split wire time and DOM time, and "feels slow" becomes a number.
Local-LLM features are bounded by API reach — a design limited to the compatibility API's common denominator can't implement num_thread or think.

Methodology: harness e2e/bench-threads.mjs, raw data in
e2e/bench-threads-results.json — reproduce with
BENCH_THREADS=6,4 BENCH_RUNS=3 BENCH_MODEL=qwen3.5:4b node e2e/bench-threads.mjs.
n=2–3 on a single Ryzen 5 4500U, so treat the exact numbers as
one-machine data; the measurement method is the reusable part.

I built a free, BYOK AI coding agent IDE that runs fully offline on local LLMs

cuculhart — Wed, 23 Sep 2026 08:33:21 +0000

I built Teaspoon IDE, a standalone Electron app that bundles a file
explorer, Monaco editor, AI chat, Git, and a real TTY terminal into one
window — with an agent loop that lists, reads, searches, and edits
files across multiple steps, all behind approval dialogs.

Repo: https://github.com/cuculhart/teaspoon-ide
Setup guide: https://cuculhart.com/teaspoon-howto.en.html

Not a VS Code fork, not an extension — a single exe.

Why I built it

Doing contract work, I kept hitting the same walls:

Confidential code can't go to vendor clouds. In contract work you handle code and engineering knowledge that simply may not pass through someone else's servers.
Orgs that can't approve $20/mo subscriptions. There are still plenty of organizations where a monthly AI IDE subscription is a hard sell.
VS Code extension agents get tangled. Extensions are convenient, but they also collide with each other — Copilot interference being the usual suspect.
Unapproved rewrites are a review burden. When the AI silently rewrites code, the human reviewer pays the cognitive cost. So every write, diff edit, and command goes through an approval dialog, and checkpoint/rollback undoes only the AI's changes.
Docker-in-Docker tools are heavy. Nice, but a hard setup for beginners. I wanted a single exe that just runs.
Beginners need visible panes. Explorer, editor, console, and AI chat as separate, obvious panes is simply easier to learn.

Nothing matched all of this — so I built it, with AI, in under 3 days.

Features

Free + BYOK — bring your own Gemini API key, pay Google directly for what you use. No subscription, no markup.
Fully offline option — point it at Ollama (Gemma, Qwen, ...) and every request goes to localhost only. Your code never leaves the machine.
No telemetry — the only network calls go to the LLM endpoint you configure. Source-available, so you can verify that yourself.
Human-in-the-loop — writes are confined to the project root; file creation, diff edits, and shell commands all require approval.
LiteLLM proxy support — real API keys never sit on the client.
Token-efficient context — the AI gets the file tree and fetches contents on demand via // GREP: / // READ_FILE: commands.
Cheap by default — Gemini 3.8 Flash is at introductory pricing (half the standard rate) through the end of 2026, and even cheaper models like 3.5 Flash-Lite are selectable.

Tech stack

Electron / React / TypeScript / Monaco Editor / Gemini API & Ollama /
Vite

License

FSL-1.1-MIT (source-available). Free to use, modify, fork, and
redistribute for any non-competing purpose — including commercial work
inside your company. The one restriction: you can't sell it (or a
renamed clone) as a competing product. Each release automatically
converts to MIT two years after publication.

Honest limitations

It's chat/agent-centric (no inline completions), there's no codebase
index (tree + on-demand reads instead), editor tabs don't exist yet,
and it's Windows-first with the UI in English/Japanese.

Roadmap

Considering PDF/image recognition, making the agent loop more reliable
on small local models, and chat improvements (multiple chat tabs).

Feedback and bug reports welcome via
GitHub Issues.