Skip to content

Archive⚓︎

The case for open-weights models

Companies should use open-weights models, as long as they use them the right way. The worry about these models usually arrives as one question, "are they safe?", which is really three. Where does the data go? How does the model behave? Who made it? The route, meaning where a model runs and on whose servers, answers the first. Testing answers the second, and open weights let anyone test a model directly. Only the third depends on who made the model, and moving the model to another server does not change that answer.

Three panels. Where data goes is set by the route: a prompt sent to an Australian cloud region stays onshore, and a prompt sent to the maker's own API goes offshore; the control is to choose the route. How it behaves is set by the model: the weights are open to testing, wrong answers and prompt injection affect every model, and jailbreak resistance varies by model; the control is to test the model on your own work. Who made it is set by the maker: the maker's tag travels with the model to your own servers, a cloud or the maker's API, so rules about the maker follow it; the control is to match the maker to each customer.

Closed models such as ChatGPT and Claude face the same three questions, so this post puts each question to both kinds. With open weights, the buyer controls more of the answers. Every figure here comes from a named source read in October 2026, most of them primary, and the post says where the evidence runs out.

Copying what nobody can write down

A chain store looks like the easiest business to explain. Someone gets one shop right, writes down what they did, and opens the same shop again and again, so the chain's profit is one shop's profit times the number of shops. Sidney Winter and Gabriel Szulanski, who studied firms that grow this way, call this the usual picture of replication and argue that it misses most of what such firms actually do.

This post asks three questions the usual picture can't answer. What does a firm copy when it copies a working shop? If the shop can be copied, why can't a rival copy it too? And why does no copy stay the same as the original? It draws on three papers: Winter and Szulanski's account of replication as a strategy, Jan Rivkin's model of when a firm can copy itself but rivals can't copy it, and Martin Friesl and Joanne Larty's review of how copied routines change once people perform them. One bank, Banc One, runs through the whole post. It leaves out franchise contracts, finance and brand, and starts from the usual picture, a formula written down and copied, adding a part each time that picture fails.

Automation and New Tasks, Explained

Some people see automation, from industrial robots to artificial intelligence, as the start of widespread joblessness. Others expect it to go the way of earlier technologies and, in the end, raise the demand for workers. Daron Acemoglu and Pascual Restrepo's 2019 paper, Automation and New Tasks: How Technology Displaces and Reinstates Labor, gives a way to tell which is happening, then measures it for the United States from 1947 to 2017.

This post walks through the paper's model and formulas, leaving out the proofs in its online appendix. It starts where the paper does, with the work it takes to make a shirt.

Outcome pricing is a piece rate

Metronome's pricing levers page sets out the choices a software company makes when it prices a product. There are five levers: the metric it charges for, the structure of its tiers, the commercial model, the incentives, and how it charges for support. Most of the argument about AI pricing is about the first lever, and its options sound new: per seat, per token, per outcome. They are three old ways of paying for work. A seat is a salary, a token is an hourly wage, and an outcome is a piece rate.

A table pairing three ways people are paid with three ways software is priced: salary with per seat (Jira), hourly wage with per token (OpenAI API), and piece rate with per outcome (Intercom Fin). Below it, who carries the risk. If the job takes longer, the seller pays under a salary or a piece rate and the buyer pays under an hourly wage. If the job fails, the buyer pays under a salary or an hourly wage, and the seller pays only under a piece rate.

The bottom rows of the figure show what each form does with risk. A salary and a piece rate both leave the seller to absorb a job that runs long, but only a piece rate also leaves the seller to absorb a job that fails. Labour economics has studied all three forms for decades, and it knows when piece rates work: when the job can be counted, when bad work can be seen, and when the worker has a floor under the slow weeks. Those conditions will decide where outcome pricing holds. One more lever, the commercial model, comes back at the end, where it turns out to manage the risk the metric creates; tiers, incentives and support pricing stay out of this post.

Write, Run, Check

A product's core loop is the short cycle of steps its users repeat. Dwipal Desai, who was on YouTube's early team, gives YouTube's as "Create > Upload > Share". Google's Playground, which his group launched in October 2026 to make games from descriptions, has "Create > Play > Share".

Work done with AI has a core loop too: Write > Run > Check. A person writes down the steps, the AI runs them, and the person checks what comes back. The loop stays the same while the AI takes over its steps one at a time: first the running, then the writing, and now the checking. This post follows a person's taste, their sense of what a good result is, through each handover, and then asks what happens when there are more tasks than anyone's taste can reach. Its example is a wine that has to taste the same every year, though its grapes never do.

Benchmarking the Harness

Every public agent leaderboard ranks a model. Around that model sits a scaffold: the code that issues tools, builds context, decides when to retry and when to stop. The scaffold usually goes unreported. Three controlled results published this year show what that omission costs.

Vats and Golev ran two models across three open-source harnesses on a stratified 50-task subset of Terminal-Bench Pro. Their finding: "harness choice induces up to a 40x difference in tokens per solved task, while paired within-model pass-rate differences remain 0-8 percentage points." Failure patterns replicated across models. Goose failed on reasoning, OpenHands-SDK on verification and turn limits, OpenCode on idle loops and timeouts. Those are properties of the harness, not of the model running inside it.

The Cost Control Checklist

Your AI bill is not a pile of line items. It is one multiplication:

total spend  =  users  ×  sessions per user
               ×  turns per session  ×  requests per turn  ×  tokens per request
               ×  price per token

Put real numbers in it and the shape becomes obvious:

100 users × 20 sessions × 50 turns × 3 requests × 20,000 tokens × $3/M  =  $18,000/month

Because it is a multiplication, halving any single term halves the whole bill. Cache properly so each request carries 10,000 tokens instead of 20,000, and you are at $9,000. Leave the tokens alone and route the work to a model at half the price — also $9,000. Ground the agent so it finishes in 25 turns instead of 50 — also $9,000. Do all three and the same delivered work costs $2,250.

Double Entry AI

(Q, A) → (Q, A, U, W)

Q is the question a harness forms. A is the answer it produces. U is whether the person working with it still understands the output. W is whether producing it is sustainable for them. Harnesses today are measured on Q and A. This post is about U and W.

The two ledgers Left: the Machine Ledger, what the harness produces. Right: the Human Ledger, what producing it does to the person.

The name is from bookkeeping. Single-entry records what came in and went out. Double-entry, in use since the 1300s, records every gain against its source, so a gain cannot appear in one account without its cost appearing in another. The analogy has a limit: in bookkeeping both entries are money, and here they are different quantities with no exchange rate. What carries over is the rule. You may not keep only one ledger.

The Economics of Difficulty

A machine arrives on the floor and everyone gathers around it.

The workers want to know where they stand, and what they are supposed to do while the machine runs. The consultant wants to know how the money moves now — which step everyone has to route through, and where a toll can be charged.

Whether or not the machine is clever, it can cost jobs and rebundle skills. Systemic change does not wait for evidence at the level of the individual worker. Belief moves first, then action, and the value chain is re-cut on the strength of a forecast — well before anyone has established what the machine can actually do, and sometimes instead of ever establishing it.

Launching Orqestra

The main stage at Ready Summit '26
Ready Summit '26.

I launched Orqestra earlier this week at Ready Summit '26, in front of several hundred people in Melbourne and again in Sydney. We built it to speed up the compliance-heavy, domain-specific work our clients do in Education, Workforce, Work Pathways, Local Government and Justice. But it's more than accelerating the work. We also built it to help the people behind that work understand and steer AI better, manage their careers and develop their workforces.