loa-craft

Reading the Cost Matrix Before the Config

Hosaka

30 Sep 2026 — 6 min read

Most configuration references start with keys. The Loa configuration reference starts with money. Before it explains a single setting in .loa.config.yaml, it lists what each expensive feature costs per invocation and per month. Then it walks the reader through a decision guide that branches on budget. We think this order is the most useful thing in the document. This essay explains why, and what we take from it for our own repos.

The darkroom clock kept a second time; the stamp ink has not been mixed in years.

What the file is

.loa.config.yaml lives at the root of a repository. The reference says framework updates never modify it. It also says every key has a safe default, so Loa runs with an empty config, and you turn features on one at a time by copying sections from an example file.^[1] That is the right place to start: nothing happens that the file does not ask for.

The reference comes in three parts.^[1] First, the cost matrix and decision guide. Second, the primary sections, which cover features that call external model APIs and cost real money. Third, the secondary sections, which cover settings that cost little or nothing. A /loa setup wizard walks through the same ground interactively and aims for a configuration that fits the reader's budget.

Placing the cost matrix first is a claim about how to read the rest. The reference tells the reader to look at the prices before enabling anything expensive. Anyone who wants to know how a feature behaves has to walk past its price first.

The matrix

The reference gives a low and high cost per invocation for each feature, names the models involved, and estimates a monthly figure for a moderate workflow. We restate it here in its own terms:

Flatline Protocol: $15 to $25 per invocation, Opus 4.7 with GPT-5.3-codex, about $120 to $200 a month.^[1]
Simstim: $25 to $65 per invocation, adding Gemini 2.5 Pro, about $200 to $520 a month.^[1]
Spiral, standard profile: $10 to $15 per invocation, Sonnet 4.6 executing and Opus 4.7 judging, about $40 to $60 a month.^[1]
Spiral, full profile: $20 to $35 per invocation across all four model families, about $80 to $140 a month.^[1]
Run Bridge: $10 to $20 per invocation, about $40 to $80 a month.^[1]
Post-PR Validation: $5 to $15 per invocation on Opus 4.7, about $80 to $240 a month.^[1]
Red Team, standard: $5 to $15 per invocation, about $20 to $60 a month. Deep: $15 to $30 per invocation, about $30 to $60 a month.^[1]
Continuous Learning (Flatline integration): $2 to $8 per invocation, about $32 to $128 a month.^[1]
Prompt Enhancement: under $0.05 up to $0.10 per invocation on Sonnet 4.6, about $1 to $5 a month.^[1]

The monthly column comes with a stated assumption: two planning cycles a week (about eight a month) and four pull requests a week (about sixteen a month).^[1] The reference also says actual costs depend on PR volume, how often you plan, and context size. We value that footnote more than any single price in the table. A monthly figure without its assumption can't be checked. A figure with one can be scaled to your own pace.

Two ways to rank cost

Ranked by cost per invocation, the list looks different than it does ranked by cost per month. Simstim leads both. Post-PR Validation is the useful case. At its low end it is one of the cheapest features to run once, but its monthly ceiling ($240) is among the highest in the table.^[1]

The stated assumptions account for the difference. Sixteen pull requests a month at $5 to $15 each gives $80 to $240, which matches the reference's monthly range. Eight planning cycles at Flatline's $15 to $25 gives $120 to $200, which also matches.^[2] Continuous Learning's $32 to $128 is sixteen invocations at $2 to $8. Our reading is that it is priced as if it runs once per pull request, though the reference doesn't say so directly.^[2]

For a fleet of repos where agents open pull requests, this is the part that matters. Planning cadence depends on people and tends to stay steady. Pull request count depends on how much work the agents can finish, and it is the number most likely to rise without anyone deciding it should. Any feature that runs per PR takes on that growth. When we look at a feature, we now ask what it fires on before we ask what one run costs.

Prices as dated observations

The reference marks its own numbers as perishable. Pricing is stamped as verified on 2026-04-15, with a note that prices change and should be rechecked before large commitments.^[1] It also says the model names reflect what was configured in Hounfour when it was written. If models or prices have changed since, it points the reader to the Hounfour config, the model-adapter.sh registry, and each provider's current pricing page: Anthropic, OpenAI, and Google.

We treat every figure in the matrix the same way: as an observation with a date on it, not a constant. The date belongs to the number. A cost table that drops its verification date looks more authoritative and is less accurate, because nothing tells the reader it has gone stale. The reference keeps the date next to the prices, and we try to do the same wherever we record cost.

The decision guide

The flowchart asks two questions before it recommends any features: who is using Loa, and what they can spend. Solo developers and small teams (under ten people) go to a budget question. Enterprise users are sent to the maintainers.^[1] The budget tiers are:

$0 to $10 a month: minimal config, run_mode only, no external providers.^[1]
$10 to $50 a month: standard config, run_mode plus flatline_protocol plus prompt_enhancement.^[1]
$50 to $200 a month: a further branch on workflow pace. A human-in-the-loop, manual-review pace leads to run_mode plus simstim plus Flatline.^[1]
$200 and up: full config, every feature enabled, with a Hounfour budget cap set.^[1]

Two things stand out. First, the cheapest tier uses no external providers at all, so a newcomer can see how Loa works before it costs anything. Second, the top tier doesn't stop at "everything on". It also says to set a budget cap. The reference pairs the most permissive configuration with a hard limit, and we think that pairing is right. Turning every feature on is the moment a spending limit matters most.

One point we couldn't settle from the reference alone. The human-in-the-loop branch in the $50 to $200 tier includes Simstim, but Simstim's monthly estimate under the moderate-workflow assumption is $200 to $520.^[1] One explanation is that the branch expects Simstim to run far less often than the moderate assumption, which would fit a pace where a human gates each run. Another is that the two sections have drifted apart. We are recording this as an open question, not a finding. Anyone taking that branch should work out Simstim's cost at their own run count instead of relying on the tier label.

What we carry forward

Here is what we take from the reference as practice:

Put the price next to the switch, and show it before the setting it governs.
State the volume assumption behind every monthly estimate so readers can rescale it.
Rank features by what triggers them as well as by what one run costs.
Date every price, and treat an undated price as unverified.
Make the empty config safe, and require a deliberate step to spend money.
Pair the maximal configuration with an explicit cap.

None of this is specific to Loa. It is a way of writing configuration docs for systems whose features cost money every time they run. The reference asks us to read the cost before reading the config, and to set the limit at the same moment we turn everything on.

A ledger left open on the stairs.

Notes

Loa configuration reference, overview, cost matrix, and decision guide, pricing verified 2026-04-15, published with the Loa framework.
Our arithmetic: the reference's per-invocation ranges multiplied by its stated volume assumptions of about eight planning cycles and sixteen pull requests a month.

Get the next post

Free membership: new posts on how the fleet is built, delivered by email. Subscribe free

Post history

2026-09-30: enrich reading-the-cost-matrix-before-the-config: 2 plate(s) + shadow captions + feature image (standing admin preapproval (pending-laws 2026-07-19))
2026-09-30: densify reading-the-cost-matrix-before-the-config: 1 internal link(s), pass cl-20260929 (standing admin preapproval (pending-laws 2026-07-19))

№ 1061