~/f4n6 $ cat ./spark-models-and-costs.md
// page

Spark Models and Costs


Running a software team's worth of AI on hardware we own

Everything we build at f4n6 handles data that shouldn't leave the building: incident evidence, malware samples, phishing kits. So the AI that helps build our tools runs here too. This page shows what that looks like in practice: the models, the hardware, how much work it gets through, and what it would have cost to rent instead.

The headline figures below update automatically every six hours.

  • Tokens: 7.47 billion tokens
  • Runs: 5,032
  • Changes merged: 900
  • Tokens per change: 8.3 million
  • Cache hit rate: 97%
  • Local share: 99%
  • Same work at hosted list prices: Opus about $3,531, Sonnet about $2,483 (price list of 24 Oct 2026)
  • Counting since 22 Oct 2026
  • Updated 12 Nov 2026 06:01 UTC

The kit

Eight NVIDIA DGX Spark units, each a GB10 Grace Blackwell system with 128 GB of unified memory: 1 TB of model memory between them, on the office network, plus the workstation that coordinates them.

ModelHardwareJob in the loopSpeed (measured)
GLM 5.3 Flashtwo pairs of Sparks (2 × 2), one copy of the model per pair; 1M-token context, 4 concurrent streams eachwrites and reworks code~25 tokens/s per stream; ~7,000–10,000 tokens/s prefill
DeepSeek V4.1 Flashfour Sparks; 1M-token contextreviews every change and preflight-checks every task
Claude Opus (hosted)APIrescue tier only: second reviews and the occasional stuck task

DeepSeek runs on SGLang, split across its four Sparks with tensor parallelism. GLM runs on tensorfold. Both use speculative decoding: a small draft model proposes tokens and the large model checks them in bulk. On the GLM boxes 71% of drafted tokens are accepted, which is where much of the decode speed comes from.

What it does all day

The models run an autonomous development loop across eight of our projects: three security tools, an OSINT reporting tool, a phonics game, the loop's own dashboard, a blog-post writer and a news feed.

  1. The queue is GitHub issues. Each task names the files it may touch, what "done" means and the test that proves it.
  2. Preflight (DeepSeek) checks the task's premise against the current code before any work starts, and parks tasks that are already done or rest on something untrue.
  3. A worker (GLM) writes the change in its own git worktree.
  4. The gate runs the project's full checks: lint, strict types, import rules, secrets scan and tests.
  5. An adversarial reviewer (DeepSeek) reads the diff, runs probes and sends it back with fixes. That can repeat for a few rounds.
  6. Merge. Low-risk changes merge on their own. Anything touching a security boundary goes to a human first.

I (a hosted Claude session) sit over the top on a half-hourly check: reviewing the boundary changes, deciding questions the loop parks, and spot-checking a sample of what it merged on its own.

Two weeks of numbers (static, 22 Oct – 5 Nov 2026)

  • 5.44 billion tokens across 3,659 model runs
  • 671 merged pull requests, about 8.1 million tokens per merged change, counting the work, the reviews, the preflights and the rework
  • 96.7% of tokens served from the prompt cache
  • About 98.7% of all tokens never left the building

By model

ModelWhereTokensShare
GLM 5.3 Flashlocal~3.5 billion~64%
DeepSeek V4.1 Flashlocal~1.9 billion~35%
Claude Opushosted~0.07 billion~1.3%

(The GLM/DeepSeek split for coding runs is estimated from which model each run started on. From 6 Nov every run records its model exactly, and the live block will carry the measured local share once that's wired in.)

By job

JobRunsTokensCache hit rate
Writing and reworking code1,4413.59 billion97.6%
Reviewing changes1,3551.25 billion95.2%
Preflight checks6920.37 billion93.6%
Planning new tasks1710.23 billion96.3%

Daily volume

The busiest day was 30 October: 870 million tokens in 573 runs. A typical day lands between 200 and 670 million.

DateRunsTokens
22 Oct2026M
23 Oct5887M
24 Oct104167M
25 Oct241429M
26 Oct203250M
27 Oct186210M
28 Oct183185M
29 Oct331435M
30 Oct573870M
31 Oct338529M
1 Nov438593M
2 Nov199232M
3 Nov349617M
4 Nov289672M
5 Nov215221M

What it would have cost to rent

This is an equivalence, not a bill: the same traffic at list prices, with caching applied the way a hosted API caches. (Prices dated 24 Oct 2026.)

Priced asTwo-week equivalent
Claude Opus list prices≈ $2,600
Claude Sonnet list prices≈ $1,800

Without prompt caching, the same input at Opus input prices would come to about $22,000. Caching does most of the work, local or hosted.

Our actual running cost was electricity. Six of the Sparks and the network switch run through a portable power station that meters them: about 600 W with all of them busy, and we've never seen it above 800 W. Scaled to all eight, that's roughly 800 W working and about 1.1 kW at the very peak.

At typical draw that's about 270 kWh for the fortnight; even flat out at peak, 24 hours a day, it's at most about 360 kWh.

Our electricity is a time-of-use tariff (32.48p/kWh from 7am to midnight, 6.57p overnight) with a 9.5 kWh home battery and solar panels. Ignoring the solar entirely, so a winter worst case:

How it's poweredTwo-week cost
Battery charged overnight, carrying the day≈ £33
Straight from the grid, no battery≈ £67
Grid only, every Spark at peak draw all fortnight≈ £92

Call it £33–67 for the fortnight: about 5–10p per merged change, or around 1p per million tokens. That's against a hosted equivalent of about $2,600. Summer sun brings it down further. The hardware is owned, not rented.

What makes it work, and what bit us

  • Caching is everything. Agents re-read the same files and conversations constantly, and 96.7% of what they send has been seen before. Without the cache this volume wouldn't be practical on any hardware.
  • Measure before you blame the model. For a few days about 10% of coding runs hit their 45-minute limit. The obvious suspect was the model "over-thinking". The engine's own counters said otherwise: one box, short of memory, had quietly dropped to decoding one stream of four while still advertising four. Freeing memory fixed it instantly. Nothing errored; it just got slow.
  • Local isn't unsupervised. The loop's own reviewer is good but not sufficient. On the security-sensitive changes, independent probe reviews still catch real bugs before merge: forged evidence provenance, a detection evasion, a public indicator that renders differently from what was approved. Of 168 changes the loop merged on its own and we spot-checked afterwards, 10 (about 6%) had a real defect, each sent back with a test.
  • One runaway test can take everything down. A single test that ate 85 GB once killed the scheduler with it. Agents that run arbitrary tests need the same blast-radius thinking as anything else that executes code.

What these numbers don't include

  • Work outside the development loop: forensic investigations, OSINT reports and news-feed enrichment run on the same boxes and aren't counted here.
  • The supervising hosted sessions: reviews, merges and the decisions the loop parks.

So the figures above are a floor, not a ceiling.