Feature cost versus decision cost

A feature bill answers "what does this capability cost this month?" A decision price answers "what does this named judgment cost per case, and how often does it run?" Neither replaces the other. Design arguments that use only one lens sound confident and miss the money.

Helpful context: Cost per decision prices one edge. Framing produces the decision map that feature cost aggregates. Separating, not sorting explains why one "feature" is often several decisions. This page holds both lenses together for product and engineering alignment.

Finance sees trends and provider totals. Engineering sees which edge dominates when loops multiply evenings and iterations. Product sees whether autonomy improvements dwarf token shaving. All three need both numbers on the same page, because each perspective alone leads to locally rational decisions that fight each other in aggregate.

What each lens shows

Lens	Makes visible	Hides if used alone
Feature / monthly	Total spend, trends, provider bill	Which judgment dominates, where guards would cut volume
Decision / per call	Price of one edge, effect of wrappers	How often the edge runs, interaction with the funnel

For the Weekly Meal Companion, the monthly "meal planning feature" might total a few hundred dollars while GenerateCandidates dominates because it runs on every evening every iteration. JudgeHouseholdFit, the judgment everyone thinks of as "the AI part," can be a tenth of the bill because it sits behind filters and runs once per plan. The monthly total hides this distribution. The per-edge price without volume hides the multiplication that makes the front-of-funnel edge expensive.

Feature cost

Monthly total across composing edges. Finance and trend visibility.

Decision cost

Price per named edge times volume after guards. Engineering visibility.

Both lenses required. Neither replaces the other.

Both lenses for design

Decision cost guides wrapper selection, model tier, and purity level per edge. Feature cost reveals whether autonomy rate improvements dwarf token shaving. Raising the share of cases that conclude without a person looking often saves far more than halving a mid-funnel template, because human review carries cost and latency the provider bill never shows.

Counting assisted cases separately from autonomous ones reveals this gap. A clerk reviewing every assessment has not displaced the full human decision. Feature cost that splits human minutes and token spend when both appear on the same capability tells the full economic story.

Cost follows volume

Volume is highest at the front of a funnel where work is comparatively mechanical. Deterministic guards and closed-work extraction change feature cost more than polishing a rare consequential cognitive unit's wording. The rare edge may deserve reliability spend. It is rarely where the monthly total lives.

Polishing JudgeHouseholdFit while leaving portion math inside ComposeWeek is a common cost inversion: attention follows prestige, spend follows volume. The inversion feels productive because the prestige edge is the one in the pitch deck. It costs money because the high-volume edge is the one on the provider bill.

Cost follows volume, and volume is highest at the front of a funnel where the work is comparatively mechanical.

The cognitive unit, Ch. 12

Decision maps are cost maps

Framing starts from decisions, not models. Once the decision map exists, feature cost is the sum of edges on that map times volumes times wrapper policies. Product roadmaps that add "one more AI feature" without updating the map hide new burn rate behind a label.

A single-shot recipe generator has a trivial map: one cognitive unit, one call per request. Feature cost equals decision cost. That simplicity is rare and valuable when it applies. The full Meal Companion agent has seven-plus named edges, loop multipliers, guard-conditioned paths, and expertise compression when guards pass. Feature cost is the sum. Decision cost reveals structure. Both exist so that the team can argue at the right level of granularity depending on the question.

What this looks like in practice

Compare two products with the same monthly bill of $800. Product A is a single-shot recipe generator: one cognitive unit, forty thousand calls. Decision cost equals feature cost divided by forty thousand. Optimisation is straightforward because there is one edge and one volume.

Product B is the Meal Companion agent with the same $800 monthly total. The spreadsheet shows GenerateCandidates at $520, loop-driven ComposeWeek and CritiquePlan at $180, JudgeHouseholdFit at $45, remainder scattered. Guard improvement on candidate generation saves more than triple-sampling household fit, because the high-volume edge dominates the total by a factor of ten.

A leadership meeting uses one slide: monthly total, top three edges by spend, proposed guard or closure on the highest-volume line, expected feature cost delta. Separate finance-only and engineering-only stories produce separate optimisations that fight each other. Shared numbers keep guard placement, wrapper policy, and autonomy goals aligned.

Pricing and capacity follow the map

Capacity planning asks how many plans per month at current architecture, not how many tokens the account holds. Pricing for B2B products can attach to decision classes with visible eval coverage rather than opaque "AI credits." When sales promises unlimited meal plans, operations needs the decision map to know whether unlimited is arithmetic or bankruptcy.

The map makes capacity planning concrete because each edge has a known cost-per-case, a known volume-after-guards, and a known loop multiplier. Multiplying those numbers by projected user growth produces a capacity forecast that finance can evaluate rather than a hope that "the models will get cheaper."

Anti-patterns in feature accounting

The most common anti-pattern is lumping human review under "overhead." Clerk minutes on AssessMealPracticality exceptions belong on the same feature row as token spend, because they are part of the cost of that decision class at the current autonomy level. Counting demo paths only misses production traffic that includes abstentions, partial plans, and loop retries that demos skip. Feature labels without maps ("AI meal planning" on the invoice) hide seven named edges and two loop multipliers. And optimizing the judge in the pitch deck means investors see JudgeHouseholdFit while operations pays for GenerateCandidates.

Each anti-pattern has the same root: one lens used alone. Monthly totals without edge breakdown hide structure. Edge prices without volume hide multiplication. Both together expose the structure that makes design conversations productive.

When the lenses disagree

Sometimes monthly feature cost falls while per-edge decision cost rises because a wrapper was added on a consequential path. That can be correct: paying more per call on fewer cases after guards still produces a lower total. Sometimes feature cost rises while per-edge cost falls because volume grew on all paths. Reading both before declaring victory or failure prevents the team from celebrating a per-call improvement that produced a higher monthly bill, or panicking about a monthly rise that reflects healthy growth on cheap edges.

Roadmap questions that use both lenses

Before approving a roadmap item, the question is whether it adds new open judgments (raising feature cost structurally), compresses an existing loop (potentially lowering both lenses), or moves closed work to code (lowering volume on high-traffic edges). Items that only "add AI" without a decision map answer hide structural cost behind a label. The map reveals what the roadmap item actually adds to the system's ongoing economic obligation.

The invoice intake parallel

Invoice intake shows both lenses on one capability: monthly document processing total versus per-field interpretation price times documents after guards. Extraction Skills dominate feature cost while individual field cognitive units dominate decision cost on exception paths. Both numbers belong in the same review when clerks ask why autonomy stalled despite flat monthly spend. The answer is usually that high-volume extraction stayed cheap while exception routing grew expensive on a per-case basis.

What to do next

Putting the monthly feature total and the top three per-edge line items on one dashboard is the starting point. Running one optimisation experiment on the highest-volume edge rather than the demo-highlighted judge typically reveals the largest cost lever. Updating the decision map when adding capabilities keeps feature cost explainable quarter over quarter. Tuning by wrapping applies when prestige edges need improvement without rewriting identity.

See paying for reliability, tuning by wrapping, and price of closed work left open.

Read next: Tuning by wrapping.