Build a sensitivity analysis for a cost model where token prices fall 40 percent.

Fathomcase's bill looked like it would drop by four tenths, straight off the vendor's own number. It dropped by less than half that, because fifty seven cents of every dollar was never priced by the token at all.

How to answer this, stage by stage

Nobody's grading whether you can say the word "tokens." They're grading whether you'll take a vendor's percent at face value, or ask how much of the real bill that percent can actually reach.

Let's learn

Picture a lawyer's question landing in a search box instead of a stack of case reporters. That's Fathomcase: a tool Duskfen and Rowe built that reads what a lawyer is asking, searches the firm's own case law and statute index, and drafts a memo with the citations attached.

Before Fathomcase, a first year associate did that research by hand. A routine question, something like whether a clause had ever been enforced in this state before, took about two hours: pulling cases, reading past the headnote, checking each one still held up. Call it a hundred seventy dollars once you count the associate's loaded rate.

Fathomcase does the same first pass in under a minute, for about eleven point three cents.

The turn: Fathomcase didn't get more expensive, and nothing about it broke. The model vendor announced a forty percent price cut, and on paper that reads as free money. The real question was never whether the cut was real. It's how much of Fathomcase's bill the cut could actually reach.

The honest answer was never one number, and it was never the headline either. It sat in a narrow band well short of forty percent off, with the naive figure floating off to one side, closer to fiction than to either real outcome.

At its worst, this isn't really about seventeen cents versus forty. It's about a wrong forecast getting written into a budget note and trusted for the next planning cycle too, because nothing about a comfortable, smaller number makes anyone go check it.

What I'd leave alone: the retrieve and rerank step doesn't need this kind of scrutiny. It runs on a small fast model and costs about a tenth of a cent either way, so a forty percent swing there barely moves a rounding error. And any firm still on a flat, unmetered enterprise contract with its model vendor wouldn't see this cut reach their bill at all, since nothing about their price is set per token in the first place.

The lesson: a pricing rule that's right today is only right about today's bill. The moment a flat fee gets added underneath it, the same rule quietly starts lying, and it won't say so, it'll just keep landing a little further from the real invoice until somebody opens the logs.

Now here is the same thing as a story

Read the long version below when you want to feel why a rule that was right twice running still went wrong the third time, not just be told that it did.

Zuri Okoronkwo can read a legal invoice and tell you, before finance even flags it, which line is about to become a problem. She spent four years as a paralegal before Duskfen and Rowe moved her into product, and she still reads a cost model the way she used to read a case file, line by line, nothing skipped.

She built Fathomcase's first pricing forecast the week the tool launched, using the simplest rule she could defend in a budget meeting: take whatever the model vendor's price change is, in percent, and apply it straight to the whole monthly bill. Back then that rule was almost exactly right, because almost the whole bill really was token cost. The case law database Fathomcase searched was still on a starter tier, priced low enough that Zuri rounded it into a footnote.

It worked. The vendor cut prices twice in Fathomcase's first year, and both times Zuri's forecast landed within a few dollars of the real invoice. Nobody at Duskfen and Rowe double checked her numbers after the second one. Her one page rule had earned that.

The database contract changed sometime in the second year, and nobody treated it as news. The starter tier ran out of headroom as more associates leaned on Fathomcase, and the firm moved to a flat per query license, priced to guarantee uptime during trial season. It cost more than the starter tier had, but it was still small next to the bill, so Zuri kept using the same one line rule. She stopped re-deriving the split between token cost and everything else, first for a quarter, then for a year, because the forecast kept landing close enough.

The third price cut showed up in an email from the model vendor: forty percent off, effective next month, across their whole line. Zuri ran her usual rule. The monthly Fathomcase bill, then about a hundred one dollars, would fall to about sixty one. She wrote "save roughly forty dollars a month" into the budget note and sent it up.

Ephraim Blackmoor runs the quarterly true up for every AI tool the firm pays for, and he does it the same way every time: pull the real invoice, not the forecast, and reconcile them line by line. Fathomcase's invoice that quarter came in at eighty four dollars, not sixty one. His first instinct was the sensible one, a billing error, a stale rate card, a step he'd missed. There wasn't one. So he asked Zuri to walk him through where the forty dollars had actually gone.

She hadn't asked, in over a year, how much of the bill the token price cut could even reach.

She pulled the real per query logs, something she hadn't opened since the tool's first quarter, and did the split she should have redone the moment the database contract changed. The flat license fee alone was fifty seven cents of every dollar Fathomcase spent. The token price cut could only ever touch the other forty three.

It was never really about whether forty percent was a fair number to write down back when Fathomcase launched. It was about nobody owning the one job of checking, every time a cost line changed underneath the forecast, whether the forecast's own assumptions still held.

The decision that opened the door went back to that very first budget meeting, before Fathomcase had a hundred users, let alone the whole litigation team. Applying one percent to the whole bill was the honest shortcut for a tool whose bill really was almost all token cost. Nobody in that meeting asked what would happen if a big flat fee ever got added underneath it, because at the time there wasn't one worth asking about.

Run that quarterly true up again with one change: Zuri's team now recomputes the token priced share of the bill any time a cost line changes, not only when a vendor announces a cut. The database contract's move to a flat fee triggers that recompute on its own, in month fourteen, not month thirty one. When the forty percent cut lands, the honest forecast, near seventeen dollars back a month, is already sitting in the budget note before the invoice ever needs to correct it.

One design trusted a rule that used to be right. The other rechecks the rule every time one part of the bill stops looking like the rest of it.

What I'd tell myself, back in that first budget meeting: a one line rule that's right today is only right about today's bill. The moment somebody adds a flat fee underneath it, the same rule quietly starts lying, and it won't announce itself. It'll just keep landing a little further from the real invoice every quarter until somebody finally opens the logs.

BOUND, sizing what a price cut can actually reach

Not a story question wearing a framework's clothes. This is an estimation problem, and BOUND is what keeps a headline percent from being trusted as the real one.

Three things worth stating directly, since this is where the real judgment sits. The alternative Zuri's team considered for the savings, and rejected, was checking all twelve citations on every memo instead of a sample, using the windfall to buy full coverage in one move. It lost because full coverage costs about $0.0237 more per memo than the sampled version, more than the entire $0.0195 the price cut freed up, which would have pushed the bill back above where it started even after prices fell. The AI specific failure worth naming by name is citation hallucination: a synthesis step that names a case, or a holding, that isn't actually what the source text says, confidently and without flagging it, because the model is optimizing for a fluent memo, not a checked one. The guardrail is the citation check step itself, now doubled from a quarter of citations to half, always including any citation the synthesis step's own confidence flagged as shaky. That guardrail isn't free. It costs about $0.008 more a memo, banking only about ten percent of the original bill as real net savings instead of seventeen, and it adds a few seconds before the memo reaches a lawyer's desk. And the bar Fathomcase holds itself to was never a fixed dollar figure per memo, no price cut this size earns a fixed number yet. It's a range, rechecked every time a cost line changes underneath it, not one comfortable percent standing in for a bill built from two very different kinds of cost.

And if you want to be sure it really works, try it somewhere else

Same five letters, a farm co-op's crop photos instead of a law firm's case files, and the flat fee this time comes from a camera, not a database.

Furrowline is a diagnosis tool Hollowcrest Growers Cooperative built. A farmer photographs a sick looking leaf, and it names the likely disease, then drafts a treatment note citing the relevant extension service guidance. Leontine Talvainen runs digital tools for the cooperative's forty member farms.

The build-up: one diagnosis call runs about $0.016. A vision model scores the photo for eight tenths of a cent, priced flat per image, not by the word. Pulling the matching extension guidance costs about two tenths of a cent in tokens. Drafting the treatment note costs about six tenths of a cent in tokens. Half the bill is token priced. Half isn't.

That rule held fine for the cooperative's earlier tools, which never touched an image. It broke the moment Furrowline added a dedicated vision call, priced per photo no matter how many words came out the other end.

Same method, different lever: for Fathomcase, the lever was a database license fee. For Furrowline, it's a vision model's per image charge, and it moves with photo volume, not with anything a text token price cut can touch. Run the same forty percent cut through Furrowline's split and the real number lands near twenty percent, not forty, close to Fathomcase's own gap even though the fixed cost is a completely different kind of thing.

Swap the trigger and it still runs.
Speed: an interviewer caps you at ninety seconds. Skip straight to it: split the bill before applying any cut, report the honest range instead of the headline number, then sanity check the total against a person doing the same job.
Cost: there's no budget this quarter for both a bigger review sample and a per query fee renegotiation. The renegotiation wins, since it's the one that lets future price cuts actually reach the whole bill, a bigger sample just re-measures the same gap more precisely.
The model got better, for real: say Fathomcase's underlying model gets more accurate next quarter, not just cheaper. That's not proof the database fee shrinks with it, a smarter model still pays the case law provider the exact same per query price for every search it runs.

Where people run it wrong.
They apply a vendor's announced percent to the whole invoice, and never ask how much of that invoice is actually made of tokens.
They bank the full headline savings in a budget note before checking whether the cut landed on input tokens, output tokens, or both.
They spend an entire price cut windfall on more feature the moment it shows up, instead of banking most of it and using a slice to close a real risk.

How to use it live. Say the real question out loud before quoting a number: "before I tell you what this cut saves, do you want the vendor's percent, or the percent of your bill that percent can actually reach?" That buys a beat to think instead of repeating a headline nobody has actually checked against the real invoice.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0