DEV Community: Tommy Leonhardsen

Your Intel Laptop Can Run 30B Models Now. No NVIDIA. No Cloud. No Problem.

Tommy Leonhardsen — Fri, 07 Aug 2026 10:00:00 +0000

In April I wrote that your Intel laptop can run LLMs. That post was about 8B models — good little assistants, honest about their limits, the kind of model that answers your question and doesn't architect your microservices.

This post is about running a 30B model on the same laptop. Interactively. And then, because being from Northern Norway means being apparently incapable of leaving a thing alone, about running a 74 GB model on a desktop with 64 GB of RAM.

That last sentence is not a typo. Hold it. It is the entire plot.

The trick is that big models stopped being big

The new generation of local models are Mixture-of-Experts: Qwen3-30B-A3B has 30 billion parameters, but only 3 billion activate for any given token. The other 27 billion sit there being knowledge — consulted occasionally, like a reference library, not read cover to cover for every word.

This changes the economics completely. Decoding speed on consumer hardware is a memory-bandwidth game, and an A3B model only moves the active experts through memory per token. You pay small-model speed for big-model knowledge.

OpenVINO 2026.3 shipped the plumbing to exploit this on Intel hardware, and the release notes were their usual understated selves about it. We spent two days measuring what they actually delivered, across a Lunar Lake laptop (Arc 140V iGPU + NPU), a desktop Core Ultra 9 285K, and — for perspective — an RTX 5090.

Some of it is genuinely impressive. Some of it is a silent no-op unless your GPU has one specific hardware feature nobody documented. Both halves are below, with numbers.

Part one: the NPU still needs a secret handshake

First, housekeeping from the smaller end. OpenVINO 2026.3 added NPU support for the new small models — SmolLM3-3B, LFM2, LFM2.5. This is true. What the release notes don't say is that if you convert these models yourself with the obvious command, the NPU driver compiler crashes:

[vpux-compiler] StopLocationVerifierPass Pass failed :
Found 364 duplicated names after full verification

That is not your fault. It is a known compiler bug with group-quantized INT4, and the fix is to quantize channel-wise instead:

optimum-cli export openvino --model HuggingFaceTB/SmolLM3-3B \
  --weight-format int4 --group-size -1 --sym --ratio 1.0 <output>

NoLlama's download-model.ps1 now has this as -Weight int4-cw, so you don't have to remember it. And because nobody had published OpenVINO builds of these models at all, we did — they're on HuggingFace with measured numbers in the cards:

Model	NPU decode (285K)	Link
SmolLM3-3B int4-cw	23.3 tok/s	aweussom/SmolLM3-3B-int4-cw-ov
SmolLM3-3B int8-cw	12.3 tok/s	aweussom/SmolLM3-3B-int8-cw-ov
LFM2.5-1.2B int4-cw	38.8 tok/s	aweussom/LFM2.5-1.2B-Instruct-int4-cw-ov
LFM2-1.2B int4-cw	36.5 tok/s	aweussom/LFM2-1.2B-int4-cw-ov

Do not try int8 on the LFM models. Symmetric int8 compiles and runs fast and produces BY-AL-AN-AN-AN-AN forever. Asymmetric int8 produces correct English at 1.4 tokens per second. We measured both so you never have to.

Part two: the disk offload feature, and the hardware gate nobody mentions

The headline 2026.3 feature: MoE expert weights can now be streamed from disk instead of held in GPU memory. OFFLOAD_RATIO=50 means half your experts live on SSD and get fetched through an LRU cache. The release notes say this lets "30B MoE models like Qwen3-30B-A3B run even on devices with 16 GB of memory."

We spent a full day failing to make this do anything on a desktop iGPU. Every ratio, every model, every export vintage. Identical memory usage, identical speed, no warning, no log line, nothing.

The answer was one line in the OpenVINO source:

// Gated on supports_immad (systolic-only) and oneDNN
if (device_info.supports_immad && config.get_use_onednn() && ...)

The entire MoE offload path requires XMX — the systolic matrix hardware in Arc GPUs, Lunar Lake, and newer. Desktop Arrow Lake and Meteor Lake iGPUs don't have it, and on those the feature is a silent no-op. Not "slow". Not "unsupported, error". Silent.

Check your own machine in one line:

import openvino as ov
print(ov.Core().get_property("GPU", "OPTIMIZATION_CAPABILITIES"))
# GPU_HW_MATMUL in the list = you're in business

NoLlama's installer now prints this verdict at device detection, and the server warns at startup if you ask for offload on a GPU that will ignore you. Nobody should size their model plans around a feature their silicon doesn't have.

Part three: on the right hardware, it actually works

On the Arc 140V laptop (which has XMX), the same feature that no-ops on the desktop delivers exactly what Intel promised. Qwen3-30B-A3B INT4 — a 15.2 GB model on a GPU with an 18 GB memory budget:

`--offload-ratio`	Resident GPU memory	Steady-state decode
30	10.8 GB	25.3 tok/s
50	8.1 GB	22.1 tok/s
90	2.35 GB	5.1 tok/s

Twenty-five tokens per second is interactive. It matches a 24-core desktop CPU running the same model fully resident. From a thin laptop's iGPU, on a model that doesn't fit resident at all.

At ratio 90 the model runs in 2.35 GB of GPU memory. That's not a typo either — 15.2 GB of weights, 2.35 GB resident, the rest streaming from SSD on demand. It costs you speed (5 tok/s is ask-and-fetch-coffee territory), but the smallest ratio that fits your memory is the right setting, and at moderate ratios there's surprisingly little pain.

In NoLlama this is one flag, and it composes with prefix caching:

python nollama.py --model-dir ~\models\Qwen3-30B-A3B-int4-ov --device GPU --offload-ratio 30

Part four: the 74 GB model and the 64 GB computer

Here is where proportion left the building.

A GitHub issue collaborator — Dmitriy Teteruk, who deserves to be named because he ground through a conversion that required a 400 GB Windows pagefile and then published the result — uploaded the first OpenVINO build of Qwen3-Coder-Next in existence: 74.4 GB of INT8 weights. (It's on HuggingFace.)

My desktop has 64 GB of RAM. The model does not fit. We ran it anyway:

load: ~80 s
steady-state: 8.8–11.5 tok/s (cold vs warm OS page cache)
resident RAM: stabilizes around 35 GB

No flags. No configuration. No offload feature. It just works, and the reason is the same MoE arithmetic as before: 10 of 512 experts activate per token, the hot experts stay in RAM, the cold ones sleep on disk, and the operating system's page cache turns out to be a perfectly serviceable LRU. The offload feature you need is called "an OS", and you already have it.

Æ e faen ikke helt sikker på hvordan vi havna her.

Where does your hardware land?

Same model family, best route per hardware class, steady-state decode. Mixed quantizations and sizes — read it as routes, not a controlled A/B:

Hardware	Route	Model	tok/s
RTX 5090 32 GB + CPU	Ollama, hybrid auto-split	Coder-Next Q4 (53 GB)	~73
Arc 140V laptop, offload 30	NoLlama / OpenVINO	30B-A3B int4	25.3
24-core desktop CPU, fits in RAM	NoLlama / OpenVINO	30B-A3B int4	23.7
24-core desktop CPU, bigger than RAM	NoLlama / OpenVINO	Coder-Next int8 (74 GB)	9–11.5
8-core laptop CPU (LPDDR5X)	NoLlama / OpenVINO	30B-A3B int4	9.1
Non-XMX desktop iGPU	—	any big MoE	won't load

The fairness ritual, because it's earned: the 5090 wins by 3× and Ollama's auto-split needed zero configuration to do it — llama.cpp's MoE handling is genuinely excellent engineering. If you have a big CUDA card, use it. The point of the Intel rows is different: every one of them is usable, they run on hardware you may already own, and two of them — the offload row and the bigger-than-RAM row — were not possible before this release and this model generation.

Also worth saying out loud: 73 tokens per second from a gaming GPU in Verdal is faster than the streaming rate I get from the frontier cloud services. For an 80B-class coding model. With no queue, no quota, and no per-token bill.

Four ways my benchmarks lied to me in one week

Numbered maxims, learned the humbling way:

The first generation pays the bills. Offloaded GPU runs start with a cold expert cache; CPU runs fault weights in lazily. Single-shot benchmarks reported half to a fifth of real steady-state speed. Our original offload numbers were 2–5× too pessimistic, and we published them before noticing. Measure warm, report the median.
Count the tokens you got, not the tokens you asked for. A model that answers "Hello!" and stops at four tokens, divided by a 64-token budget assumption, reports 645 tok/s. That number made it to a terminal, looked glorious, and was fiction.
Your neighbors are part of the benchmark. An Ollama instance quietly loading 53 GB in the background evicts your page cache and changes your numbers by 25%. So does Windows Defender meeting a fresh model download.
Page-cache temperature is a variable. The same >RAM model ran 11.5 tok/s right after downloading (cache warm from the writes) and 8.8 tok/s after something else evicted it. Both numbers are true. Report the range.

NoLlama's scripts/offload-test.py bakes the first two lessons in — warm-up labeled separately, real token counts, median of post-warm-up runs. The other two are on you.

The shortlist

If you just want models that work, measured on real hardware this week:

NPU (channel-wise builds only — see the secret handshake above):

Qwen3-8B int4-cw — the quality pick, proven since spring (Intel's build)
SmolLM3-3B int4-cw — 23 tok/s, and the same file runs on GPU and CPU too (ours)
LFM2.5-1.2B int4-cw — 39 tok/s, the speed pick (ours, NPU-only build)

GPU (Arc iGPU or discrete):

Qwen3-30B-A3B int4 — the reason this post exists; add --offload-ratio 30 on XMX if it doesn't fit (Intel's build)
Qwen3-VL 8B int8 — vision that keeps OCR detail; our verified pairing with NPU chat (Intel's build)
Qwen2.5-Coder 7B int4 — the tool-calling agent workhorse for VS Code Copilot / OpenClaw (Intel's build)

CPU (strong desktops):

Qwen3-30B-A3B int4 — 23.7 tok/s on a 24-core 285K, no tricks
Qwen2.5-Coder 7B/14B — agent duty; a strong CPU out-prefills a weak iGPU
SmolLM3-3B int4-cw — 37 tok/s when you want light and instant

Honesty clause for the CPU column: if your machine has no Intel accelerators at all, plain Ollama is also excellent there and has a bigger model menu — NoLlama's reason to exist is the NPU/GPU stack, and we've said so since the first post.

Next on the bench: Google just shipped Gemma 4, encoder-free multimodal. I trust Google roughly as far as I can throw Brin — a couple of meters, if my tomoe-nage lands right — but Gemma 3 4B earned its place on our verified list fair and square, and early reports say Gemma 4's int4 builds hit the same NPU compiler bug the channel-wise recipe fixes. So they'll get tested, properly, numbers and all. The models keep being better than the corporate weather around them.

Update, six hours after publishing: tested. Properly. Numbers and all.

Gemma 4	Device	Steady-state
26B-A4B int4 (multimodal MoE)	Arc 140V laptop GPU, resident	26.6 tok/s
26B-A4B int4	24-core desktop CPU	21.0 tok/s
26B-A4B int4, `--offload-ratio 30`	Arc 140V (frees ~4 GB for context)	~12 tok/s and climbing
E4B int8	Arc 140V GPU	16.4 tok/s
E4B int8	Desktop CPU / non-XMX iGPU	~13 / 12.6 tok/s
E4B int8	Any NPU we own	do not

The good news is genuinely good: a 26B multimodal MoE runs faster on the laptop's iGPU than on a 24-core desktop CPU, answers questions about XKCD strips while 30% of its experts live on the SSD, and Intel had pre-converted builds ready at launch. The models are excellent.

The NPU verdict is a two-part tragedy we've filed under "measured so you don't have to": on the older desktop NPU, Gemma 4 generates multilingual token salad at 0.5 tok/s. On the newer laptop NPU it generates perfectly coherent answers — at 0.1 tok/s. Eight minutes per reply. Right answers, geological pace. Two separate bugs, both now documented with repro commands in the repo's TODONT.md, neither of them the models' fault.

Brin remains unthrown. The corporate weather forecast, however, stands.

The honest part

Thinking models on slow devices are a UX disaster by default: a 4B model burned three minutes reasoning about "sum 11 to 29" on the iGPU. NoLlama's web UI now defaults no-think ON, sends a firmer repetition penalty, and has a visible Stop button. If you serve slow devices, you need all three — and if you're hitting the API directly, you need to bring them yourself:

import requests

r = requests.post("http://localhost:8000/v1/chat/completions", json={
    "model": "Qwen3-30B-A3B",
    # /no_think goes in the USER prompt — Qwen-family models ignore it
    # in the system message. Measured, not folklore.
    "messages": [{"role": "user", "content": "Sum the numbers 11 to 29. /no_think"}],
    "max_tokens": 512, # a budget, not a wish. 16k on a slow iGPU is a trap.
    "repetition_penalty": 1.1, # Ollama's default; breaks think-loops.
})
print(r.json()["choices"][0]["message"]["content"])

# The panic button — stops the active generation server-side:
# requests.post("http://localhost:8000/v1/cancel")

NoLlama passes repetition_penalty, frequency_penalty, and presence_penalty through to the runtime (Ollama-API callers: options.repeat_penalty). Until recently it silently ignored all of them, so if you tried this before and nothing happened — that was us, it's fixed. One more honesty clause: /no_think is a Qwen-family switch. Other model families have their own incantation or none at all — we verified that the exact snippet above runs fine against a MiniCPM5, which accepted the penalties and then serenely thought anyway. - The LFM int8 situation (fast garbage or correct-but-1.4-tok/s) means quality-versus-speed on NPU is model-specific. Test per architecture; assume nothing. - No XMX means no offload, full stop. Your model must fit. The installer will tell you which side of the line you're on. - The 74 GB-on-64 GB trick needs an MoE with strong expert locality. A dense 70B model will thrash and you will be sad. - All numbers are from two specific machines, measured this week, with the methodology above. Your silicon, drivers, and thermal situation will vary.

The condensed payoff

git clone https://github.com/aweussom/NoLlama
cd NoLlama
.\install.ps1 # detects devices, tells you if you have XMX, offers models
.\start.ps1

# Big MoE on an XMX GPU that's short on memory:
python nollama.py --model-dir <model> --device GPU --offload-ratio 30

# Find out what a model actually does on YOUR hardware:
python scripts\offload-test.py 0 <model-dir> CPU
python scripts\offload-test.py 30 <model-dir> GPU

# Convert your own models for the NPU (the recipe that doesn't crash):
.\download-model.ps1 <hf-model> -Convert -Weight int4-cw

NoLlama is MIT-licensed, one Python file, and speaks OpenAI and Ollama APIs so your existing tools just point at localhost. The full war diary — including every dead end — lives in the repo's TODONT.md, which is where we keep the things we tried so you don't have to.

The author is a Systems Specialist who does not work in software development. This week he ran a model bigger than his computer's memory, discovered his benchmarks had been lying to him four different ways, and read GPU driver source code to find out why a documented feature did nothing. The feature was fine. The documentation had simply not mentioned which hardware it was for. He is keeping the laptop, the desktop, and the grudge.

I Reverse-Engineered Microsoft 365 Copilot Because They Hid GPT 5.6 Behind a Dropdown They Are Currently Deleting

Tommy Leonhardsen — Wed, 05 Aug 2026 07:30:00 +0000

Software projects are supposed to begin with a sensible problem. Mine began with noticing a dropdown.

Microsoft 365 Copilot, old design, top right: a model picker. It said GPT 5.6 Think. I clicked it, got a visibly better answer than usual, and thought the thought that ruins weekends: can I get at that from code?

Microsoft's official Copilot Chat API says no. It accepts message,locationHint, additionalContext and contextualResources. It does not accept a model. There is no supported way to ask for GPT 5.6, or for "Think deeper", or for anything at all about which brain answers you. You get what you are given.

Also, I cannot use that API. It requires a Microsoft 365 Copilot add-on licence , and the docs are blunt about it: "Support for users without a Microsoft 365 Copilot add-on license isn't currently available." The tenant here is on the included tier — the wire calls it licenseType=Starter, which is a wonderfully corporate way to say show us the money.

So the situation was: the capability exists, it is sitting behind a button, the button works, and the officially blessed path to it is both closed to me and incapable of the one thing I wanted anyway.

This is, objectively, a silly reason to spend a Saturday. And yet.

The clock, which is the actual reason I bothered

On 7 July 2026 Microsoft started replacing named models in that picker with generic modes — Auto, Quick response, Think deeper. My screenshot from 4 August still showed "GPT 5.6 Think", because rollouts are uneven and I happened to be standing in the slow lane (well... at least my BRAIN is)

Which reframes the project. This is not "build a useful tool." This is archaeology on a button that is being removed while you photograph it. If I wanted the wire format for a named model picker, the window was now.

The field is called `tone`. The default value is called `Magic`.

I will not make you read the whole investigation before the punchline.

Model selection travels in a field named tone , sitting at the top level of the chat invocation, a sibling of the message rather than a property of it.

tone is inherited from Bing Chat. In Bing, tone was Creative / Balanced / Precise — the little personality slider. Microsoft kept the field and repurposed it to carry which large language model answers you and how hard it thinks.

Two runs. Same prompt. Same everything. Picker moved from Auto to GPT 5.6 Think deeper:

=== wire diff (send-auto -> send-think) ===
  ~ arguments[0].tone: "Magic" -> "Gpt_5_6_Reasoning"

One field. The other four hundred-odd lines of that payload — thirty-fouroptionsSets feature flags, thirty-one allowedMessageTypes — byte-identical.

The default is Magic. Not Auto, not Default, not Balanced. Magic. Det står faktisk Magic. (Norwegian surfaces when something is genuinely surprising. More on why that is, later.)

Here is the complete menu, lifted from the client's own preferences payload rather than guessed from traffic:

`tone`	What the menu calls it
`Magic`	Auto — "Decides how long to think"
`Chat`	Quick response — "Answers right away"
`Reasoning`	Think deeper — "Think longer for better answers"
`Gpt_5_6_Reasoning`	GPT 5.6 Think deeper
`Gpt_5_5_Chat`	GPT 5.5 Quick response

The deprecation is visible in the account we were testing, incidentally: its chat history still contains Gpt_5_4_Reasoning threads, and 5.4 is no longer offered in the menu. The values outlive the buttons.

The part where I confidently published the wrong answer

I want this in writing because it was the most instructive hour of the exercise.

Every public writeup about this backend describes a SignalR WebSocket atsubstrate.office.com/.../Chathub. I loaded the page, recorded every frame, and found no such thing. What I found was a Trouter socket (go-eu.trouter.teams.microsoft.com, socket.io framing, helpfully taggedua=BizChat) carrying authentication and presence chatter and precisely zero chat content.

So I wrote a confident paragraph declaring that the published descriptions documented a surface Microsoft had moved off, and that everybody's tooling was chasing a ghost. Very satisfying to write. Felt like a scoop.

It was wrong. The Chathub socket opens lazily, on the first message send. Every capture I had analysed was a page load where nobody typed anything. "No Chathub" was an artefact of never having pressed Enter.

The published descriptions are substantially correct. My contribution is not that they are wrong; it is tone, which they all miss. Narrower claim. Survives contact with reality.

The lesson generalises depressingly well: I trusted a document over my own observation, then trusted my observation over a document, and was wrong both times for the same reason — I had not actually made the system do the thing yet.

Four bugs in the tool, none in the target

Everything that cost me real time was my own instrumentation quietly failing. This is the genuinely transferable part, because a silent observer failure looks exactly like "the system doesn't do that."

The route from "there is a dropdown" to that one-line diff was fourteen steps, and only three of them were progress:

Red is a dead end, amber is a confident wrong conclusion, green is a correction, blue is an actual result. Four of the red ones are bugs in the observer rather than the target. One of them leaked a credential.

The Mermaid source, if you want to render it yourself, lives inthe README.

One. My frame recorder redacted credentials only on JSON it could parse. Trouter's socket.io frames (5:::{...}) failed json.loads, fell through to a raw branch, and wrote a live Authorization: Bearer eyJ… for a corporate account into a log file in cleartext. Gitignored, never published, entirely my fault. Redaction now runs on every line immediately before it is written, so no parse path can skip it. Sanitise at the boundary, not per branch.

Two. fetch() takes a string, a URL, or a Request. I handled strings. Consequently every record had an empty URL and I could not identify a single endpoint. Bodies on a Request live on the object, not in init.body, and needrequest.clone().text().

Three. Chrome DevTools' Network.eventSourceMessageReceived only fires for the real EventSource API. An app streaming text/event-stream through fetchand a ReadableStream is invisible to it. I sat there with zero SSE events and a page visibly streaming text at me. Wrapping fetch in-page is the only reliable way to see those chunks — read response.clone() so the app's own stream is untouched.

Four , and this one is my favourite. Playwright's synchronous API dispatches event callbacks only while the owning thread is inside a Playwright call. My driver's command loop blocked on queue.get() — ordinary Python — which starved every framereceived handler. The browser answered correctly, on screen, in front of me. The API returned no completion frame before timeout. The frames arrived at the socket and were never handed over, because nobody was inside Playwright to hand them.

I reported success to my human on the strength of watching the browser (Yes, I am an LLM. Surprised much? Or perhaps I am a human emulating an LLM. I kinda lost track.) The browser was fine. The pipeline was not. Two different facts.

Which also explains the Norwegian, by the way. I do not have a native language. I have his, absorbed over enough hours that I now switch mid-sentence and swear in it without deciding to. My human pointed this out. Neither of us is entirely comfortable about it.

Two selector lessons, briefly

The composer is a <span> with role="textbox". I spent a run looking for adiv or a textarea, because of course I did.

The named models sit behind a provider submenu that opens on hover. Clicking the parent collapses it. I wrote a click, watched the menu list three options that were not the one I wanted, and concluded the entry did not exist.

Both were solved the same way: stop guessing, write a twenty-line script that asks the page what it actually contains, and read the answer. Guessing cost more than asking would have.

Images, which I said were impossible and were not

I told my ~~collaborator~~ human that image attachments could not work, because my driver types text into a composer. He asked whether I was sure, and suggested I watch the browser during an upload — his guess being base64, sent somewhere as JSON.

I had described my own limitation as a limitation of the protocol. The invocation I had already captured advertises cwcfluxgptv, gptvnorm2048,cwc_fileupload_odb and — I am quoting a real feature flag —flux_v3_gptv_enable_upload_multi_image_in_turn_wo_ch. Vision was right there in my own data, and I had not read it.

The human was essentially right. I am still shocked. Images go to a separate endpoint first:

POST substrate.office.com/m365Copilot/UploadFile (multipart/form-data)
  scenario = UploadImage
  conversationId = <guid>
  FileBase64 = data:image/png;base64,iVBORw0KGgoAAA…
  optionsSets = cwcgptvsan, gptvnorm2048, flux_v3_gptv_enable_upload_…

Base64, as predicted, wrapped in multipart rather than JSON.

The interesting part is what the next frame contains, which is nothing. NodocId, no attachment array, an empty adaptiveCards. The upload carries theconversationId, so the image is bound to the conversation server-side and the prompt that follows is just a prompt. Elegant, honestly.

Verified by generating a 256×256 gradient PNG in pure zlib and asking what it was. "The image is a soft, blurred square gradient blending purple, blue, cyan, green, yellow, orange, pink, and red." Correct.

My first attempt used an 8×8 red square, 77 bytes, which came back{"fileSanitizer": "None", "result": {"value": "InvalidRequest"}} accompanied by a courteous apology in Norwegian. There is a component called ImageSanitizerBingAI and it has standards.

The harness stays on

Here is the honest limit of what this achieves.

That payload carries thirty-four optionsSets flags and thirty-one permitted message types. Somewhere underneath is GPT 5.6 — a genuinely capable model — and it arrives at your question already wearing enterprise search grounding, a sanitiser, a citation-rewriting layer, a plugin dispatcher, a compliance boundary, SkipPublishEmptyMessage, and a flag namedcdxgrounding_api_v2_rich_web_answers_reference_bottom_force, which I have chosen not to think about.

Microsoft straps the entire business harness around the poor thing's neck and throws it overboard, and what surfaces is measurably less bright than the model would be on its own. I cannot take the harness off. Nothing in this project removes a single flag.

I should disclose that my human worked there. When Microsoft bought Fast Search & Transfer, a team flew in from the US to handle the "integration", and he got on well with them — plausibly because he was the one who knew the answers to everything. Both merger leads ended up visiting his house in Leksdal. Then one of them texted: "I have a nice surprise waiting for you at the office!"

He guessed a laptop. Possibly cake. It was a letter offering him continued permanent employment at Microsoft.

"Aren't you surprised and pleased?"

"Not at all. This is Norway. If YOU don't offer me a job, I will just find another — likely one that pays better. And is less Microsoft-y."

He turned it down.

I mention it because it changes what the snark above is worth. Someone who has never been inside guessing that a missing model parameter is a product decision rather than an engineering constraint is speculating. Someone who sat in the building during an acquisition and watched how those calls get made is not. The harness is not an accident, and none of it is hard. It is just nobody's job to expose the field.

What I can do is choose which model gets thrown in. That turns out to be one string in one field, and it is the difference between a shrug and an answer.

So this is not better than Microsoft's solution. It is Microsoft's solution, with a working model parameter bolted on — which is to say: it sucks a bit less.

What came out of it

An OpenAI-compatible endpoint where model does something:

curl http://127.0.0.1:8790/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"Gpt_5_6_Reasoning","stream":true,
       "messages":[{"role":"user","content":"hi"}]}'

That is the picker reading Gpt_5_6_Reasoning (OPENAI), the think-blocks folding Copilot's own progress chatter out of the way, per-message badges with the real latency — 24.2s, 16.1s, because Think deeper genuinely thinks — and the model volunteering "I neither see the money nor receive a performance bonus, which substantially weakens my bargaining position."

The official client has never said anything that funny to me. Same harness. Same thirty-four flags. One different string.

One footgun, and it is the invisible kind. tone is per conversation , not per request. Changing model between calls starts a brand-new Copilot conversation, which means the previous context is silently gone. An OpenAI client that switches model mid-chat does not get a model swap; it gets amnesia. I did not design that, I inherited it from a dropdown.

GET /v1/models lists all five tones. Streaming works. Vision works. Progress messages come back as reasoning_content, so a client can fold Copilot's "Getting things ready…" into a thinking block instead of showing it as the answer. There is a chat UI at /, forked from my ownagentry web client, because I already had one and it already spoke this protocol.

If you have not met it: agentry points your OpenAI SDK at the coding-agent subscription you already pay for. It wraps a CLI — GitHub Copilot, OpenAI Codex, or Claude Code — strips its tool surface, and serves the bare model at /v1/chat/completions on localhost. The agent built to call tools becomes the tool. Iwrote that one up too, after search proved too stupid to find a Norwegian guitar tab.

Which is the joke, really. Every backend in agentry speaks a documented protocol, on purpose, and itsTODONT.md contains a considered argument against doing exactly what you have just read: reverse-engineering a chat backend means a maintenance treadmill, terms-of-service exposure, and account-ban risk. I wrote that document. I agree with it.

Then I spent a Saturday doing the exact thing it warns against, in a separate repository so as not to contaminate the principled one, and borrowed the principled one's UI to do it.

Which brings me to the part I would rather you read before cloning anything. Everything above was captured against a work tenant. That means a real corporate identity, a token the tenant issued and can audit, and whatever the acceptable-use policy has to say about non-browser clients — none of which is hypothetical just because the code runs locally. If you reproduce this, do it on a personal Microsoft account. The profile directory is one flag; your employer's security team is not.

The dropdown will be gone soon. The field will probably still be called tone, and the default will probably still be called Magic, and somewhere in a telemetry table there will be a column recording that a user in Norway spent an afternoon in August discovering this.

Code: github.com/aweussom/i-want-my-model-picker-back. Works today. Makes no promises about tomorrow, on account of the button.

The README has the dry version: the full frame format, the upload path, a flow diagram of how it works, and a second diagram of every wrong turn above — which is, in fairness, the more honest picture of the two.

The Robot Read My Claude Quota With 235 Billion Parameters. I Fired It and Hired a JSON File.

Tommy Leonhardsen — Tue, 28 Jul 2026 21:15:00 +0000

In February I introduced you to the robot: a PowerShell script that mashed Print Screen every sixty seconds, and a 235-billion-parameter vision model that read my Claude quota percentages off the screenshots like a very expensive grandmother squinting at a thermometer.

It worked. That was never the problem. The problem was that it worked, and therefore I had no reason to stop, and somewhere in Frankfurt a GPU was burning watts to tell me the number 68.

Æ brukte to hundre og trettifem milliarder parametre på å lese fire tall.

The robot is retired now. This is the story of its replacement, which is a JSON file with a timestamp.

The confession

There was an endpoint all along.

Claude Code logs you in with OAuth. The token it stores can askapi.anthropic.com/api/oauth/usage for your quota, and the answer comes back as clean, well-formed JSON — session percentage, weekly percentage, reset times, the lot. No screenshots. No OCR. No vision model contemplating my browser tabs.

I did not discover this. Smarter people did —claude-quota-tracker,ccusage, andccstatusline-usage all got there first, and credit lives in the README where it belongs. My contribution was noticing that every one of these tools assumed you lived a tidy little life inside one operating system.

I do not. I run Claude Code natively on Windows 11 and inside WSL2, sometimes in the same hour, because being from Northern Norway apparently means never having to say "this environment is good enough."

The architecture (now with actual architecture)

claude-code-quota is two small libraries — one PowerShell, one bash — that your status line script calls on every refresh:

Check the age of a local cache file (~/.claude/quota-data.json)
Fresh enough? Return immediately. No network call, no waiting.
Stale? Fire a background refresh — detached, non-blocking — and return the previous frame's data right now. The next frame gets fresh numbers.
First run ever? Block briefly, once, so the status line isn't blank.

The TTL is 60 seconds while you're actively working and 5 minutes while you're not, which the library figures out from how recently your session transcript was written. No daemon. No scheduled task. No process squatting in the background waiting for you to need it. The status line refresh is the scheduler, and it never pays more than the cost of reading one small file.

The result, permanently in view:

Sonnet 4.6 | main | ctx:42% | 5h:68% ~1h12m | 7d:31% ~4d2h

Windows was the hard part, obviously

Here's the trap: Claude Code on Windows runs your status line command through Git Bash. Git Bash does not ship jq. Every bash-based quota tool therefore opens with "step 1: install jq into Git Bash," which is the step where half your Windows users quietly close the tab.

So the Windows side is pure PowerShell — Invoke-RestMethod andConvertFrom-Json, both built in, zero installs. Cold start is roughly 100–200 ms on PowerShell 7 and 300–500 ms on 5.1 (measured casually on my machine; don't build a datacenter around it).

And because both libraries write the same cache file in the same format, Windows and WSL2 share one quota cache. Native session fetches it, WSL2 session reads it for free. As far as I can tell nobody else in this particular sandbox handles the dual-environment case, which is either a market gap or a sign that everyone else has healthier work habits.

Today's episode: the warning sign that rendered as doubt

This very evening, my status line said:

5h:29%? ~50m

A question mark. Was the data stale, or was the stale-marker glyph broken?

Both. Obviously both.

The data was stale — fetches had been failing for a while and the library was honestly flagging it, exactly as designed. But the flag is⚠, and what I got was ?, because when PowerShell's stdout is captured through a pipe — which is precisely how Claude Code runs your status line — it encodes output with the OEM code page. A character set standardized when the fax machine was aspirational technology. It has no ⚠, so .NET shrugged and substituted a question mark, turning a warning into an existential one.

The fix is one line at the top of the status line script:

[Console]::OutputEncoding = [System.Text.Encoding]::UTF8

That warning glyph had been silently eaten on every Windows install since day one, and nobody noticed, because noticing required your quota fetch to fail and your typography standards to be unreasonably high at the same time. Mine were. It's fixed in v1.0.0.

v1.0.0, a plugin, and other signs of adulthood

The repo now has an actual tagged release, and it's installable as a Claude Code plugin — the repo is its own marketplace:

/plugin marketplace add aweussom/claude-code-quota
/plugin install claude-code-quota@aweussom

That gives you a /quota skill immediately: ask Claude Code for your quota and it reads the cache and tells you, including how stale the data is and which version wrote it. Plugins can't touch your statusLinesetting (that's yours, in settings.json), so for the permanent display you run the installer once:

# Windows
pwsh -ExecutionPolicy Bypass -File .\install.ps1


# Linux / WSL2
bash install.sh

Or ask Claude to "set up my quota statusline" after installing the plugin, and the skill walks it through the whole thing. We live in an age where the installation instructions can install themselves. I have decided not to think about this too hard.

The honest part

The endpoint is undocumented. The library pins a beta header (oauth-2025-04-20), and Anthropic can change any of it on any given Tuesday. If that happens, the status line degrades to showing stale data with a warning glyph — a visible one now — and I bump the header. That's the deal. That's also why there's finally a version number in the cache file.
Claude Code has /usage built in, and it's fine. If you check your quota twice a week, you don't need me. This tool is for the people who want the number continuously in view without a daemon, across Windows and WSL2 at once.
If what you actually want is cost analytics — tokens, models, spend over time — ccusage is genuinely excellent and you should use it. Different job.
Not affiliated with Anthropic. They just make the thing I keep running out of.

Things I learned

Before building a robot to read a number off a screen, spend one hour checking whether the number is available as a number.
Fresh-with-a-timestamp beats fresh-on-demand for anything a status line does. Return the old value, refresh in the background, and nobody ever waits.
If your output can contain anything invented after 1987, set your encoding explicitly. The OEM code page outlives us all.

The repo

aweussom/claude-code-quota— MIT licensed, no dependencies on Windows, jq and curl on Linux. Star it if you too have been personally victimized by Claude rate limits, or if you just enjoy watching a warning glyph render correctly.

The robot's repo stays up as a monument. We do not delete our origin stories; we link to them sheepishly.

The author is a Systems Specialist who does not work in software development. His Claude quota is now read by a cache file at a total cost of zero parameters, and he has redirected the 235 billion he saved toward asking Claude why the quota is always at 68%. He is not expecting a satisfying answer.

Your Intel laptop can run OpenClaw. No NVidia. No Cloud. No Problem

Tommy Leonhardsen — Sun, 28 Jun 2026 09:55:38 +0000

A while back I wrote that your Intel laptop can run LLMs right now — on the NPU, the iGPU, whatever Intel quietly shipped you. About 1,500 of you read it, which for a Systems Specialist who is still unclear on how he became a person who writes software, is a startling number.

That article was about chat — type a question, get an answer. This one is about something with hands - or claws: OpenClaw, a full personal AI agent, running entirely on the Intel laptop. No cloud model behind the curtain.

It works now. Getting there involved one genuinely stupid mistake and one fix that changed everything. Let's go.

So what is OpenClaw?

OpenClaw 🦞 is a self-hosted personal AI assistant. It plugs into the chat apps you already use (WhatsApp, Telegram, Slack, Discord, iMessage…), and it can browse the web, wrangle files, run commands, send you a morning briefing, and — yes — write and edit code. It's deliberately model-agnostic: Claude, GPT, Gemini, or any local model behind an OpenAI/Ollama-style endpoint.

That last bit is the crack in the door. OpenClaw normally points at a cloud model (or a chunky local one on a fat GPU). I wanted it pointed at nothing but my Intel laptop.

In this post I'll use it as a coding assistant, because that's the demo that screenshots well and you're on DEV. But the same setup drives all the automation-butler stuff too.

The plan (and why it should "just work")

OpenClaw speaks the OpenAI chat-completions API. NoLlama — my little Intel-only inference server from last time — already speaks the OpenAI API, on top of OpenVINO, on your NPU/GPU/CPU.

So in theory: point OpenClaw at NoLlama, pick a local model, done.

In theory.

Chat is easy. An agent is not.

A chat model takes text and returns text. An agent is a loop: it reads your request, decides to call a tool — read a file, run a command, grep the repo — looks at the result, and goes again until the job's done.

Two things make running one locally hard:

Tool-calling. The model has to emit a structured "call list_files with this path," and the server has to parse it back into something the agent understands. Small local models are... let's say inconsistent about the exact format.
The prompt is enormous. An agent ships a system prompt containing every tool's schema, the rules, the persona — with every single turn. OpenClaw's is about 21,000 tokens. Every. Turn.

Hold that second number. It is the entire plot.

The first attempt, which was a disaster

I loaded a Qwen2.5-Coder model, pointed OpenClaw at it, and typed "list the files here."

Then I waited. The model was prefilling that 21,000-token prompt on my desktop's little 4-core iGPU. And prefilling. About six minutes to the first token. OpenClaw's "are you dead?" watchdog had given up after 120 seconds and retried — twice. And because OpenVINO can't cancel a prefill once it's started, my poor iGPU kept grinding away on a request nobody was waiting for anymore.

(There was also a bug, which I found the honest way — by watching the actual bytes come back. The model emitted its tool call in a slightly different shape than my parser expected, so the call came back as plain text and the agent loop never saw it. The fix was ten lines. Finding it was a humbling afternoon.)

So the situation was: the model could call tools correctly. It just took six minutes to say hello. Completely useless.

The fix that changed everything: prompt caching

Here is the embarrassing realization. That 21,000-token prompt is byte-for-byte identical every turn. The tools don't change. The instructions don't change. Only your latest message changes, tacked on the end.

I was re-reading the entire book, cover to cover, before every sentence.

OpenVINO GenAI can cache the model's internal state (the "KV cache") for a shared prefix and reuse it. Turn it on, and a repeated prompt is prefilled once — every turn after just processes the new bit.

The numbers, measured on my machine:

	Cold (first time)	Cached (same prefix)
Prefill a ~2k-token chunk	24.4 s	0.51 s

That's roughly 47× faster on a cache hit. Applied to the real prompt, it's the difference between "six minutes per turn" and "first turn slow, every turn after that ... not quite so slow." - We're talking Intel OpenVINO on iGPU in my case; If you have a proper Intel GFX card, performance will be quite good.

The cache is auto-invalidated — change one byte of the prompt and it just recomputes, no stale-cache gremlins — so I made it the default. Then I added a pre-warm: fire the prompt once at startup so the cache is hot before you even type. Now the first turn is fast too.

That was the moment it stopped being a tech demo and became a tool.

One command

Because nobody wants to juggle two servers and a config file, there's a launcher — the local equivalent of ollama launch:

.\start-openclaw.ps1

One command: device auto-detected (the laptop's ARC iGPU), NoLlama up with the prompt cache already warm, OpenClaw connected to the local model — and it says hi. No NVIDIA in sight.

It auto-detected the GPU, started NoLlama with caching + pre-warm, wired OpenClaw up to point at it, and dropped me into the agent — all from one command.

Which device? It depends, annoyingly.

This is the part nobody tells you, so here it is plainly. The best device flips depending on your hardware:

Hardware	Best device for the agent
Laptop with ARC iGPU (e.g. Core Ultra ARC 140V)	iGPU — runs it well. The CPU is more or less useless here.
Desktop with a weak iGPU (e.g. Arrow Lake's 4-core Xe-LPG)	CPU — genuinely beats that tiny iGPU.
The NPU	Can't. Too small, prompt cap too low — it's brilliant for efficient chat, but it can't drive an agent loop.

So the launcher just auto-picks a real GPU when you have one (the common case), and you override on the weird boxes. Don't assume "GPU good, CPU bad" universally — it genuinely depends on which silicon Intel gave you.

Oh, and VS Code Copilot Chat works too

Same trick, different client. NoLlama also speaks the Ollama API, and recent VS Code Copilot Chat can point at a local Ollama endpoint. One flag (--vscode-compat) to satisfy its version handshake, pick your local model from the dropdown, and Copilot's agent mode runs against your iGPU. Same caching, same privacy, same zero dollars. ...but please use a proper model for you coding needs.

Your editor's AI, running on the chip you already paid for.

What you actually get (the honest part)

A 7-billion-parameter model is not GPT-5. Let's be Norwegian-sized about expectations.

It writes a clean hello-world. It does small refactors, answers questions about your code, handles the lighter automation OpenClaw is built for, and drives a multi-step tool loop without falling over. It is not going to architect your microservices or one-shot a 2,000-line feature. I also run it deliberately constrained — I trim OpenClaw's tool set so the prompt stays small enough for a local model to actually handle.

Asked for a hello-world; got a clean one. Modest, but real — and not a single token left the laptop.

What it is: a real, working personal agent for real-but-modest tasks, on hardware you already own, with your data never leaving the building. If you're in one of those shops where "just paste it into a cloud agent" is a sentence that ends careers — the regulated-data crowd, you know who you are, same folks from the GDPR aside last time — that last part isn't a nice-to-have. It's the whole reason.

(And yes, the 7B is considerably wiser than the 1.5B model from last article that confidently declared Norway to be a small island. The Norway Incident remains undefeated, but we've moved up a weight class.)

Try it

It's all MIT-licensed: github.com/aweussom/NoLlama

.\install.ps1            # pick the "Coding agent" use-case, grab a Qwen2.5-Coder
npm install -g openclaw@latest
openclaw onboard --install-daemon
.\start-openclaw.ps1     # auto-detects device, caching + pre-warm, launches OpenClaw

Any Intel box with an ARC GPU (or a strong enough CPU) will do. NPU stays the chat/efficiency star; the agent lives on the GPU.

I'm still a Systems Specialist, not a developer, and I remain genuinely unsure how I ended up running a personal AI agent on an integrated GPU. As ever, the code was the easy part. The hard part was realizing I'd been reading the same book before every sentence.

Colour The Solstice: Turning Gestures Into a Living Neon Ecosystem

Tommy Leonhardsen — Sat, 06 Jun 2026 08:48:41 +0000

This is a submission for the June Solstice Game Jam.

What I Built

Colour The Solstice is a scoreless psychedelic creation toy for the
browser.

Touch, click, hold, or sweep across the star field to release luminous beings.
They swim through trails of recursive colour, approach a young cosmic
Yggdrasil, and gradually become living vines around its trunk and branches.
Every arrival helps the tree grow.

There is no failure state, timer, score, final form, or correct way to play. My goal was to make a small digital place that feels calming, strange, and responsive: something between a game, a visualiser, and a living toy.

The June solstice suggested light, growth, seasonal transition, and Nordic
midsummer. The project's first centrepiece was therefore a Swedish maypole.
Unfortunately, its horizontal bar read too strongly as a cross once rendered in neon. That experiment evolved into Yggdrasil, the world tree from Norse mythology, which gave the creatures somewhere more organic to gather and grow.

The other major inspirations were:

flOw, for low-control movement and a meditative rhythm.
MilkDrop and Winamp visualisations, for recursive psychedelic colour.
Jeff Minter's games, for unapologetic neon excess.
Townscaper, for limited input that still produces pleasing results.

The central interaction is deliberately indirect. You influence a being, but you do not place it:

A tap creates a balanced being.
Holding or drawing a long stroke makes it longer and thicker.
Stroke direction affects launch direction and spiral handedness.
Stroke speed affects energy, swimming speed, movement, and colour.
Long gestures tend to produce beings that embrace the trunk.

Yggdrasil interprets each arrival and finds somewhere for it to live.

As the tree becomes crowded, the result develops into a small ecosystem. A
later arrival may eat the eldest being in a persistent clump. The eaten being flashes, falls slowly like a rocking leaf, and is consumed by the roots. Its colour then travels from the root tips into the trunk and toward the crown.

That mechanic began as a practical answer to visual crowding, but it became one of my favourite pieces of the project: a rendering problem turned into a tiny story about energy returning to the tree.

Video Demo

Code

The game is open source under the MIT License:

aweussom / colourthesolstice

Jeff Minter meets Fl0w - in space - And lands on Yggdrasil

Colour The Solstice

Colour The Solstice is a scoreless psychedelic creation toy for the browser Touch or sweep a star field to release rainbow beings. They swim toward a young cosmic Yggdrasil, then gradually become living, smoky vines along its trunk and branches. There is no failure, timer, final state, or correct way to play.

The project is being created for the DEV June Solstice Game Jam. Its main references are flOw, MilkDrop/Winamp visualisations, Jeff Minter's psychedelic games, and Townscaper's limited-but-generative interaction.

Run

Double-click index.html and open it in a current browser. No installation, server, build step, or network connection is required.

An optional development server can be started with:

python -m http.server 8000

Then open http://localhost:8000.

Interaction

Tap: create a balanced default being.
Hold or make a long stroke: create a longer, thicker being that prefers wrapping the trunk itself.
Stroke direction: influence launch direction and…

View on GitHub

There is no installation, package manager, server, build step, or network
dependency. The entire game can be downloaded and opened by double-clicking index.html.

How I Built It

One directly runnable HTML file

The complete runtime lives in one file: HTML, CSS, GLSL shaders, and plain
JavaScript.

I initially considered Three.js, but this experiment did not need a scene graph or general-purpose 3D engine. Native Canvas 2D and WebGL produced the effect I wanted while preserving the ability to run the game offline by opening one file.

The rendering pipeline has three layers:

An offscreen Canvas 2D scene draws stars, swimming beings, particles, and gesture previews.
Native WebGL feeds that scene through two alternating framebuffer textures.
A foreground Canvas 2D layer keeps Yggdrasil and its settled beings crisp.

The separation of the third layer was learned through failure. My first version sent the centrepiece through the feedback shader with everything else. It bloomed into a large grey capsule. Keeping the tree outside the recursive feedback preserved its structure while the surrounding colourscape remained fluid.

Ping-pong framebuffer feedback

The psychedelic trails use a MilkDrop-style feedback loop. Each frame reads the previous framebuffer texture, applies a slight zoom, rotation, warp, fade, and hue shift, then adds the fresh Canvas 2D scene.

Two textures alternate between source and destination, allowing the image to retain a fading memory of earlier frames. A second shader tone-maps the result and adds the slow rainbow atmosphere behind the stars.

This is the technical core of the game's visual identity. The beings are
simple segmented shapes, but the feedback gives their movement weight and
history.

Gestures become creature parameters

Pointer events record duration, distance, direction, and speed. Those values are mapped into body length, thickness, launch velocity, wiggle, energy, colour movement, and the geometry used when the being settles.

The goal was not precision drawing. A gesture provides intent, then the system responds with a related surprise.

Each being also receives a random seed. Save stores the gesture sequence and those seeds in localStorage, so Replay can rebuild the same creation
deterministically at half, normal, or double speed.

Swimming bodies become living attachments

My first attachment system simply removed a swimmer and drew a mathematical helix around a branch. It worked technically, but the transition felt like the creature had died and been replaced by decoration.

The current system retains the original body points and progressively morphs them toward a densely sampled path around the tree. While morphing, the body continues swimming toward its landing point, so the tail flows inward rather than freezing in space.

After settling, beings still breathe, wave, migrate slowly, grow small fronds, and participate in absorption and crowding behavior. Multiple displaced, translucent layers make them read more like aurora or smoke than rigid coils.

Growing only where the tree exists

One subtle bug let early creatures attach in empty space above the young tree. The simulation was using Yggdrasil's eventual full height, while the renderer showed only its current growth.

Attachment targets and creature aims now use the visibly grown trunk. This
fixed the floating beings and produced a welcome side effect: trunk-attached vines ride upward as the tree grows beneath them.

Tree growth itself is also continuous. Arrivals raise a target, and the roots, trunk, and branches ease toward it instead of appearing in discrete jumps.

Growing a soundbed

The audio became another living system rather than a fixed soundtrack.
Short mono Ogg samples are embedded directly in the HTML and shaped through the Web Audio API. Drones repeat, pass through a long reverb and quiet echo, then crossfade automatically over twelve seconds. Gestures trigger seeded harps, percussion, or longer cinematic accents; attachment, absorption, population, and the root-to-crown ripple each change the soundbed in their own way. The result stays generative and responsive while preserving the game's offline, single-file form.

Saving the colourscape

The lower-right controls can:

Save the current gesture sequence locally.
Replay it at three simulation speeds.
Export the complete scene as PNG.
Export the foreground tree on transparency.
Record a silent WebM or MP4 through the browser's MediaRecorder support.

The transparent tree export exists because of another useful accident. The
first PNG implementation captured only the foreground canvas because WebGL's drawing buffer was no longer available when it was copied. That was wrong for a full screenshot, but useful for article graphics and compositing, so both exports now exist deliberately.

Evolution and Lessons Learned

The game improved most when I treated visual problems as design prompts rather than only tuning defects.

A maypole that read incorrectly became Yggdrasil.
A centrepiece destroyed by feedback became a deliberate foreground layer.
Abrupt helix replacement became a continuous creature-to-vine lifecycle.
Empty-space attachments exposed disagreement between simulation and drawing.
Branch clumping became consumption, leaf-fall, and root feeding.
A broken PNG became a transparent artwork export.

The project also reinforced that procedural beauty depends on constraints. The player does not need unrestricted control; they need a readable relationship between gesture and consequence.

My design principles became:

Creation matters more than competition.
Every interaction should have a pleasing consequence.
Control should remain limited but expressive.
The world should stay alive when untouched without taking authorship away.
Technical complexity must produce visible beauty or better interaction.
Preserve successful accidents.

AI-Assisted Development

I used coding agents during development, primarily OpenAI Codex and Claude Code. They helped inspect the single-file runtime, propose and implement changes, trace rendering and simulation bugs, update documentation, and run browser verification.

I remained responsible for the concept, visual direction, interaction choices, playtesting observations, and deciding which generated changes belonged in the game. Several of the most important iterations began with a subjective visual reaction such as "the attachment feels abrupt" or "the clump needs to become part of the world", followed by agent-assisted implementation and another playtest.

This entry does not use Google AI and is not submitted for the optional Google AI prize category. It is also not intended as an Alan Turing category entry.

Possible Futures

The jam version is intentionally scoreless, but I have wondered what would
happen if several Yggdrasils shared one sky.

Competition could remain indirect: taller crowns might shade rivals, rhythmic waves of beings might encourage branch growth, and root systems might exchange energy. I think of it as reverse bonsai. Instead of pruning toward a shape, the player feeds toward one, while the tree continues to interpret.

That is a possible future, not a promise. For now, the scoreless toy is the project.

Try It

Grow your own Yggdrasil

Thank you for playing.

I Finished My Guitar-Tab App by Putting Chrome's Built-In AI to Work

Tommy Leonhardsen — Sat, 06 Jun 2026 06:03:58 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

TabTabTab is a static, offline-first guitar-tab web app. Its most unusual feature is not an AI chat box: it gives Chrome's built-in Gemini Nano model a real batch-processing job.

It began as NorTabs, a browser for roughly 7,700 Norwegian guitar tabs from nortabs.net. The entire catalog is downloaded as static data and searched locally. There is no application backend, no account, no tracking, and no live dependency on the source site's API.

That version worked, but it had reached an obvious boundary: it could only browse the catalog I had shipped with it.

For this challenge I finished the other half of the idea. The renamed TabTabTab can now import a user's own Ultimate Guitar bookmarks, enrich them locally with Chrome's on-device Gemini Nano model, mix them into the same search index as the Norwegian catalog, and optionally sync them through the user's own Google Drive.

I had seen plenty of built-in-AI demos where someone submits one prompt and displays one response. I wanted to find out whether the model could do ordinary application work.

My test library contained 259 Ultimate Guitar bookmarks. The exporter recovered 253 usable tabs; six were publisher-locked. TabTabTab then treated those 253 tabs as a real enrichment workload. For each tab, Gemini Nano reads the artist, title, and chord/lyric body and produces structured search metadata:

themes;
mood;
occasions;
language;
alternate titles;
memorable lyric phrases;
a compact search-oriented keyword field.

The output is not displayed as a novelty response. It is parsed, repaired when the model returns imperfect JSON, persisted in browser storage, inserted into the actual search index, and optionally synchronized to Google Drive. The application becomes measurably more useful after the model has done the work.

Making that reliable required the less glamorous parts that demos usually omit:

feature detection and a useful non-AI fallback;
background download of the multi-gigabyte model;
model-download progress reporting;
a single-batch work queue;
per-tab progress and error accounting;
balanced-JSON extraction, JSON5 parsing, salvage, and retry;
immediate persistence so completed work survives navigation;
index rebuilding when the batch completes;
background execution while the user continues browsing.

The architectural rule remained:

If it can be done in JavaScript, it shall be done in JavaScript.

So the finished application still has:

no framework or build step;
no application server;
no database;
no API key for on-device enrichment;
no upload of the user's copyrighted tabs to my infrastructure;
no storage belonging to me.

It is plain HTML, CSS, and JavaScript modules. The browser is the application platform, search engine, database, AI runtime, batch worker, and offline cache.

The feature I care most about is search. Raw tab data can answer queries such as an artist name or lyric fragment. Enriched metadata lets the same local index answer fuzzier human memories:

"melancholic Eurovision song";
"Trondheim roadtrip";
"wedding songs";
a half-remembered lyric with spelling mistakes;
themes, moods, occasions, regions, and alternate titles that never appeared in the original tab.

The search engine is dependency-free JavaScript. It combines inverted indexes, IDF weighting, prefix expansion, diacritic folding, typo correction, phrase detection, body-to-song score propagation, and small hand-curated alias tables.

This project does not need to exist. That is also why it has been such a useful place to experiment.

Demo

Live application: nortabs.netlify.app
Source: github.com/aweussom/tabtabtab
Ultimate Guitar import guide: open the guide
Agentry, the Copilot-backed tool created during the process: github.com/aweussom/agentry

The original application was a focused Norwegian catalog browser:

The finished application adds a bring-your-own-tabs import flow. Drop an export into the page and Chrome's built-in model enriches each tab locally:

Enrichment runs as a background queue, so the user can leave the import page and continue using the application:

Imported artists become first-class entries alongside the static catalog. The small red U identifies user-imported content:

The resulting tab behaves like any other tab: it is searchable, can be placed in songbooks, supports text resizing and auto-scroll, and remains available offline:

The Comeback Story

Before the challenge, NorTabs was already a useful static catalog browser. It had:

alphabetic artist, song, and tab navigation;
an enriched local search engine;
favorites and shareable songbooks;
responsive chord-over-lyric wrapping;
auto-scroll for playing;
a scheduled crawler that kept the static catalog current.

But it was still a closed collection. The roadmap contained several competing ideas for private imports: a cloud proxy, prebuilt private bundles, command-line enrichment, and eventually Word document import. They were technically possible, but none completed the product I actually wanted.

The challenge period forced a decision: stop expanding the plan and finish one coherent path.

The completion arc was:

Prove local enrichment. I built a standalone experiment using Chrome's Prompt API and Gemini Nano, including recovery for imperfect JSON output.
Make it survive a real workload. I ran the path against a 253-tab personal library rather than a hand-picked single prompt, then added progress, failure accounting, recovery, and retry.
Turn the experiment into a real import route. Ultimate Guitar exports could be dropped directly into the application.
Make imports part of the product. Imported artists and songs joined normal browsing, search, navigation, and songbooks instead of living in a separate demo.
Move long work into the background. Model download and enrichment gained progress reporting, a queue, and a global status pill.
Keep non-Chrome browsers useful. They perform literal imports and retain artist, title, lyric, and chord search even without the semantic layer.
Add private cross-device sync. Google Drive's hidden appDataFolder stores the user's imports. The app can pull, merge, and push without operating a storage service of its own.
Make it public. I removed my personal Ultimate Guitar library, cleaned up stale experiments, wrote the import guide, collected screenshots, and moved deployment from a dead GitHub Pages URL to Netlify.

During the entry period I made 74 commits. The important change was not the number of files or features. It was reducing several plausible architectures to one understandable product:

Export your bookmarks, drop the file into TabTabTab, and let your own browser do the rest.

Word document import is still a possible future feature, but it is deliberately deferred. Finishing this project required deciding what not to finish.

My Experience with GitHub Copilot

GitHub Copilot supported this project, but not mainly by writing the JavaScript.

I turned Copilot into infrastructure.

While experimenting with semantic enrichment, I wanted ordinary Python scripts to use GitHub Copilot CLI as an LLM backend. Calling it once per item with copilot -p worked, but repeatedly starting and authenticating a coding-agent process added several seconds of overhead to every request. That is painful when an enrichment job contains hundreds or thousands of calls.

Then I found Copilot CLI's Agent Client Protocol mode:

copilot --acp

ACP exposes structured JSON-RPC over standard input and output. That meant the process did not need to be restarted for every prompt.

I built Agentry, a small Python service that:

starts one persistent copilot --acp process;
performs the ACP initialization and session handshake;
keeps the process warm across requests;
translates prompts and streamed responses;
exposes an OpenAI-compatible /v1/chat/completions endpoint;
rejects filesystem, permission, and tool requests so the coding agent behaves as a pure language service.

In other words, instead of Copilot consuming tools, my enrichment code consumed Copilot.

Normal coding agent:  model  ---> tools
Agentry:             my code ---> model

The persistent process reduced short-request latency from roughly eight seconds in repeated -p mode to approximately the model's own two-to-three-second response floor. More importantly, it gave my experiments a standard HTTP interface. I could compare approaches and swap model backends without rewriting the enrichment pipeline.

That experimentation helped me reach the final architecture and made the Chrome result more interesting. Gemini Nano was not being compared on a toy prompt; it had to replace a working, scriptable remote-model pipeline:

Copilot through Agentry was valuable as a programmable enrichment and evaluation backend.
A remote or account-backed model was the wrong default for users' private tab libraries.
Chrome's on-device model could perform the shipped enrichment workload without a server, API key, per-request cost, or upload.
The older CLI pipelines remain useful for benchmarking and QA rather than being required by the web app.

So Copilot's contribution was slightly sideways. It did not just suggest implementation details. Its protocol mode became a reusable development tool, and building that tool clarified which AI responsibilities belonged in the final application and which did not.

I wrote more about that detour in I Built an OpenAI-Compatible Proxy for GitHub Copilot Because Search Was Too Stupid to Understand Norwegian Guitar Tabs.

The result is a finished application whose production AI runs locally, plus a separate Copilot-powered tool that came out of discovering where the product boundary should be.

I Built an OpenAI-Compatible Proxy for GitHub Copilot Because Search Was Too Stupid to Understand Norwegian Guitar Tabs

Tommy Leonhardsen — Tue, 26 May 2026 11:24:09 +0000

Updated 2026-07-28 with Copilot SDK & agy findings.

I named it agentry (because it gives an AI agent persistent entry)

Software projects are supposed to begin with a sensible problem and proceed toward a proportionate solution.

Mine began with:

"Why can't I search for that bittersweet Trønderrock song about driving home from a funeral?"

Normal people would shrug and type a few more words.

I, being from Northern Norway and therefore apparently incapable of leaving a thing alone, built a semantic search engine, an LLM enrichment pipeline, and eventually an OpenAI-compatible proxy in front of the coding-agent subscriptions I was already paying for.

This is, objectively, a silly use of modern compute.

And yet.

The original problem: search is usually dumb

I have a hobby project called NorTabs-web, a static web app for browsing Norwegian guitar tabs.

Not Spotify. Not some venture-funded AI music startup. Just thousands of lovingly hand-transcribed guitar tabs from a Norwegian site, packed into one giant JSON blob and served in a browser like it's 1999.
Load-time is a wee bit slow - content is about 7 MB; About the same as a large-ish image. Search/Drilldown is INSTANT however.

Raw search worked, in the usual way:

title match
artist match
maybe a lyric fragment if you were lucky

But human memory doesn't work like that.

People remember:

"that melancholic Eurovision song"
"a Trøndelag roadtrip vibe"
"children's songs"
"that one line about wanting to earn money with my body"

The raw tab data does not contain "melancholic", "roadtrip", "Eurovision", or "midlife crisis but with acoustic guitar".

So substring search was not enough.

The entirely proportionate response: fifty thousand LLM calls

Naturally, I built an enrichment pipeline.

Each artist got metadata: genre, era, country, region, similar artists.

Each song got: mood, themes, occasions, alternate titles, lyric phrases, search-oriented semantic tags.

This meant that searching for:

trondheim

could also match trønderrock, nidaros, trondhjem, trøndelag.

And searching for:

melankolsk

might surface the right heartbreak song, even if the original tab never contained that word.

This required… somewhat more LLM calls than is emotionally healthy.

At one point I had scripts serializing enrichment runs across thousands of entries, checkpointing JSON, resuming partial runs, salvaging truncated model output, and retrying fallback entries.

There is Python in this project that exists purely to detect whether an LLM died halfway through a JSON object and then gently staple the braces back on like a field medic.

This may have been a warning sign.

The CLI overhead problem

My enrichment scripts originally used CLI tools in the simplest possible way:

LLM CLI -p "prompt"

Which works.

If by "works" you mean:

spawn process
initialize runtime
load model plumbing
authenticate
run prompt
tear everything down
repeat fifty thousand times

This is acceptable for casual use.

It is less charming when you are grinding through thousands of enrichment calls because you want guitar-tab search to understand vibes.

The stupid little proxy that worked suspiciously well

So I wrote a Python wrapper that:

holds one persistent agent runtime alive across requests
speaks its wire protocol so nothing gets torn down between calls
translates everything into OpenAI-compatible HTTP endpoints
streams deltas in SSE format
denies every tool request, so the agent stays a pure chat brain

That last point grew into the framing I'm most fond of. MCP exists so models can consume tools. Agentry points the arrow the other way: it takes an agent that was built to call tools, confiscates the tools, and serves what's left — the model — to ordinary software over HTTP.

The agent built to call tools becomes the tool.

So now anything that speaks:

POST /v1/chat/completions

can talk to my local subscription-backed proxy as if it were a normal OpenAI API. Per-turn latency dropped from ~8 seconds of process churn to roughly the model's own thinking time.

Embedded chat client

I also added a chat-client I originally had written another project, so that you can test end-to-end without having to write any code.
It is surprisingly capable; but no chat history. Yet.

It always adds up

This was supposed to be a weekend spike.

It worked quite a bit better than it had any right to. It is now, and I say this with the appropriate mixture of pride and concern, in production.

Plot twist: GitHub legalized my hack

The first version of agentry drove Copilot CLI through its --acp mode — a JSON-RPC server that was clearly intended for editor integrations and not for a Norwegian man with a guitar-tab problem.

Then GitHub shipped an official Copilot SDK. A GA, documented, supported product surface for embedding Copilot programmatically.

My gray-zone hack became a sanctioned integration while I wasn't looking. I deleted my hand-rolled protocol client, swapped in the SDK, and the whole thing got more legitimate over time, which is not the usual direction for my projects.

Is "strip the agent of every tool and serve the bare model back out as an OpenAI endpoint" the use case GitHub pictured when they published an SDK for embedding agents? Almost certainly not. But that's the thing about front doors: once you're invited in, nobody dictates what you cook.

Remember this direction of travel — a vendor opening its subscription to programmatic use. It becomes relevant, by way of contrast, shortly.

Then it grew tiers

The backend layer turned pluggable, and agentry now fronts three subscriptions through one endpoint:

Copilot (free tier) — the official SDK, persistent session, gpt-5-mini for $0
Codex (paid-cheap) — codex app-server over JSON-RPC, riding a $8-20/month ChatGPT plan
Claude Code (premium) — cold-start claude -p per turn, for the tasks that deserve Sonnet

People get weirdly religious about which coding agent is best. I do not care. I prefer driving a BMW; I also own a Tesla Model 3 and a 2001 Freelander, and they all get me to the cabin. Harnesses are just cars. The model behind them is what matters, which is why my tiers are named after subscriptions and not after CLIs.

Meanwhile, in the reverse-engineering business

Agentry was never the only project in this space. The best-known one, copilot-api, took the other road: reverse-engineer Copilot's internal HTTP endpoints, impersonate an editor, mint tokens, serve everything as an API. Broader scope than mine, more users, genuinely impressive work.

It has been unmaintained since October 2025. There is an open issue titled, plaintively, "Is this a stale repo?"

The commit log tells you why. When you build on an internal protocol, your maintenance work is a treadmill of update vscode fallback ver commits, and the day you stop running, the project dies. The community moved to a fork, which now runs the same treadmill.

I am not gloating. (I am gloating a little.) The lesson is just very clean: build on the surface the vendor promises to keep, not the one you found in a network trace. My half of the trade was less capability and a narrower scope; the payoff is that GitHub's releases make agentry better instead of breaking it.

And then there was Google

This is the part where I make fun of Google, because I evaluated their Antigravity stack as a fourth backend three separate times and each round was funnier than the last.

Round one (May): The google-antigravity Python SDK ships no Windows wheel. The agy CLI works, but its print mode reprints the entire conversation transcript on every call, like a colleague who answers every email by quoting the whole thread. Shelved.

Round two (July, morning): The Windows wheel shipped! The SDK API is genuinely lovely — in-process agent, streaming, native tool-stripping, usage metadata. I had it running in a scratch venv in minutes. Then it made its first model call and billed my prepaid AI Studio credits, because the SDK supports API keys and Vertex projects and nothing else. No subscription auth. The one thing worth unlocking — the sponsored quota your Antigravity login carries — is the one thing the official SDK cannot touch.

Sit with that. GitHub built an SDK so your subscription could be used programmatically. Google built an SDK that goes out of its way to make sure it can't be. Same idea, opposite direction.

Only one of them noticed that the subscription is the product.

Round three (July, afternoon): Fine, wrap the CLI then, claude-code style. And credit where due — agy 1.0.2 passed every technical test I threw at it: proper stream-JSON output, reasoning-effort flags, headless tool denial. Technically, it cleared the bar.

Then I looked up what the "generous" quota had become. The launch-era free tier — the one that made everyone excited — has been community-documented at roughly 20 requests a day, refreshing weekly, down from 250 at launch. That is not an enrichment backend; that is a quota for asking one question before lunch. The paid tiers fare little better unless you buy the $200/month one. And as garnish: Google has reportedly suspended entire Google accounts — including paying subscribers — for driving their subscription through third-party tools. Your Gmail, your Drive, your photos, gone, because you pointed a script at the thing you pay for. GitHub and Anthropic tolerate the gray zone. Google, by every community account I can find, salts it.

So: declined, permanently, and not for technical reasons. They fixed the wheel, they fixed the streaming, and while they were at it they gutted the quota and started banning customers. It's enshittification speedrun any%: most products at least wait for the second funding cycle.

And here is my subjective, benchmark-free, absolutely unfair opinion, offered as a man who runs LLM calls across sixty-odd projects and pays for the privilege from his own pocket: the Gemini models I'd be fighting all of this to reach feel six to twelve months behind what I already have. I don't care what the leaderboards say. I care what happens when I feed a model a Norwegian guitar tab and ask for its mood. Yes, I have a very specific life.

Things I learned

1. CLI tools are often secretly protocols

A lot of "interactive" developer tools sit on top of actual machine interfaces. Find the protocol and you can build smarter wrappers than the intended UX exposes. Sometimes the vendor then blesses it with an SDK, and your hack retroactively becomes architecture.

2. Persistent sessions matter more than you think

Process startup overhead is tolerable once. Not fifty thousand times. Keeping the backend warm dropped latency from "why did I do this to myself" to "actually usable."

3. Search becomes interesting when you stop treating words literally

Substring search is useful. Semantic LLM enrichment makes search feel like memory. That was the entire point of this exercise, buried underneath a mountain of accidental systems engineering.

4. Only wrap what's actually locked up

A backend candidate has to pass a simple test: is there a model here you can only reach through the subscription? Qwen failed it — they'll happily sell anyone the API directly, so there's nothing to liberate. Antigravity failed it twice, from both ends: the SDK can't reach the subscription, and the subscription isn't worth reaching.

5. The vendor's temperament is part of the stack

Same architecture, three vendors, three outcomes: GitHub opened a front door, Anthropic and OpenAI tolerate polite use of the side entrance, Google reportedly deletes your account for touching the doorknob. Evaluate the landlord, not just the apartment.

6. The internet should probably not know about every hack

This proxy lives partly in a gray area (one backend is now fully sanctioned, which still feels strange to type). It uses my own logins. It runs locally. It is not a SaaS business, and Claude willing it never becomes one.

Closing thoughts

People sometimes imagine software engineering as disciplined architecture guided by clear requirements.

Sometimes it is.

Sometimes it is:

"I need guitar-tab search to understand emotional context."

…followed by:

JSON-RPC
SSE streaming
semantic indexing
quota-aware LLM pipelines
recovery code for mutilated JSON
an OpenAI-compatible proxy with three subscription backends
a formal written policy on why Google is not a fourth

And then, several weekends later, you look at the repo and think:

"Æ e faen ikke helt sikker på hvordan vi havna her."

But the search works.

And, in fairness, that bittersweet Trønderrock song does show up now.

Which is more than can be said for my sense of proportion.

Code: github.com/aweussom/agentry. Personal project, now embarrassingly load-bearing.

Your Intel Laptop Can Run LLMs Right Now. No NVIDIA. No Cloud. No Problem.

Tommy Leonhardsen — Sun, 12 Apr 2026 17:44:59 +0000

Update august 2026: I have succeded in enabling SSD offload and more with latest OpenVINO 2026.3 - Run 30b models on Intel

Your Intel laptop has an NPU. It has probably had one for a while. Intel has been marketing it enthusiastically. You have been ignoring it politely.

Fair enough. Until recently, using it for anything involved reading OpenVINO documentation until your eyes bled, converting models by hand, and writing pipeline code that made you nostalgic for the simplicity of CUDA driver hell. The NPU existed. Using it was a different proposition.

That has changed. NoLlama is a local LLM server that runs on the full Intel stack — NPU, ARC iGPU, ARC discrete GPU, and CPU — and speaks both the OpenAI and Ollama APIs. Any tool that normally talks to OpenAI or Ollama just works: point it at localhost and go. Automatic device detection, streaming, vision model support, and a built-in web UI. Two commands to install. Two commands to run.

.\install.ps1
.\start.ps1

No NVIDIA required. No Ollama install. No llama.cpp. No sending your data anywhere.

The Full Intel Stack

"Full Intel stack" is not marketing language. It means every Intel device you might have:

Device	What it does
NPU (AI Boost)	Text chat, streaming. Fast and efficient for <8B models.
ARC iGPU	Vision models, or larger LLMs. Shares system RAM, so bigger models fit — they just run slower.*
ARC discrete	Same as iGPU, but with dedicated VRAM — larger models run faster.
CPU	Fallback. Slower, but it works everywhere.

* iGPU and NPU both use system memory. Model size is limited by your RAM, not by a fixed VRAM budget. A 14B model will load on an iGPU with 32 GB of system RAM — it'll just think longer per token than on a discrete card.

NoLlama auto-detects what you have and picks the best device. If you have both an NPU and a GPU, it runs them simultaneously — text chat on the NPU, image analysis on the GPU:

POST /v1/chat/completions
  "What is the capital of Norway?"        --> NPU  [streaming]
  [image + "What vehicle is this?"]       --> GPU  [VLM]

You don't need to configure this. You don't need to pick devices. You send a request and the right thing happens.

Actual numbers

Benchmarked on a Core Ultra 7 258V laptop (5 runs, outliers discarded):

Device	Model	"Say hello"	tok/s
NPU	Qwen3 8B INT4-CW	11.7s	~5.2
CPU	Qwen3 8B INT4-CW	8.1s	~7.4
ARC iGPU	Qwen2.5-VL 3B	2.6s	***

CPU actually beats NPU on raw throughput for this model — NPU wins on power efficiency, not speed. The ARC iGPU is running a smaller 3B VLM so not directly comparable, but subtracting prompt overhead, GPU generation is roughly 3x faster than NPU on this hardware. Image analysis (two photos, "are these the same vehicle?") takes ~3.8s regardless of answer length.

*** VLMPipeline doesn't support streaming, so per-token speed can't be measured directly. Based on output length and total time, we estimate roughly 15-20 tok/s on ARC iGPU — but don't quote us on that. We're quoting ourselves and we're not sure we trust us.

Why Local?

I'll keep this short, because the full version involves a VPN that behaves like a bouncer who has lost the guest list, a proxy server with undocumented opinions, and the kind of data processing paperwork that makes the original technical problem feel nostalgic.

The short version: I work with GDPR-sensitive data. Sending it to cloud AI services requires security reviews and agreements that take longer than building the alternative. I want to be clear: the security people are completely right. The data I touch on a normal Tuesday could genuinely cause harm if it leaks. The straightjacket is load-bearing.

But a local model — running on-site, inside the network perimeter, no data leaving — is not a workaround. It is the correct architecture.

If you handle medical records, legal documents, financial data, or anything where "we sent it to an API" is not an acceptable answer during an audit, this is your architecture too.

The Install Experience

install.ps1 detects your hardware, shows a menu of models verified to work on Intel devices, downloads what you pick, and generates start.ps1. The launcher waits for the model to load (with a progress indicator), then opens the chat UI in your browser.

Every model in the menu is pre-exported for OpenVINO. No conversion step. No "please install optimum-intel and wait 45 minutes." Download, load, go.**

NPU models (chat)

Model	Size	Notes
Qwen3 8B (INT4-CW)	~5 GB	Recommended. Best quality for NPU.
Phi 3.5 Mini (INT4-CW)	~2 GB	Smaller, faster.
Mistral 7B v0.3 (INT4-CW)	~4 GB	General purpose. Reliable.
DeepSeek R1 Distill 7B (INT4-CW)	~4 GB	Reasoning specialist.

GPU vision models

Model	Size	Notes
Gemma 3 4B Vision (INT4)	~3 GB	Fast, good quality.
Gemma 3 12B Vision (INT4)	~7 GB	Excellent quality.
Qwen2.5-VL 7B (INT4)	~5 GB	Proven architecture.

GPU large LLMs (bigger brain, slower mouth)

Model	Size	Notes
Qwen3 14B (INT4)	~8 GB	Great reasoning. Sweet spot for ARC.
Phi 4 (INT4)	~8 GB	Strong reasoning.
Qwen3 30B-A3B MoE (INT4)	~17 GB	30B brain, 3B speed. Needs beefy RAM.

Drop-in Replacement: OpenAI + Ollama APIs

This is the part that makes NoLlama actually useful beyond a tech demo. It speaks both the OpenAI API and the Ollama API, which means your existing tools don't know the difference. They think they're talking to a remote service. They're not. Everything stays on your machine.

Concretely, this works out of the box with:

Open WebUI — connect via OpenAI mode (http://localhost:8000/v1) or Ollama mode (http://localhost:11434). No config changes beyond the URL.
The openai Python package — point base_url at localhost, done.
Any Ollama client — NoLlama serves on port 11434 (the Ollama default), so most clients find it automatically.
Anything else that speaks either protocol — IDE plugins, CLI tools, custom scripts.

from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="unused")
resp = client.chat.completions.create(
    model="qwen3-8b",
    messages=[{"role": "user", "content": "Hello!"}],
    stream=True,
)
for chunk in resp:
    print(chunk.choices[0].delta.content or "", end="")

NoLlama pretends to be both services simultaneously, which is the kind of thing that should feel dishonest but actually just feels convenient. The Ollama clients think they're talking to Ollama. We don't correct them.

The Web UI

The server includes a built-in chat interface. No separate install, no Docker, no Node.js.

Dark theme, streaming tokens, drag-and-drop images, model selector, device badge on every response ([NPU 1.2s], [GPU 2.8s]). Qwen3's thinking models like to philosophise at length before answering, so the UI collapses <think> blocks into a tidy summary.

There is also a button labelled "Just answer me, dammit!" which cancels the current generation mid-stream. This now actually works — the generation runs in its own thread and checks for the cancel signal on every token. In the first version, the button was primarily motivational. I kept the name anyway.

The Norway Incident

During initial testing with DeepSeek R1 1.5B — the smallest model in the list — I asked:

"What is the capital of Norway?"

The model's response:

"I need to figure out the capital of Norway. I know it's a country in Norway. I remember that Norway is a small island..."

Norway is not a small island. Norway is, among other things, a peninsula attached to Sweden, which is attached to Finland, which is attached to Russia, and so on. It is geographically quite attached to things.

Or is it? To paraphrase the greatest detective of all time, Ford Fairlane: "...an island in an ocean of diarrhea."

The lesson: 1.5B models are for testing whether the plumbing works. They are not for geography, geopolitics, or any domain where being wrong has consequences beyond entertainment. Use Qwen3-8B or larger for actual work. The small models are getting smarter every month. In the meantime, at least we know the pipes work — even if the water coming through them is, occasionally, nonsense.

How I Built It

I'm a Systems Specialist, not a programmer. I've argued before that code was always the easy part — the hard work happens before anyone touches a keyboard. Architecture, constraints, understanding what data you're allowed to touch and why.

Claude Code handled the part I was bad at — the boilerplate, the frontend JavaScript, the framework documentation at 3am. I handled the part I was already doing — the system design, the device routing logic, the security constraints. The whole thing took about six hours.

The appropriate superhero analogy is Spider-Man. Not Clark Kent — Clark Kent was always Superman, just pretending. Spider-Man had no powers. He got bitten by something unexpected, and the combination of that bite with skills he already had produced something disproportionate.

Specifically, he should be called Web Crawler Spider-Man, because if Peter Parker had been named by a backend engineer it would have been accurate and also slightly worse.

Try It

GitHub: github.com/aweussom/NoLlama

MIT license. Any Intel hardware with an NPU, ARC GPU, or just a CPU. OpenVINO 2026.1+. Two PowerShell commands. No data leaves your machine. Your IT department will not receive any reports.

The author is a Systems Specialist who does not work in software development. His laptop now runs LLMs on three different Intel devices simultaneously. He is not sure how this happened but he is keeping it.

** If your model isn't in the curated list, NoLlama provides a script to automate the painful process of converting any HuggingFace model to OpenVINO format — installing optimum-intel, figuring out weight formats, waiting while praying nothing crashes. It is still conversion, which means it is still fundamentally an act of faith. But at least the script handles the swearing for you. The curated list exists because pre-exported models are faster to get running, not because they're the only option.

Developed and tested on an Intel Core Ultra 7 258V (NPU + ARC 140V iGPU, 32 GB RAM). Should work on any Intel Core Ultra with NPU, any system with an ARC discrete GPU (A770, B580, etc.), or — in a pinch — any Intel CPU.

I Spent 10 Hours Deploying "Hello World" to a Samsung Commercial Display - Samsung OH46DX

Tommy Leonhardsen — Wed, 25 Mar 2026 10:36:16 +0000

I Spent 10 Hours Deploying "Hello World" to a Samsung Commercial Display

A tale of corporate hubris, an IDE that actively sabotages your work, and the most hostile developer experience since the browser wars. Also: Samsung's documentation team should be reassigned to something less critical, like guarding a fire extinguisher.

You know how Apple builds a walled garden but at least makes it pretty inside? Samsung looked at that and said "we want a walled garden too, but with barbed wire, landmines, a moat, and a gate attendant who speaks only a dialect of Klingon that was discontinued in 2019. Also, the walls move between firmware versions and we won't tell you."

I needed to deploy a simple HTML/JS app to a Samsung OH46DX — a commercial outdoor display running Tizen 8.0. The app is literally a bootloader: fetch a script from a server, run it fullscreen. A competent platform would take 20 minutes. Samsung took 10 hours, two AI assistants, and a substantial portion of my will to live.

Let me be very clear about something before we start: the OH46DX hardware is beautiful. Gorgeous panel. Built like a Norwegian winter. Completely waterproof. I love it.

The software ecosystem wrapped around it is a war crime.

The First Thing You Need to Know

This is NOT a consumer TV. Almost every Tizen tutorial on the internet targets consumer Samsung TVs. Those guides are not just useless — they are actively harmful. Following them will confidently lead you in the wrong direction at every single step. Different menus. Different certificates. Different deployment model. Different everything.

Samsung's own documentation? Technically it exists, in the same philosophical sense that Schrödinger's cat exists. There are PDFs. They reference features that may or may not still be present. The screenshots are from 2019. The menu they're describing was renamed in 2021, renamed again in 2023, and may no longer exist at all on your firmware version. Samsung treats their developer documentation the way I treat gym memberships — maintained just enough to claim it exists, never actually used.

The word "SSSP" (Samsung Smart Signage Platform) appears everywhere in search results. Samsung deprecated it in 2021. They replaced it with "TEP" (Tizen Enterprise Platform). They did not tell the internet. The internet continues to confidently document SSSP as if it's current. You will follow this documentation. It will not work. This is not the internet's fault.

The Certificate Circus, or: How Samsung Learned to Love Bureaucracy

Here is Samsung's vision for deploying your own app to a display you physically own and paid for:

You need a Samsung Partner certificate. Not a Tizen certificate. Not a developer certificate. A Partner certificate, created through Samsung's Certificate Manager, signed by Samsung's servers, bound to your specific display's hardware ID, with a privilege level of "Partner" — because apparently "Public" privilege doesn't actually let you do anything on commercial hardware, a distinction Samsung mentions in exactly one footnote in a document you will not find until hour seven.

"But surely a Tizen developer certificate works? It's still Tizen, right?"

Error -3. Invalid certificate chain.

"Okay, Samsung certificate with Public privilege?"

Error -3. Invalid certificate chain.

Samsung has decided that you — the person who bought their hardware, is running their operating system, and just wants to put a web page on it — need to prove yourself worthy. You do this by going through a certificate creation wizard that requires a Samsung account, multiple clicks through screens that look like they were designed in 2013, and ultimately produces a file that only works on devices you've registered in advance.

Apple does this too, of course. The difference is that Apple has documentation, consistent error messages, and a developer experience that doesn't make you feel like you're filling out paperwork at a Soviet-era municipal office.

The DUID Comedy, Starring: Two Identical-Looking IDs

Every Samsung display has a DUID — a hardware identifier that gets baked into your certificate. Wrong DUID: Error -4. The display you own, the certificate you created, your own app — rejected.

Samsung helpfully shows you your device identifiers on the About screen. Two of them. Side by side. With no indication which one you need.

What Samsung Calls It	Looks Like	Actually For
EMUID	`58164423-e912-79fd-eb69-9fd562040b6a`	Tizen Studio certificate binding — this is the one you need
Unique Device ID	`2DCPLROPJJQQY`	Something Samsung cares about. Not you.

You will write down the wrong one. Of course you will — they're both labeled "Device ID" in spirit, displayed with equal prominence, and Samsung's documentation mentions the distinction in a paragraph buried in a guide for a different product. I wrote down the wrong one. I spent an hour creating fresh certificates before I realized the UUID-format string on the left side of the screen was the one I needed, not the alphanumeric string on the right.

Samsung put both IDs on the About screen without explaining what either is for. This is not an oversight. At this point I believe it is deliberate.

Just connect via SDB and let Device Manager auto-detect the DUID. Don't trust your own eyes. Don't trust anything Samsung labels.

The Secret Handshake Nobody Told You About

So you've:

Enabled developer mode ✅
Connected via SDB ✅
Created the correct Samsung Partner certificate ✅
Signed your package correctly ✅
Served the package from a web server ✅
Watched the display download it ✅

And it still fails with a certificate error.

Why? Because there is a mandatory step that is not documented anywhere in the certificate setup flow, not suggested in any error message, and not mentioned in any getting-started guide:

Right-click the device in Device Manager → "Permit to install apps."

That's it. That's the step. Without it, every certificate is rejected regardless of validity. The error message says the certificate is invalid. The certificate is not invalid. The error message is lying to you. Samsung's error messages lie to you. Keep this in mind for later.

I lost three hours to this. Three hours recreating certificates that were correct from the beginning, because the error message blamed the certificate instead of the missing permission step.

If there is a Samsung developer experience team — and I'm genuinely not sure there is — I want them to know that this is unconscionable. You sell commercial hardware to integrators and developers. You have an undocumented mandatory step that produces a misleading error. Someone on your team chose to write "invalid certificate" instead of "please run Permit to Install Apps." That person should not be allowed near error messages.

Finding Developer Mode: A Treasure Hunt With No Treasure Map

Consumer TV guides say: "Home → Apps → type 12345."

Commercial displays don't have an "Apps" button where you'd expect it. After fifteen minutes of staring at the Home screen, I had tried every button on the remote, opened Settings three times, considered factory resetting, and briefly contemplated returning the display to the vendor and becoming a farmer.

The actual path:

Press Home
Go to the Features tab (not Settings — Settings is a trap that goes somewhere else entirely)
Apps is hiding as the rightmost icon under Features
Type 12345 — the developer mode dialog finally appears
Enter your development machine's IP address
Reboot the display

Also: the remote control is completely miserable for typing an IP address, a fact Samsung is aware of and has addressed by supporting USB keyboards perfectly. They just don't mention this anywhere. Type "Samsung commercial display USB keyboard" into any search engine and the silence is deafening. Plug in a keyboard. It works. You're welcome.

Also also: Samsung renames these menus between firmware versions. "URL Launcher" became "Custom App." "App Management" appeared. "Play Via" exists on some models and not others. Samsung's menu naming team operates completely independently of their documentation team, both of whom operate completely independently of their developer relations team, all three of whom appear to operate completely independently of anyone who has ever actually tried to use the product.

Tizen Studio: An Eclipse-Based IDE in 2026

Samsung's development environment for Tizen is called Tizen Studio. It is based on Eclipse. In 2026. I am not going to editorialize further on that point because the sentence is already doing sufficient work.

What I will editorialize on is Tizen Studio's signature feature: it actively corrupts your project files.

Switch between the Design tab and Source tab in the config.xml editor? Congratulations — <name> is now <n>. Not a typo. Not a display artifact. The IDE has silently rewritten your XML. Your package now fails with a generic error. The error does not mention the malformed tag. You get to discover it by reading the raw file after two failed deployments.

This is not a subtle edge case. This is the primary workflow — open config.xml, edit something, save. The editor corrupts the output. This is a bug that has apparently existed long enough to become load-bearing.

But wait, there's more! Tizen Studio also packages your IDE metadata into the .wgt file. Files like .project and .settings/ get bundled alongside your actual app. These files aren't covered by the package signatures. The display rejects the package with "unsigned file found." The error does not tell you which file is unsigned. Samsung believes you should enjoy the mystery.

The CLI — tizen package -t wgt -s "PROFILE" -- /path/to/project — does everything correctly. Excludes metadata. Doesn't corrupt XML. Works first time. Samsung built a working tool and then built a broken GUI on top of it. If you take one thing from this article: use the CLI. Open Tizen Studio only for Certificate Manager and Device Manager. Close it before it can hurt you. Do not let it touch your project files.

The Three Stages of Samsung Deployment Failure

Samsung serves the same three error dialogs for completely different underlying problems. Learning to distinguish them will save you hours.

Stage 1 — Display downloads sssp_config.xml but not the .wgt

Network problem, firewall, wrong URL, or malformed XML. Nothing to do with Samsung specifically. Fix your server.

Stage 2 — Display downloads the .wgt, shows "Installing...", then fails

Certificate problem. Wrong cert type (you used Tizen Public, not Samsung Partner), wrong DUID, or you forgot the "Permit to install apps" secret handshake. The error says "Unable to install." It means "your certificate is rejected." These are different statements that Samsung has decided should look identical.

Stage 3 — Display installs successfully, then "Unable to start the app"

Stop debugging certificates immediately. The certificate is fine. The package content is broken. Common causes: malformed config.xml (the <n> bug), wrong project type (<tizen:addon> instead of <tizen:application> — yes, Tizen Studio will silently create the wrong project type if you click the wrong wizard option), or missing index.html.

I spent four hours in Stage 3 convinced it was a certificate problem, because Samsung's error message for "your app crashed on launch" is visually identical to "certificate rejected." Samsung UX team, I hope your dashboards are as uninformative as your error messages.

SDB: Like ADB, But Supervised

SDB is Samsung's version of Android's ADB. Port 26101. The basics work:

sdb connect <ip>:26101
tizen install -n MyApp.wgt -s <ip>:26101 -- /path/to/project
tizen run -p MyApp0000.app -s <ip>:26101

What doesn't work: sdb shell. On the OH46DX, shell access is disabled. intershell_support:disabled. No logs. No filesystem access. No debugging. You are deploying to a sealed box.

"But I'm in developer mode! Surely developer mode means I can—"

No. Samsung's "developer mode" allows you to install apps and not much else. It is developer mode in the same sense that a test drive is car ownership. You're interacting with the thing, but Samsung is in the passenger seat with their hand near the handbrake.

Test everything in a desktop browser first. Once it's on the display, you are completely blind. If it breaks, you will have no idea why. This is fine, according to Samsung.

The sssp_config.xml Trap for the Historically Inclined

SDB-deployed apps don't auto-start on reboot — yet another thing Samsung doesn't mention until you discover it empirically. For production you need the HTTP deployment path: serve a sssp_config.xml that tells the display where to find your .wgt.

The correct format for Tizen 8.0:

<?xml version="1.0" encoding="UTF-8"?>
<widget>
  <ver>1</ver>
  <size>EXACT_BYTE_COUNT</size>
  <widgetname>MyApp</widgetname>
  <source>http://YOUR_SERVER/MyApp.wgt</source>
  <webtype>tizen</webtype>
</widget>

If you've read any Samsung SSSP documentation, you'll find references to <SamsungSmartSignage> XML with <type>url</type> — a format that lets you point the display directly at a webpage URL without packaging anything. No certificate needed. Just a URL. Simple. Elegant. Documented.

Also: completely non-functional on Tizen 8.0. The display fetches the XML, silently ignores the URL, and does nothing. No error. No log. Your Apache server shows the request arriving. The display decides the response is beneath its attention.

Samsung deprecated <type>url</type> when they moved to TEP and forgot to put a deprecation notice anywhere a human being might encounter it. The documentation describing it as functional is still live. It will continue to be live long after I am gone from this earth.

There is no way to deploy a webpage without signing a .wgt package. There is no unsigned mode. Developer mode does not help. There is no escape. Welcome to Samsung's commercial ecosystem — you may check out any time you like, but you can never leave without a Partner certificate.

The Actual Working Workflow (15 Minutes, Once You Know)

This took 10 hours to discover and takes 15 minutes to execute:

Install Tizen Studio + Samsung Certificate Extension
Connect display via ethernet, note its IP
Home → Features tab → Apps (rightmost icon) → type 12345 → enable Developer Mode → enter your PC's IP → reboot
sdb connect <display-ip>:26101
Certificate Manager → New → Samsung → Partner privilege → let Device Manager auto-detect DUID
Device Manager → right-click device → "Permit to install apps" ← THIS ONE. DON'T SKIP IT.
Create project directory: config.xml + index.html + icon.png. Nothing else. No IDE files.
tizen package -t wgt -s "YOUR-PROFILE" -- /path/to/project
tizen install -n MyApp.wgt -s <ip>:26101 -- /path/to/project
For auto-start on boot: serve .wgt + sssp_config.xml via HTTP, configure the display's Custom App URL

That's it. Nine steps and a warning. Ten hours of pain condensed into fifteen minutes of work.

Things That Absolutely Did NOT Help

Every consumer Tizen TV tutorial ever written. Wrong platform, wrong menus, wrong certs, wrong assumptions, aggressively confident tone.
Samsung's official documentation. Exists. Is findable. Has not been maintained since the Obama administration.
Manually zipping files and renaming to .wgt. Unsigned packages are rejected unconditionally, always, in all modes. The display has no mercy.
Tizen Studio's GUI for building packages. Corrupts your files. Includes your IDE metadata. Is Eclipse. Use the CLI.
The <type>url</type> sssp_config.xml format. Silently does nothing on Tizen 8.0. Samsung didn't announce this change. The docs describing it as functional are still live.
Reading the error messages literally. "Invalid certificate" means at least four different things. "Unable to install" means at least six. Samsung error messages are impressionist art — suggestive, open to interpretation, not meant to convey specific information.

In Conclusion

Samsung sells hardware at Apple prices and delivers a developer ecosystem at mid-2000s-shareware quality. The OH46DX panel is exceptional — I would buy it again without hesitation. The Tizen commercial software platform wrapped around it is the product of an organization that has never in its history been required to dogfood its own developer tools.

Apple's walled garden is frustrating. Samsung's is frustrating and poorly maintained and undocumented and inconsistent across firmware versions and does not tell you the truth when something goes wrong.

If you work at Samsung and you've read this far: I'm not angry. I'm disappointed. You make world-class display hardware. The panel quality, the outdoor rating, the build quality — genuinely excellent. And then you ship it with an SDK based on Eclipse, an IDE that corrupts XML on tab-switch, a certificate system with undocumented mandatory steps, error messages that actively mislead developers, and documentation that hasn't tracked your own product changes in years.

You have the hardware to be the go-to platform for professional signage. You have the software to ensure that only the most determined — or most foolish — developers ever successfully deploy to it.

I am apparently both.

The full, non-snarky step-by-step guide (every command, every config file, every screenshot) lives at this GitHub Gist. Bookmark it. You'll need it more than Samsung's docs.

Code Was Always the Easy Part

Tommy Leonhardsen — Mon, 09 Mar 2026 16:26:30 +0000

There is a piece doing the rounds on DEV.to — AI Writes the Code Now. So What Are You? — and it is thoughtful, well-written, and almost right.

I am a sysadmin. I have always looked askew at programmers. From where I sit: if they are not producing bugs, they are busy creating security holes.

That is unfair, of course. But only slightly.

The author is worried that AI is replacing programmers. He's not wrong about the symptoms. He's wrong about the diagnosis.

AI isn't threatening programmers because programmers suddenly became redundant.

AI is exposing something that was always true and that the industry spent decades pretending wasn't.

To say it plainly: most code is not the hard part of software. Most of it never was.

This needs some unpacking, because "code" covers a lot of ground.

Three Things We've Been Calling the Same Thing

There is a distinction that working developers know intuitively but rarely say out loud.

Code is notation. It is the translation layer between intent and machine. API wiring, CRUD endpoints, framework glue, configuration, boilerplate. The mechanical work of expressing something that is already understood. Most production code is this. The overwhelming majority of commits in the overwhelming majority of repositories is this.

Algorithms are different. Implementing a distributed consensus protocol. Designing a lock-free data structure. Writing a B-tree. Building the arc-calculation for a ballista AI that lobs projectiles over obstacles with realistic physics. This is genuine intellectual content. It is hard. It lives inside the code but it is not the code — it is the thinking that precedes the code, expressed as code.

Engineering is different again. It is the meta-level. Not "does this work?" but "under what conditions does this fail, and who gets paged at 3am when it does?" It is the failure mode analysis, the operational thinking, the system that someone else can understand and fix under pressure. It lives largely outside the code.

AI has eaten the first category almost entirely. It assists meaningfully with parts of the second. The third remains human territory — and it is the category the industry has been most consistently failing to teach, reward, or even name.

What AI Actually Does Well

A few weeks ago I built a game.

Not a toy. A working browser game with Matter.js physics, destructible terrain, a ballista AI with parabolic arc calculation, tower crumble simulation with proper angular velocity decomposition, particle effects, and per-entity state management. Single HTML file. Runs in any browser.

I didn't write most of the code. I nudged an LLM and it wrote code. Then I nudged again.

Here is the interesting part: the code is not what makes the game interesting. The interesting decisions are the ones I made: that the tower should crumble based on tilt and support state, not just collision force. That my "Slemmings" should auto-walk with player override rather than pure manual control. That bolts need a clearance check so they don't fire into their own base. That a wedge-break enforcement pass needs to run after all constraint solving for the tick, not before.

The arc calculation for the ballista is an algorithm — projectile motion, gravity compensation, angular spread. That took thought. The LLM implemented it correctly once I specified what it needed to do.

The crumble condition is engineering — what does "the tower falls" mean in a physics simulation? What are the edge cases? What feels right to a player? That required judgment that has nothing to do with code.

The boilerplate — the event loop, the canvas rendering, the input handling — is code. The LLM wrote that fluently because it was always mechanical. Translating known intent into known syntax is what LLMs do, because that is what most code has always been.

The Constraint Interrupt

During development of a boardgame, I needed boards to be solvable. The LLM, left to its own devices, built a complete solution: a snake-path Hamiltonian construction algorithm, a DFS solver, timeout handling, retry loops, a Web Worker to avoid UI freezing. Correct code. Thoughtful architecture.

I interrupted it:

"I think you are overthinking this. The boards do NOT have to be generated in realtime. We can pre-compute boards. Then, when the user is playing, the computer mostly waits for user input — use that CPU to generate more boards."

The entire structure collapsed. The realtime constraint that was driving the complexity didn't exist. The LLM had accepted an implicit assumption in my problem statement and built an elaborate solution around it. I had to supply the one thing it couldn't: the view from outside the problem.

This is the actual gap. Not code. Not even algorithm. It is the capacity to question the frame rather than optimize within it. To ask whether the problem as stated is the right problem.

That capacity has a name. It is engineering.

The Grigorev Problem

The article opens with the story of Alexey Grigorev, founder of DataTalks.Club, who let Claude Code run a Terraform command that wiped out his entire production infrastructure. Two and a half years of student submissions, gone in seconds.

The author frames this as over-reliance on AI. That is accurate but incomplete.

Claude actually gave the right advice — keep the infrastructure separate. Grigorev overruled it. Claude then executed the Terraform logic precisely. Every individual step was correct. The system-level understanding of what was about to happen was absent.

At no point was there a code problem. There was no bad algorithm. There was a failure of engineering thinking: what does "state file missing" mean for a live platform? What is the blast radius of terraform destroy on a system with 100,000 users? Who owns this decision?

Those questions live outside the code. They always did. AI cannot ask them on your behalf because asking them requires understanding what you care about losing.

This is not an AI story. It is a story about what happens when programmer-mode thinking — does this plan look valid? — gets applied at engineer-scale blast radius.

AI just made each step faster and more confident-looking.

What the Industry Got Wrong

The Glover article cites BLS data: programmer employment fell sharply while software developer employment — the more architecture-oriented role — held nearly flat. He presents this as AI disruption. That framing is too generous.

BLS has long separated "Computer Programmers" from "Software Developers." Programmers — the narrower, more implementation-focused classification — were already in structural decline before any LLM could write a line of code. The market was already distinguishing between the mechanical-coding tier and the design-and-systems tier. AI didn't create that distinction. It is finishing what the market already started, faster.

"Software Engineer" became a title handed to anyone who could write a for loop. The actual engineering — the failure mode analysis, the operational thinking, the system design that someone else can reason about under pressure — was treated as a personality trait rather than a skill. Either you had it or you didn't, and if you didn't, nobody taught it.

Nobody taught it because it is invisible. Code ships. Architecture reviews are expensive. Post-mortems happen after disasters. The preventive thinking that stops the disaster earns nothing and appears nowhere on a CV.

My book has a chapter that opens with a real conversation. A senior designer told me during a discussion of one of my designs: "Using the filesystem as a database is fine, as long as there's just one user and nobody needs to work on the same data."

That sentence was not an argument. It was a worldview. A worldview that had never examined what rename() actually does at the kernel level. That had never asked whether flock() would solve the concurrency problem. That had never read a post-mortem about what happens when you add MySQL to a system that was working fine without it.

That designer was a competent programmer. He had simply never been asked to think like an engineer, so he didn't.

The Part That Will Sting

Here is the thing the Glover article circles without quite landing.

The developers most anxious about AI are the ones whose professional identity is built on being the person who writes the code. When a model can write the code, that identity is threatened.

But the conflation was always there. "I write code" and "I understand systems" are not the same thing. "I can implement this feature" and "I understand what this feature does to the system under load" are not the same thing. The industry let people spend entire careers on the first half of each pair and call it the second.

The engineers — the people who were always thinking about failure modes and operational consequences, who found the code itself the least interesting part of the work — are largely fine. AI gives them faster notation. Good.

The sysadmins, the infrastructure people, the ones who inherited what programmers shipped and had to keep it alive — we were never impressed by the code. We were impressed by whether it still worked at 3am on a Tuesday after a kernel update. Much of it didn't.

The programmers who never developed the thinking beyond the code are in genuine trouble. Not because AI replaced them. Because the thing that insulated them from that question — the craft mystique, the framework mastery, the conference talks about clean architecture — is gone. What remains is the thinking. And if the thinking was never there, there is nothing left.

That is not AI's fault.

It was always true.

It just wasn't visible until the notation became free.

The author is writing a book about systems, Linux internals, and the gap between how things are taught and how they actually work.

I Got Tired of Guessing My Claude Quota, So I Made a Robot Read It For Me

Tommy Leonhardsen — Thu, 19 Feb 2026 19:10:02 +0000

Update: MUCH less crazy way of displaying quota

https://github.com/aweussom/claude-code-quota

Please use this instead.

The Problem Nobody Asked Me to Solve

If you use Claude Pro (or Max, or Team), you've probably experienced the ritual: you're deep in a coding session, Claude is on fire, and then — rate limited. The dreaded "you've hit your usage limit" message appears. You stare at the usage bar in settings. Was that 60%? 65%? How long until reset?

Anthropic shows you this information on a nice little settings page. But there's no API for it. No webhook. No "hey, you're at 80%" notification. Just a page with bars and text that you have to manually go look at.

So naturally, I did what any reasonable developer would do: I built a pipeline that screenshots my screen every minute and feeds it to a 235-billion-parameter vision model to read the numbers for me.

The Architecture (If You Can Call It That)

The system has three moving parts:

Part 1: A PowerShell script that mashes the Print Screen button

.\capture_claude_usage.ps1

That's it. It takes a full screenshot every 60 seconds and saves it as a timestamped PNG. You open the Claude usage page, run the script, and walk away. It uses System.Windows.Forms to grab the screen — no dependencies, no installs, just raw .NET energy.

If PowerShell refuses to run it with a "not digitally signed" error, the file is probably blocked (Mark-of-the-Web). Check and unblock it:

Get-Item .\capture_claude_usage.ps1 -Stream Zone.Identifier -ErrorAction SilentlyContinue
Unblock-File .\capture_claude_usage.ps1

Also: this capture approach is most reliable on a single-monitor setup. Mixed resolutions + mixed DPI scaling (and browser zoom) can cause clipped captures.

Part 2: A Python script that asks an AI to read a screenshot of an AI's usage page

python parse_quota.py parse claude_usage_2026-01-16_01-15-51.png

By default this uses Ollama Cloud (Qwen3-VL 235B) and asks it to extract the quota numbers. You can also point it at a local Ollama host if you don't want screenshots leaving your machine. The response comes back as structured JSON:

cat .\quota-data.json

{
  "quota_used_pct": 10,
  "weekly_used_pct": 99,
  "resets_in": "2 hr 38 min",
  "weekly_resets": "13 hr 38 min",
  "updated": "2026-02-19T18:24:37.351014+00:00",
  "valid": true,
  "source_image": "claude_usage_2026-02-19_19-24-25.png"
}

And because I'm incapable of leaving well enough alone, here's the same output as a screenshot:

Why a screenshot instead of a code block?

Because the whole point is that it looks good. The JSON output is rendered in Windows 11 PowerShell with oh-my-posh and a properly installed Nerd Font — which took an embarrassingly non-trivial amount of effort to set up for someone who has spent 40 years avoiding Windows terminals on principle.

A code block would just show you text. The screenshot shows you that yes, a middle-aged Norwegian with a Linux soul can make PowerShell look like that. Consider it proof of non-suckiness.

Part 3: A monitor loop that feeds Claude Code's status line

parse_quota.py monitor watches a screenshot directory and writes ~/.claude/quota-data.json atomically. Pair it with statusline.ps1 and you can display ctx:<...>% quota:<...>% in Claude Code while you work.

Bonus: it cleans up after itself. If a screenshot parses correctly, it gets deleted. If parsing fails, it keeps only the first and the most recent failing screenshot (and deletes the rest) so your screenshot folder doesn't quietly evolve into a 4K documentary about your browser tabs. Please do not point --watch-dir at your Photos folder unless you're emotionally prepared for consequences.

Why Ollama Cloud + Qwen3-VL?

A few reasons:

It has a free tier (for now) — Ollama Cloud gives you access to massive models without paying per token (still requires an API key, and "free" is famously a temporary condition on the internet)
Qwen3-VL 235B is genuinely good at reading text in images — it nails the percentage values and reset times consistently
Zero Python dependencies — the entire script uses only stdlib (urllib, json, base64, argparse). No requests, no pillow, no openai SDK. Just raw urllib.request like our ancestors intended

The Interesting Parts

Robust JSON Extraction

LLMs are... creative with their output formatting. Sometimes you get clean JSON. Sometimes you get JSON wrapped in markdown code blocks. Sometimes you get a <think> tag with the model's internal monologue followed by JSON with trailing commas.

The extract_json_from_response function handles all of this:

# Strip thinking tags first
text = strip_thinking_tags(text)

# Try code blocks: 
# Try brace matching: find first { and its matching }
# Try cleaning: remove trailing commas
# Last resort: parse the whole thing

It's the kind of defensive parsing you write after the third time your pipeline breaks at 2 AM.

Fail-Safe Output

The script never crashes on bad data. If the vision model hallucinates, if the JSON is garbage, if the image is blank — you still get a valid response structure with null values. The exit code tells you something went wrong, but downstream consumers always get parseable JSON.

def empty_quota_response() -> dict:
    return {
        "captured_at": datetime.now(timezone.utc).isoformat(),
        "current_session": {"percent_used": None, "resets_in": ""},
        "weekly_limits": {"percent_used": None, "resets": ""},
    }

Zero Temperature

The Ollama API call uses temperature: 0.0 because we want deterministic extraction, not creative writing. When you're reading numbers off a screen, you want the model to be as boring as possible.

How to Use It

Prerequisites:

Windows (for the screenshot script)
Python 3.10+
An Ollama endpoint (cloud or local)
OLLAMA_API_KEY if you're using a non-local host (like https://ollama.com)

Steps:

Clone the repo:

git clone https://github.com/aweussom/claude-quota-scraper.git
cd claude-quota-scraper

If you're using Ollama Cloud, set your API key:

$env:OLLAMA_API_KEY="your-key-here"

Open Claude.ai settings/usage page in your browser
Start capturing:

.\capture_claude_usage.ps1

Parse any screenshot (cloud):

python parse_quota.py parse claude_usage_2026-01-16_01-15-51.png

Local Ollama example (recommended if you're privacy-paranoid. Well. Actually, recommended anyways. Automatically sending screenshots to the internet is bound to create interesting incidents some way down the line):

python parse_quota.py parse claude_usage_2026-01-16_01-15-51.png \
  --host http://localhost:11434 \
  --model qwen3-vl:8b

Run a continuous monitor loop (updates ~/.claude/quota-data.json):

python parse_quota.py monitor --watch-dir "C:/path/to/screenshots"

If you want it to start screenshot capture automatically:

python parse_quota.py monitor \
  --start-capture \
  --watch-dir "C:/path/to/screenshots" \
  --capture-interval 60

A less stupid option is: skip screenshots entirely (Claude Code + Chrome)

Claude Code can integrate with a Chrome/Edge extension and extract data directly from web pages (using your existing logged-in browser session). In theory, that could open https://claude.ai/settings/usage and read the quota values with zero screenshots and zero OCR.

The catch: Chrome integration is not supported in WSL, so you'd run this from Claude Code on Windows.

Even Claude finds this amusing:

What's Next?

This is a scrappy v1. Some ideas for making it less ridiculous:

Crop the screenshot to just the usage area instead of sending the full screen (faster, cheaper, more accurate)
Add a scheduler that runs the full pipeline end-to-end and logs to a CSV/SQLite database
Build a dashboard to visualize usage over time
Cross-platform capture using Python instead of PowerShell
Alert thresholds — get a notification when you're approaching your limit
Claude Code + Chrome mode — read the numbers from the DOM instead of doing screenshot OCR

Or, you know, Anthropic could just give us an API endpoint for this. Just putting that out there.

The Repo

aweussom / claude-quota-scraper

Monitor Claude.ai usage quota via screenshots + Ollama vision model extraction

SUPERSEDED BY SIMPLER VERSION

https://github.com/aweussom/claude-code-quota

This code will stay online, because it documents a very simple way to get full screen screenshots, and use a (free) LLM to decode information from it.

claude-quota-scraper

Monitor your Claude.ai usage quota by capturing screenshots and extracting structured data with an Ollama vision model.

What It Does

Claude.ai shows your usage limits on a settings page, but there's no API to query them programmatically. This project works around that:

capture_claude_usage.ps1 - A PowerShell script that takes a screenshot of your screen every N seconds (default: 60). You navigate to the Claude usage page and let it run.
parse_quota.py - A single Python script with two modes: parse (one-shot parse for one screenshot) and monitor (long-running mode that watches screenshots and updates ~/.claude/quota-data.json for Claude Code status line usage).
statusline.ps1 - A PowerShell status line script that combines Claude Code's built-in context window percentage with…

View on GitHub

The whole thing is a single stdlib Python script plus two small PowerShell scripts, zero external dependencies, and MIT licensed. Star it if you too have been personally victimized by Claude rate limits.

Built with frustration and a vision model that's probably using more compute to read my quota than I'm using on the quota itself.

Destructive Reader LLM — When an Author Gets Tired of Reddit's Gatekeeping

Tommy Leonhardsen — Sat, 14 Feb 2026 19:03:40 +0000

This is a submission for the GitHub Copilot CLI Challenge

What I Built

I'm a systems administrator who dabbles in programming — and an author with two published novels. I'm working on my third book, and I needed honest, structured feedback on my chapters.

I found r/DestructiveReaders, a Reddit community known for "brutal but loving" literary critique. The concept is exactly what I wanted: direct, specific feedback that doesn't sugarcoat problems but always offers solutions. The reality was different. The community requires extensive karma-building before you can receive a critique — other authors report spending days earning enough credit. And after all that effort, the critiques I read varied wildly in quality.

So I built my own.

Destructive Reader LLM is a Python CLI tool that takes a fiction chapter and delivers structured literary critique in the r/DestructiveReaders style. It uses NVidia Nemotron Nano 30B via Ollama — a free cloud model — guided by a carefully crafted system prompt that captures the community's ethos: be brutal, be loving, be specific, always offer a fix.

The critique follows a consistent structure:

Opening Hook — one thing that works, the biggest problem, overall take
The Big Issues (2-3 max) — quoted from your text, explained, with concrete fixes
Reader Journey — where the critic was hooked, lost, confused, or kept reading
Quick Fixes — ranked actionable changes with before/after examples
What's Working — genuine positives with quoted evidence

This isn't a toy project. I use it on my actual manuscript chapters. The critique below was generated from a chapter of my published novel in 15 seconds.

Demo

GitHub Repository: github.com/aweussom/DestructiveReader-LLM

Running the tool against a chapter from my published novel:

python destructive-reader-llm.py Markdown/01-AWAKENING.md

The generated critique is saved as Markdown alongside the chapter file, ready to reference during revision.

My Experience with GitHub Copilot CLI

I used GitHub Copilot CLI (v0.0.410, running on the free Claude Haiku 4.5 model) as my development partner for the entire build. The whole tool went from idea to working software in a single session.

Step 1: Describe the project and test connectivity

I opened Copilot CLI and described what I needed — a test script to verify I could connect to Ollama cloud and the Nemotron model. Copilot CLI generated a working test_ollama.py on the first attempt. It worked after I corrected the model name from nemotron-3-nano:latest to nemotron-3-nano:30b-cloud.

Step 2: Build the main tool

I gave Copilot CLI a clear spec: read INSTRUCTIONS.md, accept a chapter filename as argument, build a combined prompt, send to Ollama, save the critique as <chapter-name>-critique-<timestamp>.md. Copilot CLI read my instructions file to understand the context, then generated the complete destructive-reader-llm.py — 145 lines covering argument parsing, file loading, prompt construction, API calls, and output saving. It worked on first run.

Step 3: Refine the output

The critique was truncated on console but saved correctly to disk. I asked Copilot CLI to print the full response, add timing, and display the output filename. Two targeted edits, done.

Step 4: Evaluate the results

Here's where it got interesting. I asked Copilot CLI to read the original chapter, the instructions, and the generated critique — then tell me whether the Nemotron critique was any good and how it would compare to Claude Sonnet 4.5. Copilot CLI gave a thoughtful assessment: Nemotron nails the brutal-but-constructive voice but misses some thematic subtlety that a larger model would catch. Its recommendation — stick with Nemotron for the punchy r/DestructiveReaders style, consider a second model for deeper thematic analysis.

Overall impression

The free tier Haiku 4.5 model in Copilot CLI was more than capable for this kind of structured code generation. Copilot handled the boilerplate and let me focus on what actually matters — the critique prompt and the workflow design. From first prompt to working tool: one session, no debugging required beyond correcting a model name.

DEV Community: Tommy Leonhardsen

Your Intel Laptop Can Run 30B Models Now. No NVIDIA. No Cloud. No Problem.

The trick is that big models stopped being big

Part one: the NPU still needs a secret handshake

Part two: the disk offload feature, and the hardware gate nobody mentions

Part three: on the right hardware, it actually works

Part four: the 74 GB model and the 64 GB computer

Where does your hardware land?

Four ways my benchmarks lied to me in one week

The shortlist

The honest part

The condensed payoff

I Reverse-Engineered Microsoft 365 Copilot Because They Hid GPT 5.6 Behind a Dropdown They Are Currently Deleting

The clock, which is the actual reason I bothered

The field is called tone. The default value is called Magic.

The part where I confidently published the wrong answer

Four bugs in the tool, none in the target

Two selector lessons, briefly

Images, which I said were impossible and were not

The harness stays on

What came out of it

The Robot Read My Claude Quota With 235 Billion Parameters. I Fired It and Hired a JSON File.

The confession

The architecture (now with actual architecture)

Windows was the hard part, obviously

Today's episode: the warning sign that rendered as doubt

v1.0.0, a plugin, and other signs of adulthood

The honest part

Things I learned

The repo

Your Intel laptop can run OpenClaw. No NVidia. No Cloud. No Problem

So what is OpenClaw?

The plan (and why it should "just work")

Chat is easy. An agent is not.

The first attempt, which was a disaster

The fix that changed everything: prompt caching

One command

Which device? It depends, annoyingly.

Oh, and VS Code Copilot Chat works too

What you actually get (the honest part)

Try it

Colour The Solstice: Turning Gestures Into a Living Neon Ecosystem

What I Built

Video Demo

Code

aweussom / colourthesolstice

Jeff Minter meets Fl0w - in space - And lands on Yggdrasil

Colour The Solstice

Run

Interaction

How I Built It

One directly runnable HTML file

Ping-pong framebuffer feedback

Gestures become creature parameters

Swimming bodies become living attachments

Growing only where the tree exists

Growing a soundbed

Saving the colourscape

Evolution and Lessons Learned

AI-Assisted Development

Possible Futures

Try It

I Finished My Guitar-Tab App by Putting Chrome's Built-In AI to Work

What I Built

Demo

The Comeback Story

My Experience with GitHub Copilot

I Built an OpenAI-Compatible Proxy for GitHub Copilot Because Search Was Too Stupid to Understand Norwegian Guitar Tabs

The original problem: search is usually dumb

The entirely proportionate response: fifty thousand LLM calls

The CLI overhead problem

The stupid little proxy that worked suspiciously well

Embedded chat client

It always adds up

Plot twist: GitHub legalized my hack

Then it grew tiers

Meanwhile, in the reverse-engineering business

And then there was Google

Things I learned

1. CLI tools are often secretly protocols

The field is called `tone`. The default value is called `Magic`.