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 confirms the operation fits and, when an included allowance is involved, after 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.

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.

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. They show published rates, not your measured baseline.

For a public assessment, read the public pricing page 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.

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:

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

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.

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 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.