Alex Karp made the argument in shareholder commentary and press appearances this week and the first part deserved to land. Palantir's chief executive has been warning against what he calls "tokenmaxxing" — the organisational habit of paying per-token to rent hosted intelligence rather than owning the substrate that produces it.[^1] His case is structural. Any organisation building its operating future on rented tokens is building on ground it does not control. Access can be throttled. Pricing can be revised upward in the same quarter the budget closed. The intelligence that looked like a strategic asset turns out, on the next contract renewal, to have been a subscription.
The week handed him some evidence. Fable 5 — Anthropic's latest frontier model — returned to enterprise customers after its earlier disruption, but not on the same terms it left.[^2] Among a sample of twelve enterprise routing configurations tracked through practitioner networks, nine required material adjustment to accommodate the changed conditions (n=12; directional and illustrative, not a census). The market read the moment as a Palantir confirmation: shares moved roughly 8-9% in a single session on the thesis that if you cannot trust the hosted tap, you should own the weights — per CNBC, a single-day figure, not a trend.[^3] Karp was making the argument before that move; the market amplified it.
We think he is right about the first trap. Per-token renting of hosted intelligence is a dependency, and dependencies get priced. What he goes quiet about is the second trap — the one he is selling. And neither his warning nor his solution names the third layer in the stack. That layer is the only one that compounds.
The argument that lands
Strip the tokenmaxxing critique down and three components emerge, all defensible.
The first is access risk. Hosted model providers can restrict, ration, or reprice access without notice. The export-control cycle that disrupted frontier-model availability earlier this month demonstrated this in real time: governments pulled levers, enterprise workflows adjusted, and organisations that had built operational procedures around a single hosted tap found out what their SLAs were actually worth under pressure. Nothing in most enterprise AI contracts prevents this.
The second is pricing risk. The economics of hosted inference favour the vendor over time. As model capability increases and switching costs accumulate — because the context, the prompts, the fine-tuned behaviours, and the routing logic are now calibrated to one provider's specific model — the vendor's pricing power increases alongside the switching cost. McKinsey estimates AI infrastructure spending moving toward $600B by end of decade (directional; McKinsey estimate, scope to be confirmed).[^4] The organisations paying into that number rather than owning a piece of it are funding their own dependency.
The third is lock-in by stealth. The capability your teams are building — the prompts, the agent workflows, the routing logic, the evaluation criteria — is being calibrated to a specific model's behaviour. When that model version is deprecated or the access terms change, the calibration work does not transfer automatically. What looked like internal capability is, on closer inspection, a model-specific configuration. That configuration is not yours. It is a lease on a specific version of someone else's asset.
Karp's diagnosis of the first trap is accurate. The question is what the alternative actually is.
The trap inside the answer
Here is where the week's argument goes quiet on the part that matters. The solution Palantir is selling — own your weights, own your compute, run models on NVIDIA infrastructure, partner with Palantir for the integration layer — is not sovereignty. It is a second, more expensive dependency dressed as sovereignty.
The tell is in who is rejecting the pitch.
The governments Palantir targets most aggressively with the sovereignty argument — governments that genuinely need to own their intelligence infrastructure, not rent it from a US technology firm — have looked at the Palantir arrangement and reached a different conclusion. UK parliamentary scrutiny of the NHS data contract raised substantive documented concerns about Palantir itself as a sovereignty risk: the degree of data access, the governance arrangements, the exit provisions.[^5] Spain and France have each surfaced reservations at government level about specific Palantir contract terms — neither accepted the sovereignty framing without challenge (medium confidence; reported, not primary-verified).[^6]
The irony is structural, not incidental. A firm selling sovereignty to governments is being evaluated by those same governments as a sovereignty risk. That is not a peripheral detail. It is a precise description of the second trap: a dependency that costs more and carries a longer exit tail than the first one, sold under the branding of ownership.
If the per-token model is rented intelligence, the Palantir model is rented sovereignty. Both are dependencies. The first is cheap until it reprices. The second is expensive from day one and nearly impossible to exit cleanly once the integration layer is embedded. Neither is the answer to the question Karp is correctly asking.
Three layers nobody mapped together
The debate that ran through this week's coverage mapped two layers of the dependency stack and missed the third. We can be precise about what all three actually are.
Layer 1 is rented intelligence: pay per token, access hosted models, build workflows on top. This is the tokenmaxxing trap Karp is naming. He is right about the risk. The intelligence is rented, availability is not guaranteed, and pricing is not fixed.
Layer 2 is owned infrastructure via vendor: own the weights, own the compute, run the models on hardware you or your vendor controls. This is the solution Karp is selling. What he is not saying is that the integration layer — the connective tissue between your data, your workflows, and those weights — is still rented. The Palantir AIP layer is not yours. You have traded one dependency for a costlier one with a longer contract and a higher switching cost.
Layer 3 is owned operating capability: the context, the decision rights, the review gates, the routing logic, the institutional knowledge of what the intelligence is supposed to do and why. The working command of which tasks have moved to AI, which remain with people, and why the boundary is drawn where it is. The capability to absorb a new model, a changed access tier, a repriced contract — and keep operating — because the capability is yours regardless of which substrate delivers it.
Layer 3 is the only layer that answers the question neither Karp's warning nor Karp's solution resolves: what do you have left when the vendor exits, reprices, or gets rationed? If the answer is workflows, people who know how to run them, and institutional command of the decisions those workflows support — you have a capability. If the answer is access to a model you no longer fully control, or weights on infrastructure you cannot exit, you have a lease. A more expensive lease than the one Karp warned you about.
This is the layer nobody named this week. We will name it: the Layer 3 gap. The distance between what most organisations are building in the current AI spend and the capability that survives when the vendor terms change.
Why Layer 3 is the load-bearing one
Capability compounds. Tokens and weights do not.
When an organisation builds genuine Layer 3 capability — the standing ability to absorb new tools, govern which tasks move to AI, and own the context rather than renting the interface — it gets better at transforming faster than the tools change. Each time the AI substrate shifts, the organisation adapts more quickly than it did the last time, because it has built the muscle. The capability accumulates in the organisation, not in the vendor's contract. Transformation Capability Management is the discipline that makes this possible: the client-side method for absorbing change, governing transition, and owning the operating layer that persists across model generations.
Hosted intelligence does not compound on your side of the ledger. You pay for more tokens; you get more inference. You own more weights; you get more compute. Neither investment compounds into something you own at the end. The vendor's asset base grows. Yours stays flat.
Anthropic has stated — and we carry this as a vendor claim, not as independently verified figures — that fewer than 5% of enterprise AI spending reaches measurable operating outcomes.[^7] Whether or not that precise figure holds under scrutiny, the directional point matches what we observe: most of the current AI build-out spend is concentrated in Layer 1 and Layer 2, and most of it is not compounding into the organisations that are spending it. The compound accumulates at the model providers and the infrastructure vendors. That is exactly the condition Karp is describing. It is also exactly the condition his solution perpetuates — at a higher price point, on a longer contract, with a more expensive exit.
The answer to the tokenmaxxing trap is not better tokens or owned weights. It is Layer 3. Capability sovereignty: the standing ability to make strategic decisions about what you build, what you rent, and what you own — because the Layer 3 capability is what makes those decisions executable regardless of which model answers the phone this quarter.
What this asks of your architecture
The practical question is not which AI vendor to trust. That question resolves itself at your next contract renewal. The practical question is what your organisation is building that survives the renewal — not in the legal sense, but in the operational sense.
If your teams can diagnose which tasks have moved to AI and which have not, and why, you have Layer 3. If your transformation office can evaluate a new model and decide whether to adopt it — based on your own criteria, not the vendor's marketing — you have Layer 3. If your review gates, routing logic, and decision rights sit inside the organisation rather than inside an integration layer you licence, you have Layer 3.
If none of those things are true yet, you are running a Layer 1 or Layer 2 estate and calling it transformation. Karp is right that the first option is a trap. He is not naming the third option because the third option would make his second option unnecessary.
The full analysis of this week's vendor positioning, the government rejection patterns, and the Layer 3 capability architecture is in The Capability Brief — Edition 15. The signal summary is in Signal — Edition 19.
Your Waypoint
One layer. One test. Thirty minutes.
Take the single most consequential AI-enabled workflow your organisation has built in the last twelve months — the one with real operational weight, not a pilot. Put it through what we call the vendor-exit test.
Ask: if the model behind this workflow were deprecated tomorrow — replaced by a new version with different behaviour or different access terms — what would still be yours? Write two columns. Column one: what the organisation owns. The criteria for routing decisions. The review gates. The institutional context for why this task was designed this way. The people who understand the logic. Column two: what is vendor-held. The model's specific behaviour patterns. The API shape you calibrated to. The integration layer that connects your data to someone else's inference.
If Column one is substantial and Column two is thin, you have Layer 3 capability: a working capability that adapts when the substrate changes, because the capability is not the substrate. If Column two is where the real operating logic lives, you are in the Layer 3 gap — running on a layer you do not own, dressed as transformation.
The test does not tell you to stop renting intelligence. Renting intelligence is sensible. It tells you where the boundary is — which layer the compounding is happening in, and whether you are building the one that survives.
That is the question Karp is not asking. It is the only one worth answering.
References
[^1]: Alex Karp (Chief Executive, Palantir Technologies) — commentary on "tokenmaxxing" and the risk of per-token intelligence renting as an organisational dependency trap, shareholder communications and press appearances, late June–early July 2026. Paraphrase throughout; no verbatim quotations used. Carried as the argument being made, not as independently verified claims about market conditions or competitor capabilities.
[^2]: Fable 5 (Anthropic), enterprise access restored after earlier disruption on revised commercial terms, reported around 30 June–3 July 2026. Among a sample of twelve enterprise routing configurations tracked through practitioner networks, nine required material adjustment to accommodate the changed conditions; n=12, illustrative and directional, not a census. Reported; exact revised terms remain in flux at time of writing.
[^3]: Palantir Technologies share price movement, approximately +8-9% in a single trading session attributed to investor thesis about owned-weights/compute as an access-risk hedge; per CNBC, single-day figure, not a trend or sustained move. Reported; not independently verified against primary market data.
[^4]: McKinsey Global Institute estimate, approximately $600B; directional, unverified against primary publication; year and scope not confirmed.
[^5]: UK Parliament — documented parliamentary scrutiny of the Palantir NHS data contract; concerns raised over the degree of data access, governance arrangements, and exit provisions. Described as a long-running parliamentary record, not a single-event claim. Strong attribution; publicly documented in Hansard and committee proceedings.
[^6]: Spain and France — government-level reservations about Palantir contract terms surfaced during procurement and policy review processes. Medium confidence; reported through press coverage of respective government procurement debates, not primary-verified against official government statements at time of writing.
[^7]: Anthropic — fewer than 5% of enterprise AI spending reaches measurable operating outcomes; vendor claim, carried as the argument being made, not as independently verified figures. Source: Anthropic commercial communications, approximately Q1–Q2 2026.
[^8]: BusinessGPS, Transformation Capability Management v2.2, 21 May 2026; The Chief Work Officer Is the Role. Transformation Capability Management Is the Discipline., The Way Pointer — Edition 18, 29 June 2026; When the Substrate Gets Switched Off, The Way Pointer — Edition 16, 15 June 2026; The Capability Brief — Edition 15 and SAP Compass — Edition 9, 6 July 2026 (companion intelligence editions).
The Way Pointer is published by BusinessGPS — the transformation capability platform helping organisations make strategic choices about what they build, what they buy, and what they own.