What AI code review costs per day, and how teams cut it

The question usually comes up when the review bot becomes its own line on the monthly invoice. This article prices one bot on three open models, with and without caching, and shows where the spend cap goes.

What drives the cost of AI code review

Two things multiply the cost of a review bot: how often it runs, and how much text it reads each time.

Runs come first. By default, a GitHub Actions workflow on the `pull_request` event runs when a pull request is opened or reopened. It also runs when the head branch is updated. The head branch is the branch you push your changes to, so every push starts a new run. A pull request with four fix-up pushes, small follow-up commits after review feedback, therefore gets five reviews. GitHub's `types` keyword limits which activity types start the workflow, but this article keeps the default and cuts the price of each run.

Tokens come next. A token is the unit a model reads and writes, and you pay per million of them. A review bot works as an agent loop. It asks the model several times in a row to read the diff, open files and run tools. Each request sends the system prompt, the review rules and the context gathered so far again.

Most of the tokens in a run are input tokens, the text you send. Output tokens, the comments the model writes, are the smaller part, so input drives the bill. Our guide on what coding agents cost per token shows the same pattern for coding agents in general.

AI code review cost per pull request and per day

A run bills three kinds of tokens, each at its own price. The daily cost is the cost of one run times the runs a day.

cost of a run = (new input tokens x input price)
              + (cached input tokens x cached input price)
              + (output tokens x output price)
daily cost    = runs a day x cost of a run

Without caching, all input tokens count as new input tokens.

Here is a calculated example with hypothetical inputs, not a measurement. Your team opens 40 pull requests a day, and each gets 5 review runs, so the bot runs 200 times a day. One run is an agent loop of 10 requests. Each request averages 60,000 input tokens and 1,000 output tokens, so a run reads 600,000 input tokens and writes 10,000 output tokens.

With caching, we assume 90% of the input is a repeated start. That is 540,000 tokens billed at the cached input price. The other 60,000 tokens pay the full input price.

These are the list prices from our model pages, read 19 October 2026, in US dollars per million tokens:

Take GLM-5.3 without caching. A run sends 600,000 input tokens at $1.40 per million, which is $0.84. It writes 10,000 output tokens at $4.40 per million, which is $0.044. The run costs $0.884. With caching, 540,000 input tokens cost $0.1404 and the other 60,000 cost $0.084, so the run costs $0.2684.

Each cell below shows the cost without caching, then with caching.

Caching cuts the daily bill by 62% to 70% in this example, on every model: on GLM-5.3 from $176.80 to $53.68 a day. The model moves it further. In the per-day column with caching, DeepSeek V4.1 Flash costs $23.04 and Kimi K3 costs $147.00.

The example does not show everything. The token counts and the 90% cached share are assumptions, and caching is best-effort, so your real share may be lower. Reasoning is on by default on all three models, and its trace is billed as output, so real output can exceed 1,000 tokens per request. It also says nothing about review quality. Replace the assumptions with a week of your own numbers before you compare.

Keep your reviewer, swap the model

A working review bot can keep its tool. You change the endpoint and the model.

We are Lyceum, a sovereign European AI inference provider for open-source models. Our serverless models run in Paris and Finland, and prompts and outputs are processed, not stored, and never used for training.

For Claude Code, point it at our Anthropic-compatible endpoint, the API format Claude Code expects. Create a key with Generate API key under Inference → Serverless in the dashboard. Then set two environment variables before you start Claude Code:

export ANTHROPIC_BASE_URL=https://api.lyceum.technology/anthropic
export ANTHROPIC_AUTH_TOKEN=lk_your_api_key

Use `ANTHROPIC_AUTH_TOKEN`, not `ANTHROPIC_API_KEY`, for a bot. Both work, but the API key variable makes Claude Code ask you to approve the key on first run. That prompt fails in non-interactive use such as `claude -p` in CI.

To choose a model, pass its ID to `/model` inside Claude Code:

/model z-ai/glm-5.3

The model change takes effect with your next message, without a restart. Our guide to using our API in Claude Code has the rest.

Three models from the table fit review work:

• GLM-5.3 (`z-ai/glm-5.3`): for complex coding and long agent tasks.
• Kimi K3 (`moonshotai/kimi-k3`): for long coding sessions and reasoning.
• DeepSeek V4.1 Flash (`deepseek/deepseek-v4.1-flash`): for long, input-heavy agent workloads.

Epoch AI found that the most capable open-weight models have lagged frontier closed models by an average of four months since January 2026. Run your own review rules against a sample of past pull requests before you switch the whole repository. Serverless inference is billed per token, with no base fee, so that test costs only its tokens.

Prompt caching for repeated repo context

Prompt caching means the provider bills a repeated prompt start at the cached input price instead of the input price. On GLM-5.3 the cached price is $0.26, less than a fifth of the $1.40 input price. On our serverless inference it is automatic: there is nothing to enable.

The mechanism is a reused prefix, the identical start of a prompt. When a model reads a prompt, it stores a record of every token it has read. That record is the KV cache (key-value cache). Reusing the record means the model does not read the same text again. The vLLM documentation describes automatic prefix caching: a new request that shares the same start reuses the record and skips computing the shared part. On our side, recent prompt prefixes stay in GPU memory until newer requests replace them. A repeated start only hits the cache while it is still there.

For GLM-5.3 we went further on 5 October 2026. Since that update, every turn of a session, meaning each request in one conversation, goes back to the GPU that holds its KV cache. The context is not read twice. We cut GLM-5.3 prices the same day: cached input fell from $0.44 to $0.26 and input from $1.75 to $1.40 per million tokens. The prices in the table above are the new ones.

A cache only helps when the start of the prompt is identical. Keep the stable part at the front and vary only the tail. For a review bot, that order is:

1. System prompt and review rules, word for word the same on every run.
2. Repository context the bot always loads, such as style guides or architecture notes.
3. The diff of the latest push, last.

A timestamp, a run ID or a shuffled file list near the top changes the start, so nothing after it is reused.

Caching is best-effort: a request may or may not find your earlier prompt still cached, depending on recent traffic. Check what you got in the usage object of each response. Read it defensively, because `prompt_tokens_details` is missing entirely on a cache miss:

details = resp.usage.prompt_tokens_details
cached = details.cached_tokens if details else 0
print(resp.usage.prompt_tokens, cached)

Watch the output side too. The reasoning trace is the text a model writes while it thinks, and it counts as output tokens. Kimi K3 output costs $15.00 per million. Setting the request parameter `reasoning_effort` to `"none"` turns reasoning off on Kimi K3 and DeepSeek V4.1 Flash. On GLM-5.3 it does not: the setting moves the reasoning into the answer, so do not rely on it there. The serverless docs list each model's default.

Cap and track review spend per API key

A spend limit keeps a saving from turning into a surprise. Give the review bot its own key, so its usage and cap stay separate.

An owner or admin can put a spend limit on a key: a cap on what that key may spend on serverless inference. Once the key reaches it, new requests are refused with HTTP 402 and the error code `api_key_spend_limit_reached`. The limit either renews monthly or is a fixed budget. A fixed budget does not reset. Once it is used up, every request from that key gets a 402 until an owner raises or resets it, so the bot stops reviewing. We suggest a monthly limit for a bot that runs every day.

It is a soft limit, so leave some headroom: spend is counted in a billing ledger that is updated every few minutes. Make the CI job fail on a 402 instead of retrying.

In the dashboard, set the cap under Account → API keys with Set spend limit. Track the result under Inference → Serverless → Usage. It shows input, output and cached tokens per model, member and API key. Group by API key to see the bot alone.

We recommend fixing the prompt order first. Then compare models on a week of usage: a cached share near your assumption, and review quality your team accepts. Create a key with a spend limit for the review bot, point it at our serverless inference and compare a week per model.