Harness Corp: a game about making a 0.6B model useful

Developer Tom (creator of WorldTUI) released Harness Corp, a browser-based incremental game that runs Qwen3-0.6B locally via WebGPU and tasks players with building harness upgrades — such as a $20 Input fence, JSON mode, an add_days tool and an EU Prompt-Writing Licence — to make the fixed 0.6B model reliable on data-extraction jobs. The game is built on a roughly 600-line WGSL and TypeScript custom WebGPU inference engine that keeps weights in int4, adopted after WebLLM failed on Firefox because that browser allowed only 9 storage buffers per shader where WebLLM needed 10. Testing Qwen3-0.6B's failure modes produced the upgrades: wrapping inputs in <email> tags fixed few-shot examples leaking into answers (pass rate had dropped to 0%), and the prompt line "one tool call is enough" raised tool-calling pass rates from 40% to 70%.

TL;DR: Harness Corp is an incremental game in which Qwen3-0.6B runs directly in your browser, and it's up to you to make it useful. You buy harness parts, run evals, and gradually automate more and more of your work. Play it here 358 MB download https://simedw.com/projects/harness-corp . It requires WebGPU. Desktop Chrome or Edge works best, but I've done my best to get it working on mobile and Firefox too. While working on WorldTUI https://simedw.com/2026/10/21/world-model-terminal/ , I started experimenting with various small language models running in the browser. It reminded me of the early days of LLMs, when prompt engineering was half the battle and getting a model to produce valid JSON felt like a major achievement. Eventually, I decided to turn this into a small game. There are spoilers from this point onwards, so I'd recommend giving the game a try first. The premise You've started a company, and naturally, the board wants it to be AI-native. But legal can only sign off on running Qwen3-0.6B locally. The company receives a stream of increasingly difficult data extraction tasks. It starts with things like extracting names and dates from emails and moves on to invoice totals with VAT exceptions. Every task can be done manually, but you will quickly want to delegate it to your digital coworkers. Every completed task earns money. Unfortunately, running your imaginary GPU cluster costs electricity, so you need to make enough money to keep the lights on. As you earn more, you can buy harness upgrades like JSON mode or an add days tool to make the model more reliable. Run evals to see whether things actually improved, and finally automate yourself out of a job. The base model stays fixed throughout, for practical reasons. You're just building increasingly elaborate machinery around it. And if you buy the EU Prompt-Writing Licence , you can write your own prompts What a 0.6B model gets wrong Before building the game, I tested how Qwen3-0.6B fails on these tasks. Most failures ended up becoming upgrades you can buy. Here are some of them. The example makes it worse. Few-shot prompting is a well-established technique, but with smaller models you need to be careful about how you structure the examples. Otherwise, the model might start copying from them, and the pass rate can drop to 0%. It even copied the example inside a rule: write "e.g. Ali Khan", and Ali Khan started showing up in the answers. The way around this was to wrap the emails in <email tags. In the game, this is the Input fence upgrade, and it costs $20. It can't stop calling tools. When I gave it a tool for the date extraction tasks, the first call was almost always correct. But then it kept calling, until it eventually got the answer wrong. One prompt line, "one tool call is enough", increased the pass rate from 40% to 70%. The game lets you go one step further by buying the ability to halt after the first tool call. Leading questions. I asked it to look up where each order's customer was based, with the question "...is this customer based in Japan?". It answered "Country: Japan, yes" for every order, even right after the lookup tool said Germany. You can buy a code tool that validates the location, which completely solves this problem. The fix for most of these follows the same pattern: let the model read, and let the code decide. Running Qwen3 in the browser The obvious choice for running Qwen3 in the browser was WebLLM https://github.com/mlc-ai/web-llm , and it worked brilliantly until I tried it in Firefox. Apparently, Firefox only allows 9 storage buffers per shader on the configuration I encountered, and of course WebLLM needed 10. 1 fn:1 There might have been a way to fix this in WebLLM, but I took this as an excuse to use the custom WebGPU inference engine from WorldTUI https://simedw.com/projects/worldtui . It only needed some adaptation. It's roughly 600 lines of WGSL and TypeScript. It keeps the weights in int4, dequantizes them in the shader, and does the computation in fp32. It never binds more than 6 storage buffers I still haven't implemented constrained decoding, so Firefox users don't benefit from the JSON mode upgrade, sorry Chrome and Edge still use WebLLM, since it has constrained decoding; Firefox gets my engine. The custom engine is a little slower to produce its first token, but considerably faster at generating subsequent tokens. Since most prompts in the game are under 500 tokens, the difference in startup time hardly matters. Summary I find the idea of games with their own small neural networks quite interesting. Not just using AI to generate assets, but making the model itself part of the game mechanics. As computers get more powerful and models get smaller, I suspect we’ll see more games shipping with their own models. Harness Corp is a small experiment in that direction. It's a little ridiculous, but I had a lot of fun building it. 1. The WebGPU standard only guarantees 8 storage buffers per shader. ↩ fnref:1