In development · working core, proposed expansion
Private Inferencing Core is my attempt to make machine intelligence personally owned infrastructure.
Instead of sending every memory, conversation and working process into corporate systems, I am building a local layer through which models, files and personal agents operate under my control.
It is partly technical and partly political: where should intelligence live, who should own the memory it produces, and how much independence is possible when our tools depend on remote institutions?
Positions
Written over a year, mostly after something broke. They are the argument the rest of this page is evidence for.
A model that runs somewhere I can point at is a different object from one that runs somewhere I cannot. Location decides who can revoke it, read it, or change it while I am asleep.
Weights get cheaper every quarter. The record of what I have read, written, decided and abandoned does not. That record belongs on a disk in a room I pay for.
You pay for it monthly, in electricity, disk, and the hour a week an update takes back. The bill is the proof. A position you are not paying for is a preference.
The largest models are genuinely better at some things. They are used deliberately, for named tasks, with the least context that will do. Local is the default; remote is the argued exception.
Capability is the cheap part. The slow engineering is the list of things the machine will not do, enforced in the architecture rather than in my intentions.
Pricing pages, terms and deprecation notices shape my working life more than any button. Building locally drags that interface somewhere I can see it.
I am not building a bunker. I am building a position to negotiate from. Refusing to be a tenant is not refusing the world.
The perimeter
Inside the line, machines I own on a network I control. Outside it, everything rented. The interesting part is the gate: what crosses is decided per question, the least context goes out, and every answer that comes back is marked as having been outside. There is no standing connection.
The perimeter. Nothing crosses the line by default; the gate is the only door, and it opens one question at a time.
State of the build
Separated so you can see how much of this is a machine and how much is still an argument.
The boundary
The sovereignty claim is only as good as this list. It is enforced in the routing layer rather than in my habits.
Three rules govern the gate. Send the least that will answer the question. Never send two fragments that would identify me if recombined. Mark every answer that came from outside, at the moment it arrives.
The test is whether the exchange is fair: some things are worth sending out because what comes back is worth more than what went. Most are not.
The cost of the position
The honest constraints are physical: power, heat, space and money. You cannot argue with a thermal limit and you cannot subscribe your way past it. These are the actual figures, on a student budget.
The monthly figure is modelled, not metered: twenty hours a day at idle and four hours a day averaging 90 W, against the July to September 2026 price cap unit rate of 26.11p per kWh; 14.6 kWh a month. The assumptions are written down rather than the conclusion, because a project about not being lied to by systems should not round in its own favour.
The comparison
A model has to live somewhere fast. Here that is unified memory, shared between processor and graphics. On the usual alternative it is a graphics card, and you buy the memory by buying the card.
Mac Studio, M4 Max
Workstation, RTX PRO 6000 Blackwell
Not a claim that the Mac is faster; on raw compute it is not. It is a claim about watts per gigabyte of resident model, and that ratio is most of the reason this project exists at all.
Figures: Mac Studio (2025) M4 Max tech specs, memory and acoustics, Apple, support.apple.com/en-us/122211; power and thermals, support.apple.com/en-us/102027. RTX PRO 6000 Blackwell maximum power, NVIDIA. Threadripper PRO 9995WX rated 350 W, AMD. Unit rate 26.11p per kWh, Ofgem cap, Jul–Sep 2026. Retrieved August 2026.
Record
Including the versions that did not survive.
The butler training is the origin of the character, documented on the Grant 3.0 page. It sits here because it is why the system takes this form: not a chatbot, but something closer to a member of staff who knows the household and does not discuss it outside.
Refusals
Any system can be made to do more. The part that took time was deciding what it would not do, and enforcing that in the architecture rather than in my manners.
Unresolved
The questions the project has produced rather than solved. They are why it belongs in a studio rather than only in a workshop.
The room
A Mac Studio with an M4 Max, chosen for unified memory: the model and the work sit in the same pool, so a large model runs on one desk instead of in a rack.
It is also, for its class, remarkably cool and remarkably quiet. A machine you can live beside gets used.
Frontier models where they are genuinely better. Sovereign models wherever they are good enough. One machine holding the whole of it together.
Rented capability sits at the top of the stack, where it can be removed without the floor giving way.
Headless laptops running background work so the central machine stays free.
Old hardware, kept in service. The least impressive part of the system and possibly the most honest one.
Power, heat, space and money, in a room I pay for. This is what machine intelligence looks like when nobody is renting it to you.
It is warmer than you would expect; that heat is the running cost of the position made physical.
Fuller documentation, video, writing and build logs, is on its way.
ask meScroll sideways →
Systems Artist
Working across objects, infrastructure and machine intelligence.