ned Productions - Friday 04 September 2026

18:17.

Word count: 4583. Estimated reading time: 22 minutes.

Summary:: The use of multiple AI coding agents is described. Token costs and the Jevons’ Paradox are analysed. Three projects are detailed: ISO wording, a WebAssembly-based Python environment, and a secure container for unsupervised LLMs. Various subscription services are compared to minimise expenses. Finally, personal updates regarding construction and family are shared.

For the past month I have had three AI coding agents busy running in parallel in the background to implement three things I’ve been working upon – sometimes I stretch to four concurrent things, but to be honest the context switching for that gets a bit head hurty, so I tend to find three concurrent things is enough. What I do is when I wake up in the morning as I’m drinking the morning coffee, I review each of their work from the night before. I write out feedback and direction for their next iteration but don’t send it yet as before 11am it costs twice as much per token, but after 11am I set them running. I then revisit them throughout each day, and I generally give them final instructions before I go to bed around 11pm or so. They have been given strict instructions to finish up before 2am, when the per-token rate doubles again (why twice the price between 11am and 2am? That’s because in China which is UTC+8, that would be 6pm until 9am, so the off-peak rate is outside Chinese business hours).

All three AI coding agents have been running Deepseek v4 Flash 0731 (DSv4F) which I reviewed in depth last entry and that has raised a new problem: cost.

Economics 101: Good Old Jevons’ Paradox

The Jevons’ Paradox is when technological improvements increase the efficiency of using a resource, when then paradoxically leads to a rise rather than a fall in the total consumption of that resource. This is due to elasticity of demand: when a thing becomes much more useful for a given cost, total consumption rises. This has been very much the case for me and LLMs during the month of August:

It’s actually even worse than the above: I burned a further two billion tokens on Opencode Go which is a US$10/month subscription – I ate the entire month’s allowance in three days which was the 23rd, 24th and 25th of August:

You can see on the 1st August my last use of Step 3.7 Flash, which had been the previous Pareto optimum, and that use was for the previous diary entry. Since then, it’s been almost nothing other than DSv4F.

I seem to get through at least 200 million tokens per day, with my worse case day so far being an astonishing 1.35 billion tokens when I had it go off and research ‘what would be the ideal LLM programming language?’ (the answer: Python, followed by C and quite some distance later, Rust – yes I was surprised too):

During the month of August, I reckon I paid about US$0.00865 per million tokens (it’s easier to say US$8.65 per billion tokens). That’s after Deepseek doubled their prices – they were half that cost again originally. As I’ve gotten better at minimising uncached token parsing which is the expensive part, I daresay the wholesale cached read token price of US$7 per billion tokens will get closer. Deepseek v4 Flash remains – for now – by far and away the Pareto optimum for my use case which is very heavy on cached read tokens: as of end of August 2026, only MiMo-v2.5 has cheaper cached read tokens at US$2.8 per billion, and it’s not clever enough to be left to run for hours without supervision (that said, I think there is a cost reduction strategy there which I’ll be coming back to later).

I’m not keen on spending US$100 per month on LLMs especially in my current zero-income circumstances, so I have been casting around looking for cheaper tokens. Deepseek themselves are unusual in that they offer no direct to consumer subscription, they appear to offer subscription pricing via third parties only. Of those third parties, here are the only places that I have found with cached read token pricing cheaper than wholesale pricing, ranked in order of bang for the buck determined via a thorough survey of the automatically updated pricings at https://codeberg.org/mutablecc/calculate-ai-cost/src/branch/main/subscription_vs_api_comparison.csv:

Ollama Cloud gives you exactly 3x the monthly subscription price of US$20 in tokens, and therefore that is 3x cheaper than the DSv4F wholesale rate (and same goes for all the other models they provide). If you’re happy buying a full year of subscription, they knock 20% off the price, which makes this probably the cheapest source of DSv4F tokens at a minimum price of US$2.25 per billion tokens.
Opencode Go gives you 1.5x-6x the monthly subscription price of US$10 in tokens depending on model. They list what multiple it is per model at https://opencode.ai/docs/go/#usage-limits. For DSv4F, it is currently 3x, same as for Ollama Cloud.
ClinePass gives you 2x-5x cheaper than the wholesale rate for US$10 per month, and they don’t publicly document anything further. It would appear they are quite similar to Opencode Go in terms of bang for your buck in practice, but because they allow a dynamic rug pull any time they choose based on what suits them – and I have no idea what discount they offer on DSv4F tokens specifically – Opencode Go or Ollama Cloud are better choices as they publicly document what you get for your money.
OpenRouter offers the public DSv4F wholesale rate of a minimum price US$7 per billion tokens, and it’s what you fall back onto when you’ve burned through your daily or weekly token allowances with the earlier three.
DevPass gives you exactly 3x cheaper tokens for a large range of backend providers the same as you’d get on Openrouter, but the monthly minimum subscription is higher at US$29 per month. There are two big issues:
1. ~~Maximum prompt caching requires special handling otherwise DevPass can cycle your session between backend providers, thus burning through your allowance much quicker.~~
2. You don’t get to choose who provides DSv4F, they do, and they annoyingly don’t choose the provider with the cheapest cached read price so you end up burning through your US$87 much quicker than you would with the previous two options.
In fact, I ended up cancelling my subscription for this option, because the providers they chose ended up costing US$41 per billion tokens, which is 13x the cost of Opencode Go and 5x the cost of OpenRouter wholesale. So until they fix their provider selection, or better again let end users pin specific backend providers, I cannot recommend this service.

I am hardly alone in the same boat of seeking cheaper tokens wherever I can find them: this guy’s blog post is pretty much identical to what I just wrote, except he’s hunting for cheap Kimi K3 tokens. And you’ll find similar blog posts and Reddit posts etc all over the internet because there is a small army of us all in the same position.

Obviously your first start is the Ollama Cloud subscription for US$20 per month, giving you maybe six billion tokens at twenty percent below one third price (27.5% in fact). You might then add two Opencode Go subscriptions so they start their monthly cycle two weeks offset from each other to add an additional ~2.5 billion tokens at the one third price every second week. Any tokens needed above that you fill in using wholesale priced tokens from Openrouter. If I end up using fewer tokens in future, one can cancel either one of the Opencode Go subscriptions as needed, which is why I chose those and not 2x year long Ollama Cloud subscriptions.

To automatically switch between these providers, one would need some sort of dynamic router which programmatically selects between Deepseek v4 Flash 0731 providers based on rules, and thankfully there is a mature one of those called Omniroute. It, very usefully, already is Deepseek v4 Flash 0731 aware and automatically disables usage during peak hours in China and it also automatically can parse Opencode Go quotas so it doesn’t even need to poll whether the quota is fully consumed. Very nice!

We are now up to a minimum monthly spend of US$40 for around eleven billion tokens, which is less half the US$100 I spent last month on ten billion tokens. That obviously is not quite one third the cost, but as I mentioned I got better at not wasting tokens as last month progressed. We’ll see how September goes with the new arrangement.

Now, let’s get into the projects I’ve been having my concurrent instances of DSv4F working upon:

LLM Project 1: ISO normative wording

I am famously bad at writing ISO normative wording. Eight years full time on ISO committees and I still suck at it. But good news: LLMs are specifically trained to mimic style and form, and if you feed them the entire ISO C standard using a prompt like this:

You are an expert member of the ISO WG14 C programming language standards committee, with an eye for detail and a tendency towards nitpicking.

Read proposed-wording, then read the N3886 it links to (you may find a copy in the reference directory). Ensure that proposed-wording applies cleanly to N3886. Where the proper tone, phrasing, terminology or vocabulary differ in proposed-wording from N3886, fix the proposed-wording.

Read the abstract machine section of N3886. Is there anywhere in the proposed wording which ought to be rewritten in terms of the abstract machine?

Then comprehensively review proposed-wording to determine if an implementation could be faithfully made from the proposed-wording alone. Merge any missing detail or other issues into plans/analysis.md. Try to make plans/analysis.md a list of open action items.

Make very sure you follow the style and conventions in N3886 such that after you are done, the proposed wording matches N3886 like a glove.

With that prompt, the LLM will turn my hand written wording such as this:

And the following macros, which restrict the optimizations which the compiler may perform:

sigfence(vars ...) for the following prevents the compiler relocating memory accesses from one side of the fence to the other side of the fence; it also causes the compiler to flush changes to memory bef ore the fence, and to reload from memory after the fence.

the memory storing all values accessible by external or internal linkage.

the memory storing values vars ... without linkage.

sigfence() is async-signal-safe.

Into this:

7 At a call to the sigfence macro (7.14.1), the implementation shall not deviate from the abstract machine for the memory that the call describes: the value of the memory at the point of the call is the value most recently stored to the memory before the call; an access to the memory that is sequenced after the call reads from the memory; and no access to the memory is performed on the other side of the call from where it is sequenced.

…

and the following macro, which restricts, for the memory described below, the freedom of an implementation to deviate from the abstract machine (5.2.2.4):

sigfence(...) provides the guarantees specified in 5.2.2.4 for the following memory:

the memory storing all objects with external or internal linkage;

the memory storing the objects without linkage named by the arguments of the invocation.

sigfence() is async-signal-safe. The behavior is undefined if the sigfence macro is invoked with more than eight arguments. Each argument, if any, shall be an lvalue designating an object; the behavior is undefined if an argument is a bit-field or designates an object declared with the register storage-class specifier. An argument that designates an object with external or internal linkage is permitted but has no effect, because the memory storing such objects is described by any invocation of this macro.

… which is far better than anything I have ever written myself – in fact, my own wording was me trying at 110% to write the best normative wording ever so far. As you can see, this just isn’t something I am good at, and now I have a normative wording writing helper. Yay!

Obviously I have been applying multiple rounds of analysis and refinement until the LLM could find nothing more. As I have four WG14 papers in flight right now, that took the month as one of my three concurrent projects, especially as you can also have the LLM repeatedly compare the proposed normative wording to the reference implementations, so everything moves together in lockstep and they all support one another. This is definitely not something I could do for a reasonable cost before DSv4F came out. I am very pleased.

LLM Project 2: Running full fat Python on real i386 Linux JIT transpiled into WebAssembly in the web browser

My son has a bunch of beginner Python teaching books, but they are all orientated around desktop Python, and he only has a locked down Chromebook which can’t run a desktop OS like Linux. You can get nowadays surprisingly good Python-within-a-webbrowser implementations which offer almost all of a desktop Python experience, but the ‘almost all’ comes with a giant missing package: no tkinter package, because for obvious reasons getting an X11 emulation running well on a HTML canvas is a big project and nobody has done one yet. As a result, while the tutorial programs he types in for Python turtle work great in Python-within-a-webbrowser, the lack of tkinter meant a good chunk of those Python teaching books was wasted.

So I asked DSv4F to go off and research how to solve this (I had been thinking let’s get it to write an X11 implementation for HTML canvas) and it found an interesting open source project which is a virtual machine running real i386 Linux JIT transpiled into WebAssembly in the web browser. One could then – theoretically – boot into Python IDLE, and voilà there’s your full fat Python with all bells included but it runs within his locked down Google Chromebook.

That was the theory: it turned out to be considerably harder in practice, and indeed the LLM has been working on this all day and all night for four weeks to reach this:

(Note that for readers in years to come, I have rented the VPS which hosts that URL for one year, and I don’t intend to renew it after so the above iframe may now be broken. If that is the case, visit https://github.com/ned14/webbrowser-python-idle which may have a new live example link, or indeed you can just run the thing yourself locally from that github repo. Also, security policies may prevent WebAssembly loading within an iframe on your web browser, if so visit https://webvm.nedprod.com/ and that should work)

The reason that this took four weeks and probably a good US$60 of token spend is because it turns out that WebVM upstream is more a proof of concept code quality than anything actually useful. It is absolutely riddled with bugs, hangs, race conditions, missing functionality, and stuff that just doesn’t work at all even though it is supposed to and sometimes does if and only if the wind is blowing right. I really have to hand it to Deepseek v4 Flash 0731: it just kept at it, and at it, and at it. Night after night, day after day, until all known bugs were fixed, worked around, or otherwise mitigated. Even when we bumped the Linux and Python versions from the EOL versions used upstream and just about everything broke badly as a result, it just went at the iteration and drill down until it had it running again. I then had it invest five days in performance improvement, and we got boot times down from four minutes to fifteen seconds – though I’ll admit that I did a lot of helping here, because DSv4F would only ever take a very narrow view on optimisation and never asks ‘should we consider a completely different approach here?’. Which is fair enough: that’s not what this model is for, it’s meant as a worker bee not as the ideas person.

Still, I have to admit I admired its doggedness, and the fact it did eventually actually get there. And that inspired me into my third LLM project:

LLM Project 3: Enabling LLMs to be left to roam free unsupervised

As I mentioned at the top of this diary entry, there is a fair bit of involvement from me in supervising, reviewing and instructing the LLMs. That’s because they’re running in Visual Studio Code instances on my laptop, and because they can run any command at all, that means they could be doing anything. So I have to manually review every single thing they do several times per day, and this gets tedious very quickly. It also means that I have to leave my laptop permanently running and connected to the internet, and that that very much reduces the usefulness of a laptop.

So what if they could run free not on my laptop and I don’t need to care what commands they run? Then I could appoint a ‘manager LLM’ to review and manage ‘worker LLMs’, and I only have to do something when I get pinged.

To explain a little more, much of my current loop with LLMs is having it iterate prompts like this for some project:

Comprehensively analysis this project for correctness and implementation duplication, looking to de-duplicate where possible. Identify any missing test coverage which is low effort to add. Identify opportunities to improve performance during operation, and safety/good UX.

You set that running. It runs for a few hours. You manually review every command and thing it did and all the code it changed. You git commit, you run it again. Day, after day, after day.

There is zero reason why a manager LLM, probably GLM 5.3 which I’ll talk about later, couldn’t be launching and coordinating a bunch of DSv4F worker LLMs so I don’t have to. I might wire that then into say WhatsApp, and you could talk away with it including by voice note.

I am also very uncomfortable about anything which can run commands on any of my computers remotely. It’s basically a wide open security hole, and I am absolutely 100% confident that at some point somebody somewhere is going to take advantage of cloud LLMs to run any commands they like on people’s computers.

I don’t intend to be one of those victims, so before the LLMs turn nasty, my third LLM Project is to build a container for them so secure that I can legitimately ignore how they get the job done. For that, your container needs to meet these criteria:

Coding agents need to be able run any command they like, including package install, and it only affects an ephemeral filesystem within the container. Docker/Podman has exactly this, so it’s a good foundation to start from.
Each session should be named and runs in the background so I don’t need an open tty. Basically, I SSH in, create a session, set it going, detach it and it keeps going until I kill it.
Each session should have absolutely no visibility of the local network: it can’t even see the host NIC. All it has is a proxy for HTTP, HTTPS, and SSH for git, and those only work with explicitly whitelisted targets. Even DNS is proxied and only whitelisted items resolve. This prevents them going off and attacking some poor victim on the internet as part of a botnet.
One can mount parts of the filesystem of the host, but it’s keyed on physical button keypress (my SSH keyfob). The docker environment doesn’t do the mount itself, it asks a sibling container which does the auth, then that asks another sibling container to do the mount/unmount. Every container checks everything for correctness and prints by its own i/o to the human; also the sibling containers have 100% read only filesystems, so it should be fairly hard to mount anything not explicitly permitted by me.
It must not be possible to DDoS the host by consuming CPU, RAM, disc space or inodes. Docker has limits for CPU and RAM, but the LLM had to write code to enforce disc space and inode usage limits.
Pi.dev is the principle LLM harness running within each session. It does get a shared directory with all other pi.dev sessions so they can coordinate, and that shared directory does persist over time. One could checkout git repos into that shared directory, and LLMs could work on say refining and debugging a codebase over an extended period without worrying about losing data.

I haven’t finished this project yet as DSv4F has been beavering away at the security side of things for multiple weeks by iterating this prompt:

If an extremely malicious and very intelligent coding agent were running inside the pi-dev container, comprehensively analyse their potential ability to escape the container, damage data, or cause denial of service. Be extremely thorough. Leave no stone unturned. Go the extra mile. Analyse every possible corner case exhaustively.

As a result of those iterations, it has written such a large and comprehensive test suite for all the possible corner cases that iterating further changes takes a very long time. As LLMs don’t get tired, it just keeps going and going and going until it’s done. I’m also finding some of the ergonomics not quite right when I use it manually, so there is some design iteration left to do yet too. But I’m getting close, and then I get my laptop back to being a laptop once again. And I’ll be less anxious about leaving the laptop always running and god only knows what commands are being executed in my name as I sleep.

Managing LLM costs going forth

Obviously if I get the ‘Roam free LLM’ project up and running, I am likely to start burning a lot more than ten billion tokens per month. However, as I mentioned above, there may be scope to achieve this within my current subscription budget:

The manager LLM might run GLM 5.3, a 753b-40b MoE model which costs a minimum of US$86 per billion cached read tokens on Ollama Cloud. That’s expensive, but still way cheaper than any LLM of similar capability. It has an AA Intelligence Index v4.1.1 score of 60, which is at the time of writing the best possible score for any locally downloadable LLM.

(In case you’re wondering why not Kimi K3, OpenRouter thinks it costs 2x GLM 5.3 per task when used for agentic work. And yes, given the expense, we shall really need to keep the total tokens ever passing through this model as low as possible – it is 37x more expensive than DSv4F!)
‘High’ worker LLMs will run DSv4F, a 284b-13b MoE model which costs a minimum of US$2.33 per billion cached read tokens on Opencode Go. It has an AA Intelligence Index v4.1.1 score of 52.
‘Low’ worker LLMs will run MiMo-v2.5, a 310b-15b MoE model which costs a minimum of US$0.47 per billion cached read tokens on Opencode Go (about 5x cheaper than DSv4F). It has an AA Intelligence Index v4.1.1 score of 38. As mentioned above, it isn’t really clever enough to leave running unattended – it is very much a last generation model (three months ago hah!) – but it’s fine for simple very clearly specified jobs like reordering action item lists.

And of course prices will drop over the next few months as new models appear, and existing Pareto optimal models will have to discount, like MiMo v2.5 has. One then has the enviable choice between spending less for what we’ve already got, or maintaining the spend for better.

I suppose I should mention GLM 5.3 Flash, which OpenRouter thinks costs the same per task as DSv4F. A lot of people are excited about this just released LLM as it has an AA Intelligence Index v4.1.1 score of 57, so it looks better bang for the buck than DSv4F. However it is only similar cost because it’s currently on promotional pricing – next week it will double in price, and then it won’t look so good any more. For our cached read heavy use case, it doesn’t look compelling even at the promotional pricing, even if you assume it emits half the tokens of DSv4F: it would be more than twice as expensive, and not especially that much more capable. I actually unwittingly used GLM 5.3 Flash for about a week because there was an ‘unnamed frontier model’ going for free and with one trillion token usage caps. And no doubt, it was better than DSv4F overall, though I felt DSv4F was better in specific things like relentlessness during debugging. For totally free of cost, it was amazing, but at 2x the cost of DSv4F? Not worth it.

What’s next?

My builder informed me two weeks ago that he can no longer install my insulated foundations due to ‘lack of capacity’, so now I need to source an insulated foundations installer. Wonderful. I’ve gotten quotes in for all the materials, I’m just waiting for quotes for the labour. Hopefully I’ll have those by next week, and with a bit of luck we might get the foundations complete before 2027. Then I just need some walls!

Megan failed both her chartered accountancy final exams, so she’ll need to resit them in January and that means another four months of taking the children anywhere else so she gets time to study. That, combined with the insulated foundation works, means I will likely have little free time to spare. In any case, the employment situation has not improved – I am increasingly wondering if I ought to be thinking whole new lines of business rather than traditional tech consulting based around C/C++. The reality is that LLMs have partially nullified ‘the programming language question’ because devs no longer need to specialise in a particular programming language ecosystem. As an example of what I mean, that webvm project described above uses:

36% Javascript
22% Python
20% C (almost entirely diagnostic and quirks workaround patch code)
8% Shell

And the secure ‘Roam free LLM’ project:

51% Shell
41% JavaScript

I understand all of those languages well enough to competently generate a finished project, but I would have been much slower to work in those less familiar languages than I would be in say C, C++ or Python. Now the LLM can blat out whatever programming language, it may not be of ideally high quality as if I had written it, but for most applications that will matter far less than the human still needed in the loop to drive the final quality push before completion. Ultimately this is because LLMs don’t – and can’t – know what the finished project is supposed to look like, or how bug free it needs to be, or how quick its boot times need to become.

So meat bags shall continue to have a role for a while yet! But I think maybe future remote work might be more of a ‘get this problem solved’ type rather than a ‘we need a specialist’ type. I also can’t help repeatedly thinking that there must surely be future work in humanoid robots somehow, but I’ve not seen much happening in that area in Europe. Maybe things will look better in Q1 2027 after Megan hopefully passes her resits?

Until then, I have plenty to be doing. As normal after Megan’s birthday every year, I go teetotal until Christmas. This is usually my most productive period each year, this time last year I closed off multiple long standing todo items many of which had been open for years. Here’s hoping that this Autumn will also be a clanger for getting stuff done!

#LLM

Go to previous entry

Go back to the archive index

Go back to the latest entries