DEV Community: Tommy Leonhardsen

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.