Code Review and Code Generation

Code review and code generation sit at opposite ends of the token bill. A review reads far more than it writes, because the model receives the instructions, the diff and the surrounding code and replies with a short list of findings. Generation writes far more than it reads, because the model receives a function and a short brief and replies with tests, documentation or a rewritten module. Review is an input-heavy workload and generation is an output-heavy one, and on Clarke an output token costs $7.00 per million against $1.50 for an input token.

The cost of one call is the input tokens multiplied by the input price, plus the output tokens multiplied by the output price, divided by one million.

Two worked examples to replace with your own numbers

The first is a pull request review in two passes. The first pass asks for every possible finding and the second sends those findings back and asks which are genuine.

A pull request is rarely reviewed once. A pull request that is pushed to three times can trigger three reviews, so a team of 50 engineers who each merge 20 pull requests a month, at 2.5 reviews per pull request, runs 2,500 reviews and pays about $171 a month on Clarke before prompt caching.

The second is generating unit tests for one function.

In the review example input is 95 percent of the tokens and 82 percent of the cost, so a tighter prompt and prompt caching matter most. In the generation example output is 24 percent of the tokens and 59 percent of the cost, so asking for less code per call matters most. Prompt caching can cut the cost of repeated prompts by up to 90 percent, and a review bot sends the same standards on every call.

A reviewer that explores the repository with tools reads far more than the example above. In a test published by Kilo, a review agent running Claude Opus 4.6 read 618,853 input tokens and wrote 6,142 output tokens on a 338-line pull request. At Clarke's prices the same token counts would cost about $0.971, which is why input price decides the bill for agentic review.

Measure your own diffs before you plan around any of these numbers.

Clarke is the default for code review and routine code generation. Radium lists code assistance as one of its primary uses, covering generating, debugging, refactoring and explaining code, and it handles the work most teams send to a model all day, which is commenting on a diff, writing unit tests, adding documentation, translating a function between languages, drafting a migration and explaining an unfamiliar module. Radium describes Clarke as comparable to Sonnet 5.5 and GPT-6 Sol overall and has not published a code-specific benchmark, so the section below on testing matters before you move any traffic.

Tycho does the work around the review. Use it to summarize a pull request, draft a commit message, apply labels, sort changes by risk and decide which pull requests need a deeper pass. It costs $0.50 per million input tokens and $2.25 per million output tokens, so summarizing a 6,000-token diff costs about $0.004.

Hal is for the changes where a miss is expensive, such as security-sensitive code, concurrency, database migrations, refactors that cross services and architecture-level planning. Radium describes Hal as built for deep code generation, with large codebase refactoring and multi-file implementations. The two-pass review above costs about $0.11 on Hal, so sending only the risky share of pull requests to it keeps the average close to Clarke's.

Route by the cost of a missed finding.

A review bot or coding assistant depends on a short list of API capabilities, and each one should be confirmed against your own client before production traffic moves.

Three things do not carry over unchanged. Radium does not support the Responses API yet, so a reviewer built on it has to call chat completions, and it does not offer embeddings, so code search that relies on embeddings keeps its current embedding provider. Model names from other providers return a model-not-found error until you change them to a Radium model ID. When reasoning is enabled, the response includes a thinking block before the text block, so read the last content block instead of the first.

Check each row against your own client before the cutover.

Radium serves OpenAI-compatible and Anthropic-compatible APIs, so an existing review bot or coding assistant keeps its SDK, its prompts, its tool definitions and its retry logic. Three values change, which are the base URL, the API key and the model name.

Pick the SDK you already use, then your language. The Anthropic SDK adds the /v1 path itself, so its base URL does not include it. Replace YOUR_API_KEY with your key and keep it out of your repository.

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.radium.cloud/v1",
)

response = client.chat.completions.create(
    model="clarke-1.0",
    messages=[
        {"role": "user", "content": "Hello, Radium!"}
    ],
)

print(response.choices[0].message.content)

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: "YOUR_API_KEY",
  baseURL: "https://api.radium.cloud/v1",
});

const response: OpenAI.Chat.ChatCompletion =
  await client.chat.completions.create({
    model: "clarke-1.0",
    messages: [{ role: "user", content: "Hello, Radium!" }],
  });

console.log(response.choices[0].message.content);

curl https://api.radium.cloud/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{
    "model": "clarke-1.0",
    "messages": [{"role": "user", "content": "Hello, Radium!"}]
  }'

package main

import (
	"context"
	"fmt"

	openai "github.com/sashabaranov/go-openai"
)

func main() {
	cfg := openai.DefaultConfig("YOUR_API_KEY")
	cfg.BaseURL = "https://api.radium.cloud/v1"
	client := openai.NewClientWithConfig(cfg)

	resp, err := client.CreateChatCompletion(
		context.Background(),
		openai.ChatCompletionRequest{
			Model: "clarke-1.0",
			Messages: []openai.ChatCompletionMessage{
				{Role: openai.ChatMessageRoleUser, Content: "Hello, Radium!"},
			},
		},
	)
	if err != nil {
		panic(err)
	}

	fmt.Println(resp.Choices[0].Message.Content)
}

import com.openai.client.OpenAIClient;
import com.openai.client.okhttp.OpenAIOkHttpClient;
import com.openai.models.chat.completions.*;

OpenAIClient client = OpenAIOkHttpClient.builder()
    .apiKey("YOUR_API_KEY")
    .baseUrl("https://api.radium.cloud/v1")
    .build();

ChatCompletion completion = client.chat().completions().create(
    ChatCompletionCreateParams.builder()
        .model("clarke-1.0")
        .addUserMessage("Hello, Radium!")
        .build());

System.out.println(
    completion.choices().get(0).message().content().orElseThrow());

using OpenAI;
using OpenAI.Chat;

var client = new OpenAIClient(
    new ApiKeyCredential("YOUR_API_KEY"),
    new OpenAIClientOptions
    {
        Endpoint = new Uri("https://api.radium.cloud/v1"),
    });

var chatClient = client.GetChatClient("clarke-1.0");
var response = await chatClient.CompleteChatAsync(
    new UserChatMessage("Hello, Radium!"));

Console.WriteLine(response.Value.Content[0].Text);

import anthropic

client = anthropic.Anthropic(
    api_key="YOUR_API_KEY",
    base_url="https://api.radium.cloud",
)

message = client.messages.create(
    model="clarke-1.0",
    max_tokens=1024,
    messages=[
        {"role": "user", "content": "Hello, Radium!"}
    ],
)

print(message.content[0].text)

import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic({
  apiKey: "YOUR_API_KEY",
  baseURL: "https://api.radium.cloud",
});

const message: Anthropic.Message = await client.messages.create({
  model: "clarke-1.0",
  max_tokens: 1024,
  messages: [{ role: "user", content: "Hello, Radium!" }],
});

console.log(message.content[0].text);

curl https://api.radium.cloud/v1/messages \
  -H "Content-Type: application/json" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "clarke-1.0",
    "max_tokens": 1024,
    "messages": [{"role": "user", "content": "Hello, Radium!"}]
  }'

Ask for findings as JSON

A review bot is easier to trust when its output is machine-checkable. This example asks Clarke for findings against a JSON schema at temperature 0, so your CI can reject any response that does not match.

import json
from openai import OpenAI

client = OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.radium.cloud/v1",
)

findings_schema = {
    "name": "review_findings",
    "schema": {
        "type": "object",
        "properties": {
            "findings": {
                "type": "array",
                "items": {
                    "type": "object",
                    "properties": {
                        "file": {"type": "string"},
                        "line": {"type": "integer"},
                        "severity": {"type": "string", "enum": ["low", "medium", "high"]},
                        "message": {"type": "string"},
                    },
                    "required": ["file", "line", "severity", "message"],
                },
            }
        },
        "required": ["findings"],
    },
}

diff = open("change.diff").read()

response = client.chat.completions.create(
    model="clarke-1.0",
    temperature=0,
    messages=[
        {"role": "system", "content": "Review the diff for defects. Report only issues on changed lines."},
        {"role": "user", "content": diff},
    ],
    response_format={"type": "json_schema", "json_schema": findings_schema},
)

findings = json.loads(response.choices[0].message.content)["findings"]
for f in findings:
    print(f["severity"], f["file"], f["line"], f["message"])

Steps

1. Create an account at deploy.radium.cloud and generate a key at deploy.radium.cloud/keys. New accounts get $25 in credit with no card required.
2. Set RADIUM_API_KEY as a secret in the CI job or service that runs your reviewer, and keep it out of the repository and out of browser code.
3. Change the base URL and model name, then run the reviewer in shadow mode, with its comments going to a log or a private channel while your current provider keeps posting to pull requests.
4. Compare the two sets of comments on the same pull requests, then switch the reviewer over.

The Radium docs list Claude Code and PydanticAI among the tools that connect by changing the base URL, and switching back means pointing the base URL at your previous provider. Guides for the OpenAI and Anthropic SDKs are in the Radium docs.

Cost is easy to compute and quality is the part that takes work, so test before you move anything. Take the last 200 pull requests your team merged, run each one through your current model and through Clarke with the same prompt and the same context, and compare the output.

1. Measure the noise first. Use temperature 0 on both sides and run each side twice, so you know how much of any difference is run-to-run variation before you blame the model.
2. Score only what a machine can check. That means whether the output validates against the JSON schema, whether each finding points to a file and line that exist in the diff, and whether a generated test compiles and passes. Leave the quality of prose to people.
3. Read pairs, not scores. Sort the pull requests by how much the two outputs differ and read the most different pairs side by side. A reader decides which is better, and a sort order that is slightly wrong costs nothing.
4. Count what reviewers do with the findings. Findings that are accepted or fixed are the value, and findings that are dismissed are the false positives you pay for in attention.

Give the reviewer the code around the change as well as the change itself, because a model that sees only the diff flags problems that are handled a few lines away. Two passes also reduce false positives, with the first pass asking for every possible finding and the second asking which of them are genuine. G-Research describes this pattern for its own review tool, and the worked example above uses it.

Decide the threshold before you look at the results.

Radium fits when code review and routine code generation are a meaningful share of your AI spend and the tools you use accept a custom endpoint. There are cases where switching is the wrong move.

• Your coding tool does not let you set a base URL. Many editor assistants and hosted review products choose the model for you, and you can only change it if the tool accepts your own endpoint and key.
• Your volume is small. If the bill is a few hundred dollars a month, the evaluation will cost more than the switch saves.
• Your agent runs long autonomous loops that edit many files and run tests until the task passes. Radium has not published a code benchmark for this, so move one bounded step first, such as reviewing or writing tests, and measure it before you move the loop.
• Your workflow depends on the Responses API or on embeddings from the same provider. Radium does not offer either, so those calls stay where they are.

If none of these apply, run the comparison on your last 200 pull requests.

Can I use Radium for AI code review without changing my review tooling?

Yes, if your tooling lets you set a base URL, an API key and a model name. Radium serves OpenAI-compatible and Anthropic-compatible APIs, so you point the SDK at https://api.radium.cloud/v1 for OpenAI-style calls or https://api.radium.cloud for Anthropic-style calls, and your prompts, tool definitions and retry logic stay the same.

Which Radium model is best for code review and code generation?

Use Clarke (clarke-1.0) for review comments, unit tests, documentation and routine changes, Tycho (tycho-1.0) for pull request summaries, labels and commit messages, and Hal (hal-1.0) for security-sensitive review, large refactors and architecture planning.

How much does AI code review cost on Radium?

Clarke costs $1.50 per million input tokens and $7.00 per million output tokens. A two-pass review of a 400-line pull request, using about 37,200 input tokens and 1,800 output tokens, comes to roughly $0.068 before prompt caching, and a team of 50 engineers running 2,500 reviews a month would pay about $171.

Is Radium as good as Claude or GPT for coding?

Radium describes Clarke as comparable to Sonnet 5.5 and GPT-6 Sol and Hal as comparable to Opus 5.5 and GPT-6 Astra, and it has not published a code-specific benchmark. Replay your own pull requests through both models, compare the outputs side by side and decide on your own results.

Does Radium train models on our source code?

No. Radium does not use customer data to train models. Data is encrypted in transit, and enterprise customers can request retention and residency details during a security review.

What does not work when I switch a coding tool to Radium?

Model names from other providers return a model-not-found error until you change them to hal-1.0, clarke-1.0 or tycho-1.0. The Responses API and embeddings are not available, so tools that depend on them need chat completions or a separate embedding provider. When reasoning is enabled, read the last content block of the response, because a thinking block comes first.