Second-Order Effects: What Cheap Cognition Changes

Predicting when something becomes possible is guesswork. Predicting the order in which things become viable is not: it follows from a threshold each use case has, and those thresholds can be written down today.

The viability threshold

A task is worth automating when the cost of doing it is below the value of having it done, with enough margin to be worth the trouble:

Viable when:

  c_model + c_verify + c_integrate  <  v_task * p_success

  c_model      inference for one task
  c_verify     checking the output is acceptable
  c_integrate  amortised cost of building and running
               the path around it
  v_task       value of one completed task
  p_success    fraction of attempts that are usable

v_task is set by the domain and does not fall.
c_model falls.
c_verify falls only if verification can be automated.

The asymmetry in those last three lines is the entire content of this page. One term is collapsing, one is fixed by the world, and one falls only under a specific condition. Everything else follows.

Note the p_success term as well, because it multiplies the value rather than adding to the cost. A task with high value and low success probability can be worth attempting at scale; a task with modest value needs high reliability before it clears the bar at all. Rising reliability moves the threshold as surely as falling price does, and it is the reason some use cases switch on without the price moving at all.

It is worth running the inequality once with real-looking numbers, because the result is usually not where intuition puts it. Take a task worth an assumed $3 when completed — enriching a record, drafting a reply that a person will send — at a success rate of 0.8. The right-hand side is $2.40. Inference at four cents is irrelevant to whether this clears; two minutes of human checking at a loaded dollar a minute is not, and neither is a build cost of $40,000 amortised over however many tasks a year the work actually produces. Divide that build cost by 100,000 tasks and it is forty cents a task, which changes the answer; divide it by 5,000 and it is eight dollars, which ends the discussion. Volume is a term in viability, not just a multiplier on the benefit.

One more term hides inside c_integrate and deserves naming: latency. A task that has to complete while somebody waits can only use models and pipelines fast enough to do so, which is often not the cheapest option available. Where the work can be done in the background, the whole latency-tolerant end of the price list opens up — batch tiers, slower and cheaper models, retries at leisure. Moving a task from synchronous to asynchronous can therefore cross the viability threshold without any change in capability or price, and it is usually a product decision rather than an engineering one.

The order of unlocks is predictable

Sort every candidate use case by value per task. High-value tasks cleared the threshold long ago; low-value, high-volume tasks clear it last. So the sequence is knowable even though the dates are not:

v_task     example class of work        status
--------------------------------------------------
$100+      specialist review of one       viable at
           document, one legal or         almost any
           medical opinion                price

$1 - $10   support responses, code        viable at
           review, drafting, research     moderate prices

$0.01-$1   per-item classification,       viable only
           moderation, tagging,           when a task
           enrichment, translation        costs cents

< $0.01    per-token personalisation,     viable only
           speculative background work,   at near-zero
           re-checking everything         cost, and only
           continuously                   with automated
                                          verification

Two consequences follow. The largest volumes are at the bottom of that table, so most of the eventual demand for inference sits in work that is not yet viable — which is the mechanism behind the staircase-shaped demand curve in the elasticity page. And the frontier of what is newly possible is always the least glamorous work, because it is the cheapest per task. The next thing to become viable is not a more impressive version of what exists; it is something currently considered too trivial to bother with.

The table also identifies a second class of unlock that has nothing to do with new capability: work that was already being done, but selectively. Reviewing a sample of transactions rather than all of them, checking the important contracts rather than every one, translating the documentation that seemed worth translating. Sampling is a cost-saving measure, and when the per-item cost collapses the sample can become the population. That change is invisible in any list of new capabilities and is frequently where the value actually is, because a control applied to everything is a categorically different thing from one applied to a tenth, even when the underlying task is identical.

One caution about reading the ordering as a forecast. Thresholds explain the sequence, not the timing, and the gap between a use case becoming economically viable and it actually being deployed is filled with things this model does not price: whether anyone owns the problem, whether the data is reachable, whether the output would be trusted, and whether the workflow around it can absorb the change. Viability is necessary and nowhere near sufficient, which is the same point the adoption term makes in a bottom-up business case.

The verification floor

As c_model tends to zero, total cost tends to c_verify + c_integrate. Whatever those are, they become the whole cost, and whether they fall decides whether the threshold keeps moving:

If a human must check every output:

  c_verify = (minutes to check) * (loaded cost per minute)

Assume 2 minutes at $1.00 per minute:  c_verify = $2.00

Then no reduction in c_model below $2.00 changes
viability at all. A model call at $0.02 and a model
call at $0.0002 are the same decision.

This is the single most useful prediction available from the model, and it is not about capability. The tasks that cheap cognition transforms are the ones where verification is cheap or automatable. Code with tests that run. Structured extraction validated against a schema. Retrieval where a citation can be checked against the source. Translation with a round-trip check. Anything where a machine can decide whether the output is acceptable inherits the full price decline.

Where verification requires expert human judgement — a diagnosis, a legal position, a strategic recommendation — the cost floor is the expert’s time, and cheaper inference moves the total cost hardly at all. Those domains change through improved reliability, which reduces how much has to be checked, rather than through price. Two very different mechanisms, frequently conflated.

There is a middle path that is often the real answer: verification does not have to be all-or-nothing. If a cheap automated check can identify which outputs are likely to be wrong, human attention can be spent only on those, and the effective verification cost becomes the check rate multiplied by the human cost. Sampling, confidence thresholds, agreement between two models, and validation against a schema or a source document all work this way. The economic effect is large: taking the human check rate from one hundred percent to twenty cuts c_verify by four fifths, which does more for viability than any plausible further fall in model price. Designing the filter is therefore worth more engineering attention than choosing the model, and it is consistently underinvested in because it is not the interesting part.

The attention bottleneck

There is a second non-falling cost, and it is easy to miss because it is not on anyone’s budget. If the output of a task is text a person must read, the binding constraint is reading time, which has not become cheaper and will not.

A system that generates a thousand summaries an hour for a team that can read twenty is not producing nine hundred and eighty units of value; it is producing a backlog and a new filtering problem. The value of generated output is capped by the attention available to consume it, and past that cap additional generation has negative value, because it crowds out the output that would have been read.

• Workflows that end at a human eye do not scale with the price of tokens. They scale with how much reading they save, which means summarisation, ranking and filtering are worth more than generation in exactly those workflows.
• Workflows that end in a system do scale. Output consumed by a database, a test suite, a queue or another program has no attention ceiling, and these are where volume genuinely grows without bound.
• The design instruction that follows: when cognition gets cheap, spend it on deciding what a person should look at, not on producing more for them to look at.

Using this to decide what to build

• Write down v_task for your use case. If you cannot estimate the value of one completed task, you cannot know whether a price decline helps you, and the number is usually estimable within a factor of two.
• Ask what verifies the output. If the answer is a person, price declines will not change your economics much, and your effort belongs on reliability and on reducing what must be checked.
• Look one rung down the value table. The work that is currently too cheap to be worth automating is the work that becomes viable next, and it is where the volume is.
• Check the downstream constraint before scaling. Human review capacity, approval processes and reading time are all fixed inputs. A pipeline that outruns one of them has converted a cost saving into a queue — and the enterprise version of this mistake is the adoption term in the bottom-up spend model.