> ## Documentation Index
> Fetch the complete documentation index at: https://jupiter-docs-gacha-v2-api.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Compute Units & Priority Fees

> Control compute unit limits and priority fee percentiles on /build

The `/build` response includes `computeBudgetInstructions` with the **compute unit price** but not the **compute unit limit**. You need to simulate to determine the correct limit.

Why: since you are building your own transaction with custom instructions, the CU usage will differ from a base swap. The simulation gives you the actual number, and you set the limit with a safety buffer.

## Why this matters

Priority fee cost is calculated as:

```
priority fee = compute unit price × compute unit limit
```

A tighter CU limit directly reduces the priority fee you pay. Setting it to the maximum (1,400,000) when you only use 200,000 means you pay 7x more than necessary. See [Solana fee structure](https://solana.com/docs/core/fees/fee-structure) for details.

## Customise compute unit price

The `/build` response bakes a compute unit price into `computeBudgetInstructions` based on recent network priority fees. Use `computeUnitPricePercentile` to control how aggressively you bid:

| Value           | Percentile      | Use case                                      |
| --------------- | --------------- | --------------------------------------------- |
| `"medium"`      | 25th            | Lower fees, may land slower during congestion |
| `"high"`        | 50th            | Balanced (default)                            |
| `"veryHigh"`    | 75th            | Higher fees, better chance of landing quickly |
| Integer 0-10000 | Custom (in bps) | Fine-grained control                          |

When `mode=fast` is set and no `computeUnitPricePercentile` is provided, the default is the 90th percentile instead of the 50th.

You can also override entirely by replacing the `computeBudgetInstructions` from the response with your own `setComputeUnitPrice` instruction.

## Cap the compute unit price

<Warning>
  The estimated compute unit price tracks recent network priority fees. When recent blocks contain transactions bidding extreme values, the estimate can spike far above what is needed to land. Validate the compute unit price before signing.
</Warning>

Decode the compute unit price from the `setComputeUnitPrice` instruction in `computeBudgetInstructions` and clamp it to your own maximum. The instruction data is base64: a 1-byte discriminator (`3` for `setComputeUnitPrice`) followed by the price as a little-endian u64 in micro-lamports.

```typescript theme={null}
const COMPUTE_BUDGET_PROGRAM = 'ComputeBudget111111111111111111111111111111';
const MAX_CUP_MICRO_LAMPORTS = 10_000_000n; // set your own maximum

for (const ix of build.computeBudgetInstructions) {
  if (ix.programId !== COMPUTE_BUDGET_PROGRAM) continue;
  const data = Buffer.from(ix.data, 'base64');
  if (data[0] !== 3) continue; // 3 = setComputeUnitPrice
  const cup = data.readBigUInt64LE(1);
  if (cup > MAX_CUP_MICRO_LAMPORTS) {
    data.writeBigUInt64LE(MAX_CUP_MICRO_LAMPORTS, 1);
    ix.data = data.toString('base64');
  }
}
```

Run this on the raw `/build` response before converting the instructions for your SDK, so the same check works with both @solana/kit and @solana/web3.js. With the clamp in place, your worst-case priority fee is bounded: `CUP cap × CU limit`. A lower cap can slow landing during congestion, so pick a maximum that matches the fees you are willing to pay.

If you already maintain your own priority fee estimate, you can skip the decode: drop the returned `computeBudgetInstructions` and set your own `setComputeUnitPrice` with the lower of your estimate and your cap. A low `computeUnitPricePercentile` is not a substitute for a cap, because a percentile of an inflated fee distribution can still be extreme.

## Estimate compute unit limit

1. Build the transaction with all your instructions + **max CU limit** (1,400,000)
2. Simulate with `replaceRecentBlockhash: true` to get actual CU consumed
3. Rebuild with **1.2x the simulated value** (capped at 1,400,000) as the CU limit
4. Add the CU price instruction from the `/build` response

The [Build](/swap/build) code example demonstrates this in steps 4-5 (kit) with full working code.

<Warning>
  Setting the CU limit too tight causes transaction failures. Always use at least a 1.2x buffer over the simulated value.
</Warning>

## Related

* [Build](/swap/build) for the full code example with CU simulation
* [Transaction Submission](/transaction/submit) to submit via Jupiter's transaction landing infrastructure with SOL tips for priority processing
* [Reduce Transaction Size](/swap/advanced/reduce-transaction-size) for other optimisations