> ## Documentation Index
>
> Fetch the complete documentation index at: https://lithi.ai/llms.txt
>
> Use this file to discover all available pages before exploring further.

# Compare AI API costs for your task

Compare the cost of getting the same result through Lithi and your current workflow. Include the work
your agent still does, and count each charge once. Run this after [Choose work](/docs/compute/choose-work)
confirms the operation fits and, when an included allowance is involved, after [Usage fit](/docs/compute/usage-fit)
decides whether now is the right moment. Use authorized evidence to measure the work; never guess the
current price or balance.

A quote is evidence for a decision, not permission to spend. A comparison can honestly say to keep
your current path, wait, or that the evidence is not comparable.

## Compare Claude Code, Codex or Cursor work

Ask your agent to identify the billing path used for this task. An included subscription allowance,
purchased credits and a direct API meter are different pools; use the actual pool and current rates
rather than assuming the product name tells you the price. For direct API work, compare equivalent
input, output, quality and review with the Lithi quote, including work your agent retains. Continue
on the current path when it makes sense, wait if an allowance reset fits your deadline, or delegate
when the supported task and total cost make that useful.

## Compare the same decision

The first seven checks are gates. If one differs, the two costs describe different work and no
arithmetic repairs the comparison.

| What must match | Why |
| --- | --- |
| Task | A narrower prompt is a different task, not a cheaper version of the same one. |
| Volume | Compare the same items, pages or other natural unit. |
| Output | The accepted fields and artifact shape must match. |
| Quality threshold | A lower acceptance bar changes the result being bought. |
| Verification | Include the checks the current path requires, or exclude them from both sides. |
| Timing | A rush result and a queued result are different commitments. |
| Permitted data handling | Both paths need to support the data profile you approve. |

Then gather the evidence that completes the arithmetic:

- a measured current baseline from an authorized source and the actual model meter when the current
  path uses an API;
- a current signed quote with its maximum charge;
- any retained frontier work that still happens with your existing agent, including planning or
  review that remains in a hybrid path;
- cache fees, batch fees, retries and retained planning or review on the side that pays them;
- preparation, transfer, verification, delivery and human-review overhead that sits outside the
  quote; and
- the partial-failure rule for work that fails or abstains.

Count each item once. The quote's included platform transfer, default checks, normal retries, delivery
and repair are one included group; do not add any of them again. If work stays with your existing
agent, record that retained work once rather than charging it to both sides. A genuinely zero
overhead is evidence with amount zero; an omitted overhead is unknown.

## Keep billing shapes separate

Use the pool's actual billing shape. A plan name, model name or host class does not establish it.

| Current path | What to compare |
| --- | --- |
| Subscription with an included allowance | Inside the allowance, marginal cash cost is zero. Usage fit can decide whether preserving room for later work is useful. That preserved allowance is not cash savings. |
| Metered API or bring-your-own key | Use the actual model meter, current rate source and fees for the same work. Usage fit does not apply because there is no included allowance to preserve. |
| Purchased or prepaid credits, metered usage pool or enterprise usage | Treat each consumed credit or unit as metered cost. Do not describe moving the work as preserving a subscription allowance. |
| Hybrid | Add the current path's retained planning, context or review cost once, then add Lithi's signed quote and any Lithi-side overhead. Keep each pool's unit and evidence separate. |

An included subscription allowance that happens to be counted in credits remains an included
allowance. Purchased or prepaid credits spent on the work are metered. If the billing shape, pool,
unit, model or fee is unknown, stop at `NOT_COMPARABLE` or `INSUFFICIENT_BASELINE` rather than
inferring it.

## Each system keeps its own meter

Lithi compares its signed quote with the current path's own measured meter. Keep a vendor’s token
count, page count, credits or compute units in that vendor’s own units when comparing costs. A natural-unit
baseline stays in that unit; if no current conversion makes the scopes comparable, the result is
`NOT_COMPARABLE`.

For a real decision, vendor rates and limits are resolved from their current source identity when the
assessment runs, not remembered from a plan name. An unknown model, region, fee or billing unit
keeps the comparison unresolved.

Lithi also publishes dated list-price comparisons for reference workloads. They are on
[Compare published prices](/docs/compute/billing/pricing-and-units#compare-published-prices). They show
published rates, not your measured baseline.

For a public assessment, read [the public pricing page](/pricing) in Markdown or HTML.
An HTTP-capable agent can also use `https://lithi.ai/api/public/compute/pricing` for structured rates.
JSON is optional when the current page provides the required rates and units. Record the source and retrieval date, check
USD and per-million-token input/output units, and keep conflicting or unreadable sources unresolved.
Both formats project the same information rates; neither issues a quote, reserves capacity or
authorizes execution.

For a simple planning illustration only, the public Compute pricing information lists **$0.05 per
million input tokens** plus **$0.10 per million output tokens**. The code-review example below uses
explicitly assumed Lithi-metered quantities. It is not a customer charge, reservation or execution
approval. A current signed quote supplies the maximum charge for a real decision.

### Estimate a code-review packet

For an arithmetic illustration, suppose 100 bounded review packets each contain 8,000 complete
input tokens and return 1,000 output tokens. Include the review instructions and all repeated caller,
type and test context in that input assumption.

| Component | Assumed quantity | Informational estimate |
| --- | --- | --- |
| Input | 100 × 8,000 = 800,000 tokens | $0.04 |
| Output | 100 × 1,000 = 100,000 tokens | $0.01 |
| Total Lithi processing | 900,000 tokens | **$0.05** |

Your existing agent still selects the packets, resolves findings, applies accepted repairs and
verifies them. That retained work consumes its own allowance or metered budget. For an included
subscription, the potential benefit is demand avoided in the same pool, not a lower subscription
fee. For API billing, compare the same accepted review quality and volume with the current path's
actual meter and rates. These assumptions are not measured usage, a quote or evidence of savings.

Keep the current model's input, cached-input and output counts in that model's own units. Keep the
other provider's token counts separate from the counts measured by Lithi. Include that provider's
cache, batch and retry charges according to its own meter, and compare the resulting workload total
with the signed quote on the same output, quality, timing and data-handling basis.

For a comparable decision, calculate the totals explicitly:

```text title="Estimate a code-review packet" kind="rules"
current comparable baseline = measured current-path charges
                            + required current-path costs not already included

Lithi comparable total = signed quote maximum charge (or a clearly labeled public planning estimate)
                       + retained current-agent planning and review
                       + required costs not already included in the quote or retained work

potential difference = current comparable baseline − Lithi comparable total
percentage difference = potential difference ÷ current comparable baseline × 100
```

Compute the percentage only when the current comparable baseline is greater than zero. A positive
difference means the Lithi path is lower; a negative difference means it is higher. Use each
provider's applicable cache and batch rate for the billed units, rather than adding a discount as
another charge. Do not add platform transfer, default checks, normal retries, delivery or repair a
second time when the quote includes them, and do not add retries already represented in measured
consumption. A labeled public estimate or modeled difference is not measured savings.

Use zero only when the evidence shows that a component is genuinely zero. An omitted component is
unknown, so the comparison stops rather than understating one side. If any task, volume, output,
quality, verification, timing or data-handling check differs, these totals are for different work and
the result is `NOT_COMPARABLE`.

## Plain outcomes

| Result | Meaning |
| --- | --- |
| Lower cost | The comparable Lithi total is lower. |
| Similar cost | The totals are close under the evaluator's rule. |
| Higher cost | The comparable Lithi total is higher. |
| More evidence needed | A required baseline, fee, unit or comparison condition is unresolved. |
| Current quote needed | There is no usable current quote. |

This table keeps the reader decision separate from the helper contract. If a required baseline, fee,
unit or comparison condition is unresolved, keep the result in `NOT_COMPARABLE` or
`INSUFFICIENT_BASELINE`; if there is no usable current quote, use `QUOTE_REQUIRED`. A measured zero
baseline is `ZERO_BASELINE`, so no percentage difference is claimed. For the exact
`evaluateEconomics` fields, including `comparability`, `position` and composed outcomes, use the
[Kit helper reference](/docs/compute/kit/reference).

## Subscription allowance is not cash savings

Within an included subscription allowance, the current task's marginal cash cost is zero. The plan's
subscription fee is a shared or fixed charge, not a per-task saving estimate unless you have a
declared, measured allocation rule. After the allowance is exhausted, the baseline may include an
overage charge. A move can preserve room in the same pool while still receiving `LITHI_HIGHER_COST`
against a zero marginal baseline. Do not add allowance preservation to direct cost or describe it as
prepaid cash savings, a subsidy, a quota top-up or a way around provider limits.

For an API key or another metered pool, every unit already has a price. Usage fit is skipped and cost
fit compares the measured baseline with the signed quote. If the current API is rate-limited, the
evaluator may add `API_RATE_LIMIT_CONSTRAINED` and the next step `weigh_throughput_against_cost`.
That is a throughput consideration; it does not override quality, privacy, comparability or a higher
cost result.

## Keep timing and approval separate from price

Use the urgency policy from [usage fit](/docs/compute/usage-fit) when a reset or deadline matters.
Compare the time left with the estimated end-to-end duration, including preparation, approval,
transfer, execution, verification, delivery and reserve. Unknown duration supports no speed claim.
Waiting for a near reset can be the right decision even when a quote is available; a deadline can
make a current quote worth reviewing even when it is not cheaper.

Your rules can set allowed tasks and data, a maximum charge, a minimum saving or allowance benefit,
a quality floor, a deadline and a reset threshold. Pause when any required fact is unknown. These
rules guide a user-controlled assessment; they do not trigger automatic transfer or execution. Keep
the current quote, any data-transfer approval and paid execution approval as separate decisions.

Lithi can assess a supported bounded task even when it is urgent or not especially large and flexible.
It may use many admitted Macs after approval, but the customer does not shard the work or choose
placement. More Macs do not create a linear speed multiplier; capacity and completion speed remain
subject to the quoted operation and current admission conditions.

## A concrete decision

For a fictional 40-invoice sample, Maya needs the same extracted fields and page citations
on both paths. Her current path has a measured baseline. The Lithi side has a signed
quote, and both sides include the same verification and human review. If the quote is higher, the
answer is `LITHI_HIGHER_COST`, even if moving the sample would protect her subscription window. If
the baseline is stale or the review differs, the answer is `INSUFFICIENT_BASELINE` or
`NOT_COMPARABLE`, not a savings estimate.

Review the evidence, maximum charge, data profile and approval before execution. Getting an estimate
or quote creates no paid Compute activity and does not change a provider quota, reset or billing plan.