The Re-Derivation Tax

Executive Summary

Enterprises modernizing legacy estates have converged on a common first move: point a large language model at the code. Open Claude, open a coding agent, paste in the COBOL, ask what it does. It works — the answer comes back, and it is often good.

The problem is not the answer. The problem is that the organization pays for that answer again, and again, and again.

Every engineer who opens a session about PAYCALC01 re-derives the same understanding from the same source. Every new sprint re-derives it. Every audit request re-derives it. Every model upgrade re-derives it. The knowledge is produced, consumed once, and discarded into a chat transcript that no one can query, govern, version, or cite. We call this the re-derivation tax, and on a portfolio of any size it is the dominant cost of AI-assisted modernization — larger than licences, larger than tokens, and considerably larger than most programs budget for.

BlueDrop NextGen is built on a different premise: derivation is a fixed cost that should be paid once. NextGen runs a deterministic parser coupled to a multi-pass LLM pipeline across the entire estate, and persists the result as a structured, versioned, provenance-carrying repository of business rules, data lineage, call graphs, and domain classifications. After that, questions are answered from the repository rather than re-derived from source.

The consequences are measurable in three places:

1. Token economics. A repository-assembled prompt carries 3–8K tokens of curated, relevant context instead of 40–120K tokens of raw source and copybooks. Across a program's lifetime this is a 20–50× reduction in input token volume for equivalent questions — and unlike prompt caching, the saving does not expire in five minutes.
2. Human economics. The dominant term. Reconstructing situational understanding of a legacy program costs an engineer 20–40 minutes. Looking it up costs two. On a 1,200-program estate with typical reference frequency, this is the difference between a six-figure and a five-figure line item.
3. Consistency and audit. Two engineers asking the same question of a chat interface get two plausible, differently-worded, occasionally contradictory answers. Two engineers querying a repository get the same answer with the same citation — which is the only version of this that survives contact with a regulator.

This paper sets out the mechanism, a transparent cost model with stated assumptions, and — importantly — the cases where a direct interface remains the better tool. NextGen is not a replacement for Claude Code or equivalent agents. It is the context supply that makes them cheap.

1. Three Taxes on Ad-Hoc LLM Use

1.1 The Re-Derivation Tax

Consider a single COBOL program of 2,000 lines with a dozen copybooks and four called subprograms. To answer any non-trivial question about it — what determines eligibility here? which fields feed the premium calculation? what happens on the error path? — a model must first read and understand the whole unit.

That understanding is expensive to produce and, in a chat or agent session, entirely ephemeral. It exists inside one context window, belonging to one person, for one afternoon.

Now scale it. A modernization program touches each program in the estate multiple times across its lifecycle: discovery, rule extraction, target design, test case derivation, remediation, validation. Different people, different months, different tools. The cost of understanding is therefore not paid once per program — it is paid once per (program × person × phase).

For a 1,200-program estate, three engineering touchpoints and 2.5 phases, that is roughly 9,000 independent re-derivations of knowledge that changed exactly zero times in the interim. The source code is static. The understanding is recomputed anyway, because there is nowhere to put it.

1.2 The Context Rent (Token-Maxing)

The second tax is structural to how transformer inference is billed. To answer a question about a program, the model needs the program in context — plus copybooks, plus called modules, plus relevant JCL, plus the data definitions. On a mainframe estate this payload is routinely 40–120K tokens.

You pay that payload on every turn, not once per session. A ten-turn conversation resends the accumulated prefix ten times. Agentic tools are worse: an autonomous agent exploring a legacy codebase issues 15–40 tool calls per task, each one carrying the entire accumulated transcript — every file it has read so far — back to the model. Cumulative input scales super-linearly with the number of turns.

This is what practitioners mean by "token-maxing": the working set expands to fill the context window because nobody has curated it, and then that maximal working set is billed repeatedly.

The instinctive response is to buy a bigger context window. Current-generation models offer 1M-token context at standard pricing, which removes the capacity constraint entirely. It does not remove the economic one. A 1M-token context that you fill and resend is simply a larger recurring bill. Capacity was never the binding constraint; relevance density was.

1.3 The Divergence Tax

The third tax is the one that ends up in front of a regulator.

Ask a chat interface the same question twice — different session, different engineer, different day, possibly a different model version — and you will get two answers. Both fluent. Both mostly right. Differently worded, differently scoped, occasionally contradictory on edge conditions.

For casual work this is tolerable. For a modernization program it is not, because the extracted business rule is the deliverable. If the rule statement varies by who asked, the organization has no canonical specification of its own system. Downstream, this surfaces as:

• Reconciliation meetings to decide which version of a rule is authoritative
• Test cases built against one interpretation and code built against another
• Rework when the divergence is discovered in UAT rather than in analysis
• An inability to answer "where did this rule come from and who approved it?" — the subject of The Auditability Gap, Paper 1 in this series

Divergence is not a token cost. It is a rework cost, and rework is the most expensive category of work in any modernization program.

2. Why Prompt Caching Does Not Solve This

A reasonable objection: modern APIs already cache. Anthropic's prompt caching lets you mark a stable prefix, pay a write premium on first use, and read it back at roughly a tenth of standard input price thereafter. For long system prompts and repeated document context this is the single highest-leverage cost optimisation available. It is real, it works, and every NextGen deployment should use it.

It does not, however, address the re-derivation tax — because it operates at the wrong layer.

	Prompt cache	Vector / RAG index	NextGen repository
What is cached	Token encodings	Text chunks + embeddings	Derived conclusions
Scope	One session, one prefix	One corpus, one index	Whole estate, all consumers
Lifetime	5 minutes or 1 hour	Until re-indexed	Versioned, permanent
Survives model change	No	Partially	Yes
Carries provenance	No	Source chunk only	Full derivation lineage
Reasoning preserved	No	No	Yes
Governable / reviewable	No	No	Yes

Prompt caching is ephemeral, session-scoped, and prefix-exact. It expires by design, it is not shared between users, and any whitespace change invalidates it. It reduces the cost of re-reading. It does nothing about the cost of re-thinking.

Vector retrieval goes one layer further by making the corpus addressable, but it retrieves text, not conclusions. A RAG hit on a COBOL paragraph still requires the model to work out what the paragraph means, every time. It compresses the payload; it does not eliminate the derivation.

A cached conclusion is qualitatively different from a cached token. It can be reviewed by a human, approved, versioned, superseded, cited in an audit response, diffed across releases, and queried by systems that were never part of the original conversation. It is an asset on the balance sheet of the program rather than an artifact of one engineer's afternoon.

3. The NextGen Model: Extract Once, Govern, Serve

3.1 Deterministic First, Probabilistic Only Where Necessary

The architectural commitment that makes the economics work is the coupling of a deterministic parser to the LLM layer, rather than treating the LLM as the parser.

A large class of facts about a legacy estate are exactly computable and should never be inferred by a language model: call graphs, copybook expansion and field-level usage, CRUD matrices against VSAM/DB2/IMS, JCL job-step dependency chains, dead code and unreachable paragraphs, data lineage across program boundaries, RACF/ACF2 resource associations. A parser produces these deterministically, cheaply, exhaustively, and identically every run.

The LLM is then reserved for what only it can do: reading intent from procedural code, distinguishing a business rule from an implementation artifact, expressing a condition in domain language, and classifying rules against a taxonomy.

This division has three effects:

• Cost. Structural facts are computed at near-zero marginal cost instead of being re-inferred at token prices.
• Accuracy. The LLM is never asked to hallucinate a call graph, because it is handed one.
• Payload reduction. The parser produces a reduced, relevance-dense input for the model — the specific paragraphs and data items in scope, not the whole compilation unit. This is the single biggest lever on tokens per derivation.

It is also, incidentally, the architecturally distinctive element of the system rather than the LLM application alone.

3.2 The Multi-Pass Extraction Pipeline

NextGen extracts through successive passes, each consuming the structured output of the last rather than re-reading source:

Pass	Purpose	Input	Relative cost
Pass 0	Domain profiling — establish estate vocabulary and taxonomy	Sampled corpus	Low, one-off
Pass 1	Technical rule extraction per program	Parser-reduced source	Highest
Step A	Functional unit clustering	Pass 1 artifacts	Low
Pass 3	Bottom-up business rule synthesis	Clustered artifacts	Medium
Pass 4	Domain classification against taxonomy	Rule statements only	Very low (small model)
Pass 5	Cross-program consolidation and deduplication	Portfolio rule set	Medium, one-off

The critical property: only Pass 1 touches source code. Every subsequent pass operates on compact structured artifacts measured in hundreds of tokens rather than tens of thousands. This is why total extraction cost is dominated by a single pass over the estate rather than by the number of analytical passes performed.

A second property compounds it: the marginal cost per program declines across the portfolio. By program 400, the domain taxonomy is established, terminology is normalised, and Pass 5 is recognising duplicates rather than deriving new rules. Ad-hoc prompting has no such amortisation curve — the 1,000th session costs exactly what the first did.

3.3 What Gets Persisted

The repository holds, per rule and per program:

• Canonical rule statement in domain language, with a stable identifier
• Source provenance — program, paragraph, line range, copybook, commit
• Derivation lineage — which pass produced it, under which prompt version, using which model
• Taxonomy classification and compliance-stream mapping
• Confidence, review status, approver, and supersession history
• Structural facts from the parser: dependencies, lineage, CRUD, reachability
• Cross-references to duplicate or conflicting rules elsewhere in the estate

The last two points are what make it a governed asset rather than a cache. A conclusion with provenance and an approval state can be relied upon. A chat transcript cannot.

3.4 Retrieval-Assembled Context

Once the repository exists, answering a question is a fundamentally different operation. Instead of loading the program and asking the model to work it out, the system assembles a targeted context: the relevant rule statements, the dependency slice that matters, the taxonomy branch, the related rules from elsewhere in the estate.

Typical assembled payload: 3–8K tokens, against 40–120K for the raw equivalent. And because the payload is curated rather than exhaustive, answer quality typically improves — the model is not being asked to locate a needle in 100K tokens of procedure division.

4. The Cost Model

The figures below are illustrative and built on stated assumptions. Every organisation should substitute its own. The point is the shape of the curve, not the absolute number.

4.1 Reference Estate and Assumptions

Parameter	Value
Programs in scope	1,200 (≈2.4M LoC COBOL)
Copybooks / JCL members	4,000 / 900
Average analysis payload per program (source + dependencies)	50K tokens
Engineering touchpoints per program over programme lifetime	2.5
Programme duration	24 months
Model rates (Anthropic published list, August 2026)	Opus 5: $5/$25 per MTok · Sonnet 5: $2/$10 · Haiku 4.5: $1/$5
Prompt caching	Cache read at 0.1× input; 5-min write at 1.25×; 1-hr write at 2×
Batch API	50% discount, applied to offline extraction passes

4.2 Scenario Comparison

Scenario A — Direct interactive use (chat interface). Engineer loads the program and its dependencies, works through ~10 turns. In-session caching applies to the stable prefix. Effective input ≈ 128K tokens per session, output ≈ 12K.

Scenario B — Direct agentic use (coding agent on the repository). Agent explores autonomously: greps, reads, follows CALL chains, re-reads. ~25 tool-call turns, accumulating transcript, ~80% cache hit rate on the stable prefix. Effective input ≈ 700K tokens per task, output ≈ 38K.

Scenario C — NextGen repository-backed. One-time multi-pass extraction across the estate, then retrieval-assembled queries at 6K in / 1.5K out.

	A: Interactive	B: Agentic	C: NextGen
Effective input tokens per unit of work	~128K	~700K	~6K
Cost per unit of work (Opus-class)	~$1.20	~$4.45	~$0.03
Units across programme (1,200 × 2.5)	3,000	3,000	3,000
Subtotal — derivation / query	~$3,600	~$13,400	~$90
Re-runs, re-asks, new joiners (×2.5 realistic)	~$9,000	~$33,500	~$225
One-time extraction (all passes, blended models, batch + cache)	—	—	~$1,500–3,000
Total token spend	~$9,000	~$33,500	~$1,600–3,200

Two honest observations about this table. First, raw token spend is not a large number in any scenario. Anyone claiming millions of dollars of token savings on an estate this size is selling something. A 10–20× reduction on a $33K line item is worth having, but it is not the business case. Second, the business case is directly beneath it. Token cost is the visible tip of a cost structure whose bulk is human.

4.3 Where the Money Actually Is

Cost category	Ad-hoc pattern	Repository-backed	Basis
Engineer reconstruction time	25–40 min per program re-engagement	2–5 min lookup	3,000 engagements × 25 min saved ≈ 1,250 hours
Rework from divergent rule statements	8–15% of extracted rules require reconciliation	Single canonical statement	Reconciliation ≈ 2–4 hrs per disputed rule
Audit evidence production	Re-derive and reconstruct on request	Query existing provenance	Days → hours per request
Onboarding a new engineer	Full re-derivation of estate understanding	Repository orientation	Weeks → days
Model deprecation / upgrade	Session knowledge evaporates entirely	Artifacts persist; re-validate selectively	Recurring, every 6–12 months

At a blended $95/hour, the reconstruction-time line alone is approximately $118,000 on the reference estate — roughly 35× the entire agentic token bill. Add rework and audit response and the ratio widens further.

This is why the argument for a repository is not fundamentally a token-cost argument, even though the token-cost argument is real and favourable. It is a labour-amortisation argument that happens to also cut the API bill by an order of magnitude.

4.4 The Amortisation Crossover

The structural point, stated plainly:

• Ad-hoc cost scales as O(programs × people × phases) — linear in every dimension, with no decay
• Repository cost scales as O(programs) once, plus a near-zero marginal query cost that declines with portfolio maturity

Break-even on the reference estate arrives at roughly 250–400 program-engagements — typically inside the first quarter of a modernization programme. Everything after that point is compounding return. On estates of 3,000+ programs, or programmes running beyond 18 months, the crossover arrives materially earlier and the gap widens for the remaining duration.

5. Consistency Is the Same Asset as Efficiency

It is worth stating explicitly that the efficiency case and the governance case are not two benefits. They are one property viewed from two angles.

The reason a repository is cheap is that it answers from a stored conclusion. The reason it is auditable is that it answers from a stored conclusion. Determinism at the reference layer is what delivers both — even though the derivation itself used a stochastic model.

Practically, this means:

• Same question, same answer. Rule LIA-PREM-0147 reads identically to every consumer, in every sprint, in every document.
• Every answer carries a citation. Program, paragraph, line range, extraction pass, prompt version, model version, reviewer, date.
• Change is visible. When a rule statement is revised, the repository holds the prior version and the reason. A chat transcript holds neither.
• Review is possible. A subject matter expert can approve 40 rules in an afternoon. No one can approve 40 chat sessions.
• The regulator's question is answerable. "Show me every rule governing surrender charge calculation, where it lives in the source, and who signed it off" is a query, not a project.

6. Where Direct Interfaces Still Win

A whitepaper that claims its product wins everywhere is marketing. NextGen does not, and the boundary matters for anyone planning a tooling strategy.

Use a direct chat or agent interface for:

• Genuine novelty. Questions outside the repository schema — architectural judgement calls, open-ended design exploration, "what would happen if we restructured this differently."
• Early discovery. Before the corpus is characterised, exploratory prompting is exactly the right way to find out what you are dealing with. NextGen's own Pass 0 is a systematised version of the same instinct.
• Code generation and refactoring at the point of edit. A coding agent with live repository access, running tests, iterating on a diff, is better at this than any knowledge repository will ever be. This is not the same job.
• Anything requiring current working state. Uncommitted changes, live branch state, a running test suite.
• Small estates. Below roughly 100–150 programs, amortisation may not clear the extraction cost within the programme's life. Do the arithmetic before committing.

The Correct Composition

The framing "NextGen versus Claude Code" is the wrong one, and organisations that adopt it get worse results than those that don't.

The pattern that works is NextGen as the context supply for the agent. The repository is exposed as a queryable service — via MCP or equivalent — so that when a coding agent needs to know what PAYCALC01 does, it retrieves the extracted rule set and dependency slice in 5K tokens instead of reading 60K tokens of source and working it out again.

The agent gets better context, faster, at a fraction of the token cost. The repository gets a high-frequency consumer that proves its value daily. The organisation gets consistency in the specification layer and flexibility in the execution layer, which is the correct place for each.

7. Instrumenting the Claim

Do not take the numbers in Section 4 on trust — including ours. These are the metrics that let an organisation prove or disprove the case on its own estate, typically inside one quarter.

Metric	Definition	What good looks like
Tokens per resolved question	Total input+output tokens ÷ questions answered to acceptance	10–30× reduction post-repository
Re-derivation ratio	Analyses performed ÷ distinct artifacts analysed	Approaching 1.0
Context compression ratio	Raw payload ÷ assembled payload for equivalent queries	8–15×
Answer variance rate	% of repeat questions yielding materially different answers	<2%
Provenance completeness	% of rules with full source + derivation lineage	>98%
Rule reuse rate	% of queries served from repository vs. requiring fresh derivation	>85% by month 3
Amortisation curve	Cumulative cost per program, plotted against program count	Monotonically declining
Time-to-answer	Median minutes from question to cited answer	25 min → <5 min

Run a bounded pilot: 50–80 programs, both patterns, measured. The amortisation curve either bends or it does not, and it will be visible well before the pilot ends.

8. Adoption Pattern

Phase 1 — Calibrate (weeks 1–4). Pass 0 domain profiling on a representative sample. Establish taxonomy, terminology, and payload-reduction ratios. Baseline the ad-hoc pattern's token and time cost on the same sample so the comparison is like-for-like.

Phase 2 — Prove (weeks 4–10). Full pipeline across a bounded slice — one business domain, 50–150 programs. Instrument every metric in Section 7. SME review of extracted rules establishes accuracy alongside cost.

Phase 3 — Scale (weeks 10–28). Portfolio-wide extraction, batch-processed. Cross-program consolidation. Amortisation curve becomes observable and should be reported to the programme steering group monthly.

Phase 4 — Serve (ongoing). Expose the repository to downstream consumers: coding agents, test generation, target design, compliance mapping, audit response. This is where the return compounds, because each new consumer amortises the same fixed extraction cost across more work.

9. Conclusion

The question facing modernization programmes is not whether to use large language models on legacy estates. That is settled; the capability is real and the alternative is worse.

The question is whether the understanding those models produce is an asset or an expense.

Treated ad-hoc, it is an expense — recurring, unbudgeted, invisible in the finance system, and paid once per person per question per phase for the duration of the programme. It produces fluent answers that no two people can agree on and no auditor can trace.

Treated as a repository, it is an asset — derived once, governed, versioned, cited, and referenced at negligible marginal cost by every downstream consumer including the coding agents that would otherwise have re-derived it.

The token savings are real and run to roughly an order of magnitude. They are also the smallest part of the argument. The larger part is that an organisation which has mined its estate once, properly, owns a specification of its own systems — and an organisation which has prompted its way through the same estate owns a folder of transcripts.

Appendix A — Model Assumptions in Full

Assumption	Value	Sensitivity
Average program size	2,000 LoC	High — scales linearly
Tokens per program incl. dependencies	50K	High
Tokens per assembled repository query	6K	Medium
Turns per interactive session	10	Medium
Tool-call turns per agentic task	25	High — dominant in Scenario B
Agentic cache hit rate	80%	High
Touchpoints per program	2.5	High
Re-run multiplier	2.5×	Medium
Extraction re-run/QA overhead	+40%	Low
Blended engineer rate	$95/hr	High — dominant in Section 4.3
Model mix, extraction	70% Sonnet-class, 30% Opus-class	Medium
Model rates	Anthropic published list, August 2026	Snapshot; ratios more durable than absolutes

Substitute local values before quoting any figure externally.

Appendix B — One Question, Three Ways

"What conditions cause a policy to be flagged for manual underwriting review, and where is that implemented?"

	Interactive chat	Coding agent	NextGen repository
Context loaded	Program + copybooks pasted, ~55K tokens	Autonomous exploration, ~180K accumulated	12 rule records + dependency slice, ~5K tokens
Turns	6–8	22	1
Effective input tokens	~110K	~640K	~5K
Elapsed time	20–30 min	8–12 min	<1 min
Answer form	Prose, session-specific phrasing	Prose + file references	Canonical rule statements + citations
Reproducible	No	No	Yes
Cites source lines	If asked, unverified	Usually	Always, verified at extraction
Cost	~$0.75	~$3.40	~$0.03
Reusable by next person	No	No	Yes — same record

The cost differential is a 25–100× spread. The reproducibility differential is categorical.

© 2026 BlueDrop. All rights reserved.