Meet Peasant: All I Wanted Was to Save on Codex Credits

The original requirement was embarrassingly small

Minion/Codex is useful, but it is the specialist in my little AI department. I did not want to spend specialist credits on searching documents, pulling facts out of logs, organising evidence or doing other repetitive work that a smaller local model could handle well enough.

So Peasant got hired.

Peasant is the local worker in the workflow: cheap, persistent and deliberately narrow. ChatGPT remains the project lead for investigation, decomposition, review and integration; Minion gets called when a bounded coding task genuinely benefits from a stronger implementation agent; I still decide what gets built and what is allowed near production.

The name started as a joke. The job turned out to be real.

Peasant searches documents, retrieves evidence, works through logs and answers narrow questions with citations. He is not there to imitate the strongest cloud model. He is there to stop us paying the strongest cloud model to carry boxes.

That makes Peasant less of a miniature chatbot and more of an AI evidence mule.

The obvious next question was how much useful work a small local model could do before the computer itself objected. That is how a credit-saving experiment turned into retrieval benchmarks, model-size tests, memory-pressure measurements and, briefly, a discussion about buying Peasant his own hardware.

What Peasant actually runs on

The current host is a small Windows 11 MINISFORUM/EliteMini-series PC that was already here. Windows reports an AMD Ryzen 5 7545U, with 6 cores / 12 threads, and four soldered 4 GB Micron LPDDR5-6400 packages for 16 GB physical RAM. Around 14 GB is available to Windows after hardware reservation. Graphics are integrated AMD Radeon; Ollama has been observed running the language model on the CPU rather than using Radeon acceleration.

The generation model itself is a 2.5 GB download. At the 8,192-token context used in the measured setup, Ollama reported roughly 3.9 GB resident size. The small embedding model adds another few hundred megabytes.

The architecture is deliberately boring. An allowlist decides what Peasant is allowed to index, likely credential material is rejected, documents are chunked into a local SQLite index, and the answer comes back with citations to the evidence it used. The local web interface is bound to loopback rather than exposed to the network.

The point is not to create another infrastructure service. It is to make local information easier to use without giving a language model control of the systems it is reading about.

Does a 4B model actually help?

More than I expected, but less than the marketing version of local AI would suggest.

On the measured 50-question benchmark, retrieval found the expected document 50 out of 50 times and covered 93.27% of the expected facts in the top six retrieved chunks. That is the part of Peasant I trust most: finding the right evidence.

Generation is weaker. The first full generated-answer benchmark scored 81.71%. The model can give concise, useful answers, but it will occasionally omit a requested value or turn historical evidence into a broader claim than the source supports.

That is why Peasant cites his work and why a stronger model or a human still reviews anything important.

Speed is also very much "small local computer" speed. Warm generation reached 21.89 tokens/second on a controlled short response, while complete retrieval-and-generation questions took roughly 20–53 seconds in smoke tests. Across the full generated benchmark the average was 25.2 seconds per case.

Useful? Yes.

Instant? No.

The computer objected before Peasant did

The first serious workload exposed the real constraint: memory headroom.

During the 50-case benchmark Windows reported about 14,117 MiB usable memory, and free memory fell to roughly 442 MiB. At that point the machine was under paging pressure. Peasant was still working, but so was Windows, the browser, development tooling and everything else expected from the same PC.

This matters because the host was never bought as an AI server. It is a normal mini-PC attached to my desk. A batch job that technically completes is not much use if it makes the machine unpleasant to use for everything else.

That gave Peasant his first hard engineering boundary: local inference must leave enough computer for the human.

Naturally, we tried a bigger model

Once the 4B model worked, the obvious next experiment was qwen3:8b.

The 8B candidate is an 8.2-billion-parameter Q4_K_M model and the local Ollama copy is about 5.2 GB. It fits on disk. It can run. Neither fact means the machine has enough memory headroom to run it comfortably alongside the rest of Windows.

The bigger model pushed exactly the resource problem the 4B benchmark had already exposed. More model meant more RAM pressure, more waiting and less useful computer left for everything else. The improvement was not valuable enough to justify turning the desktop into a dedicated inference appliance every time Peasant had work to do.

So the promotion was rejected.

The dedicated-hardware rabbit hole

The next idea was predictable: give Peasant his own machine.

We looked at used workstations and a DIY AM4-style build with 64 GB of upgradeable RAM, enough CPU to keep the system responsive and, eventually, a discrete GPU with enough VRAM to make larger local models worthwhile.

On paper that solves the problem cleanly. Peasant gets a dedicated box, the desktop stays responsive, and future models have room to grow.

Then we priced it.

RAM and GPU prices are not especially interested in the fact that this started as a cheap local assistant. Even using second-hand parts, the base machine was heading into several hundred pounds before adding the kind of GPU that would materially change what Peasant could run. Once memory, GPU, case, PSU and cooling were counted, a "free local model" was rapidly becoming a four-figure hobby infrastructure project.

That forced the useful question:

What problem are we spending this money to solve?

Right now, Peasant already does the job he was built for. Spending heavily to make him imitate the cloud models would remove most of the economic reason for having him.

Why Peasant stays small

The current division of labour is deliberate.

Peasant handles local retrieval, evidence gathering and repetitive first-pass work. ChatGPT handles broader investigation, architecture and review. Minion handles substantial coding work when a bounded engineering task needs an implementation agent. I decide what gets built and what is allowed near production.

That means the smallest model can still be useful without pretending it is the smartest member of the team.

If Peasant can turn 29 documents and a pile of logs into three relevant sources and a cited answer, he has already earned his electricity.

What would justify an upgrade?

Dedicated hardware is still an option, just not an automatic next step.

It becomes interesting when the workload changes enough to justify it: substantially larger local corpora, regular long-running jobs, a model that produces a measured improvement worth paying for, or hardware prices that make the experiment sensible again.

Until then, the upgrade policy is straightforward:

Measure first. Buy hardware second.

The current 4B system is not glamorous. It is CPU-bound, memory-constrained and slower than a cloud model. It is also private, inspectable, inexpensive to run and genuinely useful at the narrow job it was given.

Peasant remains small, local and appropriately supervised.

The GPU server can wait until he produces a convincing business case.