Palantir AIP pricing and Foundry negotiation. Most of the price is set during the pilot.

Palantir sells AIP and Foundry as a negotiated annual platform fee with no published list, so the opening number reflects what it thinks your account will bear. The deal is won or lost in the pilot scope and the production terms agreed in advance.

How are Palantir AIP and Foundry priced?

Palantir publishes no list price for AIP or Foundry. Enterprise deals are a negotiated annual platform fee, scoped in the order form by licensed users, data domains, compute and use cases. Because there is no list, there is no discount in the usual sense. The opening number reflects what Palantir believes your account will bear.

That makes the spread between buyers unusually wide. Across our engagements, annual fees for comparable mid size deployments differed by a factor of 2 to 3, and the difference came from how each buyer negotiated rather than from what was deployed.

What Foundry actually meters

Underneath the platform fee, Foundry measures consumption in its own units. Palantir's documentation expresses all computational work as compute seconds and all storage as gigabyte months. AIP language model calls are counted in tokens and converted into compute seconds, with different rates for input and output and by model and hosting region.

• Batch, interactive and continuous compute. Pipelines, dashboard queries and always on streaming or model jobs all draw compute seconds, at different intensities.
• Storage. Data held in Foundry and in the indexed Ontology is measured in gigabyte months of allocated storage.
• AIP tokens. For GPT-4o hosted in North America, Palantir's published example converts 10,000 input tokens to 43 compute seconds and 10,000 output tokens to 172.
• Users and use cases. These sit in the commercial scope of the order form, and they are where most of the negotiation happens.

Where the published usage rates fit

Palantir states that its published compute rates apply to Foundry enrollments hosted on AWS under certain default contract terms. Existing customers are told to confirm their own rates. In practice, large AIP and Foundry buyers sign a negotiated platform agreement. The unit rates still matter, because they decide what happens when usage grows past the scope you bought.

Palantir's annual report says it generally offers contract terms of one to five years, and some customers sign shorter ones. Offer a longer term only in exchange for written protection on renewals and expansion.

Why does the Palantir pilot decide the production price?

The production proposal usually arrives after your business already depends on the pilot's output. Palantir's annual report says it gives prospective customers its platforms at no or low cost for evaluation, through short term pilot deployments that include bootcamps. Its AIP Bootcamp page promises to take customers from zero to a working use case in 5 days.

The low entry price has a purpose. During the bootcamp and the months that follow, the Ontology encodes your business logic into Palantir's data model before any production price exists. The land and expand motion is described openly in Palantir's investor materials, and it runs in three stages:

1. Bootcamp. A short engagement delivers a working use case in days or weeks, often priced near cost.
2. Adoption. Business users start relying on the output, while the Ontology and the pipelines behind it deepen quarter by quarter.
3. Production proposal. The commercial offer lands once dependence is established, when your negotiating position is close to zero.

In every case we benchmarked, pilots that started without commercial terms converted to production at materially worse pricing than pilots that began with a pre agreed production rate card.

How to run a bootcamp and keep your negotiating position

Take the bootcamp if the use case is worth testing, but first agree the rate card for production, the renewal cap and the export rights. At that point Palantir wants the logo more than you need the platform, and every one of those terms costs it little to grant.

The same sequencing applies to other AI platforms, and our enterprise AI procurement framework sets it out step by step. For the timing of usage based AI pilots more broadly, see our guide on negotiating before pilot usage spikes.

What actually lowers a Palantir fee?

Two things lowered the opening fee most in our engagements: a smaller licensed scope agreed before the order form is drafted, and a costed alternative that Palantir believes you would fund. Asking for a percentage off without either of those moved very little.

Narrow the scope before the order form drafts

Cutting licensed users, data domains and use cases before the first draft is where the largest reductions in the table came from. Scope in the first draft tends to stay, since every later cut needs Palantir's agreement. Decide what you need for the first 12 months and license that, with the rate card covering what comes after.

Cost a build path on Databricks or Snowflake

The competitive pressure Palantir takes seriously is a costed build alternative on Databricks or Snowflake, with named engineering owners and a timeline. Its sales team has lost deals to exactly that option and knows it. A vague threat to build something in house does nothing.

Price the alternative properly. Our Databricks negotiation guide and our analysis of 10 Snowflake contract clauses cover the platforms the alternative would run on. They belong in the Palantir file whether or not anything is ever built, because the credibility of the plan depends on real prices.

Why a formal RFP bake off rarely changes a Palantir price

Standard procurement advice says to run a formal bake off and let competition set the price. Against Palantir it barely moved the fee in our engagements. Palantir sells outcomes to executives, not features to procurement, and prices on that basis. Put the effort into a funded build path, and refuse to start the pilot without production terms.

What does a scoped Palantir deal look like in numbers?

The example below is hypothetical, built to show how the ranges from our engagements combine. Say Palantir opens at $4,000,000 a year for 600 users, 8 data domains and 5 use cases. You cut the first phase to 350 users, 5 domains and 3 use cases, and you fix a rate card for later additions.

Treat the ranges as negotiation benchmarks. Your own scope sets the baseline, and the savings show what disciplined buyers achieved against the same sales approach. In this example, the two added use cases alone cost $240,000 to $420,000 less a year with the rate card in place.

What will the Palantir account team say, and how should you answer?

Expect the conversation to push commercial terms past the point where you depend on the platform. These are the lines we hear most often, with the replies that worked.

• "The bootcamp is free, so there is nothing to negotiate yet." Reply that the bootcamp can start once the production rate card, renewal cap and export terms are attached to it, because production is what the bootcamp leads to.
• "We cannot price production until we know the use cases." Ask for unit prices instead: per added use case, per data domain, per user band, and the compute second rate above committed scope.
• "Databricks and Snowflake cannot do what the Ontology does." Agree that they do not do everything, and show the costed plan for the use cases actually in scope, with owners and dates.
• "Commit to five years and we will give you our best price." Accept a longer term only with a single digit renewal cap, the rate card and the exit terms in the same document.
• "You can export your data through our APIs whenever you want." Ask for it in the contract, with formats, timelines and the transition help that goes with it.

Which contract terms protect you after signature?

The terms that govern life after signature are the renewal cap, the expansion rate card, export rights and transition assistance. All four are negotiable before signature and rarely after, so they belong in the first order form.

Renewal and expansion terms

• Renewal cap. A written ceiling on the year over year platform fee increase, ideally single digit, because Palantir prices the platform as a long term operating layer.
• Expansion rate card. Pre priced units for added users, data domains and use cases. Buyers who priced phase two in contract one paid 20 to 35 percent less per added use case than buyers who did not.
• Unit rates above scope. The compute second and storage rates that apply if usage grows past the committed scope, fixed for the term. Our uplift cap redline shows wording you can adapt.

Exit and transition terms

• Export rights. Contractual documentation of the Ontology and data egress in open formats, with named timelines, agreed while they cost Palantir nothing to grant.
• Transition assistance. A defined services obligation at termination, priced in advance. If transition help is priced only when you leave, Palantir sets that price when you have the least choice.
• Pilot ownership. Confirmation that the Ontology definitions, pipeline logic and outputs built during a bootcamp belong to you, whether or not you convert.

Foundry can query tables in Databricks, Snowflake and BigQuery as virtual tables, without copying the data into Foundry. Where that fits your architecture, keeping the source data in your own platform lowers storage charges and shortens the exit. Our termination for convenience clause guide covers the related exit wording.

How do you check what you already use in Foundry?

Start with an inventory of every Palantir touchpoint already live: pilots, bootcamps and data connections. The depth of the Ontology is Palantir's bargaining strength, so you need to know it before they describe it to you.

• Resource Management. Foundry's Resource Management application reports compute seconds and gigabyte months by project, which shows where usage is concentrated.
• Ontology Manager. The object types, link types and actions defined so far show how much business logic already sits in Palantir's model.
• Data Lineage. Map which pipelines feed which applications, so you can see what would have to be rebuilt elsewhere.
• Access groups. Count the named users in the identity provider groups that grant Foundry access, and separate builders from people who only view results.
• Existing paperwork. Collect every order form, statement of work and pilot letter, including any that set compute or AIP rates.

How does the approach change for a first purchase or a renewal?

The earlier you are in the relationship, the more of this you can still win. A first purchase is the only contract you sign with the alternative still fully alive, so it prices every later deal.

First purchase or first pilot

Here everything is open, and the weeks before the pilot are your strongest point. Tie the pilot's start date to a signed production rate card. If Palantir will not price production yet, limit the pilot to a use case you could rebuild elsewhere, and keep production data connections out of it until terms exist.

Renewal or expansion of a live deployment

With pipelines and users in place, a renewal is harder. Rebuild what you can: cost a partial build path covering the next use cases, trim users who only view results, and ask for the cap and exit terms you did not get the first time as the price of a longer term.

What have we seen in recent Palantir negotiations?

Fredrik Filipsson advised on roughly 8 to 12 Palantir AIP and Foundry negotiations between 2024 and 2025. The commercial gap between similar deployments was wider than on any other platform we benchmark.

• Fee spread. Fees for comparable deployments varied 2 to 3 times over, explained by whether the buyer funded an alternative, narrowed the scope and sequenced the pilot.
• Phase two. The cheapest expansions were the ones priced in the first contract.
• Pilots. Pilots that began without production terms always converted at a worse price than those that had them.

Without a list price there is no discount to ask for, only an alternative you can prove you would fund.

When should each step of a Palantir negotiation happen?

Plan from the date any pilot would start. By the time Palantir sends an order form, most of the timing has already been set.

Before you commit to a multi year term, our GenAI vendor lock in assessment helps you score how hard an exit from the platform would be.

What to do next

1. Inventory every Palantir touchpoint already live. List pilots, bootcamps and data connections, because the depth of the Ontology is what Palantir negotiates with.
2. Cost the build alternative. Put named owners and a timeline on a Databricks or Snowflake plan, funded and visible to the board.
3. Define the licensed scope you actually need. Settle users, data domains and use cases before the order form is drafted.
4. Demand the production rate card before new pilot work starts. A pilot without terms hands the price to Palantir.
5. Write the exit into the first order form. Include renewal caps, export rights and priced transition assistance.
6. Get independent support. Our GenAI practice runs the Palantir negotiation with you, with no ties to any vendor.

Frequently asked questions