Call and Document Summarization
Summarize calls, tickets and documents on Tycho at $0.50 / $2.25 per 1M tokens, with JSON output. Change the base URL, key and model to switch.
What drives the cost
Summarization reads far more than it writes. The model receives a whole call transcript, ticket thread or report and replies with a few sentences and a handful of fields, so input volume drives the bill. On Tycho an input token costs $0.50 per million and an output token costs $2.25 per million.
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 the wrap-up note for one support call, returned as JSON for the CRM.
| Assumption | Value |
|---|---|
| Call length | 10 minutes at about 150 words a minute, 1,500 words |
| Transcript with speaker labels | About 2,000 tokens |
| Instructions and JSON schema, sent on every call | 700 tokens |
| Input tokens per call | 2,700 |
| Output tokens per call, the summary and fields | 250 |
| Cost per call on Tycho | $0.0019 |
| Cost per 1,000 calls | About $1.91 |
A contact center with 200 agents who each take 40 calls a day over 22 working days summarizes 176,000 calls a month. That comes to about $337 a month on Tycho, $1,021 on Clarke and $1,674 on Hal.
The second is an executive summary of one long report.
| Assumption | Value |
|---|---|
| Report length | 60 pages of text at about 670 tokens a page |
| Report text | About 40,200 tokens |
| Instructions, sent on every call | 1,000 tokens |
| Input tokens per report | 41,200 |
| Output tokens per report, the summary | 1,500 |
| Cost per report on Clarke | $0.072 |
| Cost per report on Tycho and on Hal | $0.024 and $0.113 |
In the call example input is 92 percent of the tokens and 71 percent of the cost. In the report example it is 96 percent of the tokens and 85 percent of the cost. The transcript or the report changes on every call, so prompt caching only saves on the instructions, which are a small share here.
The biggest saving is in how the calls are made. A pipeline that asks for the summary, the reason for contact, the resolution, the next steps and a follow-up flag as five separate calls sends the transcript five times. In the call example that is 11,500 input tokens and about $0.0064 per call, 3.4 times the cost of asking for every field in one call with a JSON schema.
Measure your own transcripts before you plan around any of these numbers.
Which model to use
Tycho is the default for summarizing calls, tickets, chats and short documents. Radium built it for classification, extraction, summarization and routing at high volume, and positions it as comparable to Haiku 5.5 and GPT-6 Luna. It follows a JSON schema and costs the least per token of the three models, which matters when every call and every ticket goes through it. Radium has not published a summarization benchmark, so run the test in the section below before you move any traffic.
Clarke takes the summaries people make decisions on, such as board packs, contract summaries, incident reviews and anything a customer will read. It also has a context window of 1,000,000 tokens against Tycho's 125,000, so a long report, a full deal room or a quarter of meeting notes fits in one call. The report above costs about $0.072 on Clarke.
Hal is for synthesis across many sources, such as comparing several analyst reports, tracing a decision through months of tickets or writing a research brief with a recommendation. Most summarization pipelines never need it.
Routing by validation keeps the bill close to Tycho's price. If 10 percent of call summaries fail the checks in the test section and are sent again to Clarke, the average cost per call is about $0.0025 in the example above.
| Step | Model | Model ID |
|---|---|---|
| Call wrap-ups, ticket and chat summaries, meeting notes, short documents | Tycho | tycho-1.0 |
| Long documents, summaries people decide on, summaries that fail validation | Clarke | clarke-1.0 |
| Synthesis across many documents and research briefs | Hal | hal-1.0 |
Route by who reads the summary.
What this workload needs from the API
A summarization pipeline depends on a short list of API capabilities. Confirm each one against your own client and a sample of your own transcripts before production traffic moves.
| Capability | Why summarization needs it | On Radium |
|---|---|---|
| Structured output | Returning the summary, the reason for contact, the resolution and the next steps as fields your CRM can store | JSON mode and JSON schema on all three models, through response_format |
| Context window | Holding a long call, a long ticket thread or a full report in one call | Tycho 125,000 tokens, Hal 250,000, Clarke 1,000,000 |
| Streaming | Showing a live summary in the agent desktop while the call is still being wrapped up | Supported on all three models |
| Concurrency | Summarizing every call as it ends, or working through a backlog | No published rate limits. Send requests in parallel and retry 429 and 503 responses with backoff |
| Repeatable runs | Getting the same summary from the same transcript twice | temperature 0 with a fixed seed |
| Token counting | Estimating cost before a large backfill | POST /v1/messages/count_tokens on the Anthropic-compatible endpoint |
Four things do not carry over unchanged. Radium serves text models, so audio is transcribed by your current speech-to-text step and the transcript is sent to Radium. Radium does not offer a batch endpoint, so a backlog runs as ordinary requests sent in parallel. Tycho reads text only, so tickets with screenshots go to Clarke, which accepts image input. Radium does not offer embeddings, so a pipeline that also indexes summaries for search keeps its current embedding provider.
Compare all three models on the model overview. The switching guide walks through a four-step evaluation against Anthropic and OpenAI, and the migration guide lists what changes and what stays the same. Turning a summary into fields is close to Document Extraction and Classification, and summarizing a conversation for the next agent is part of Customer Support Chat. More workloads are in the use cases index.
Run your schema on 50 real transcripts before the cutover.
How to switch
Radium serves OpenAI-compatible and Anthropic-compatible APIs, so an existing summarization job keeps its SDK, its prompts, its schema 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.
from openai import OpenAI
client = OpenAI(
api_key="YOUR_API_KEY",
base_url="https://api.radium.cloud/v1",
)
response = client.chat.completions.create(
model="tycho-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: "tycho-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": "tycho-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: "tycho-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("tycho-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("tycho-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="tycho-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: "tycho-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": "tycho-1.0",
"max_tokens": 1024,
"messages": [{"role": "user", "content": "Hello, Radium!"}]
}'Ask for every field in one call
This example sends one transcript to Tycho and asks for the summary and the CRM fields together, against a JSON schema, at temperature 0 with a fixed seed. Your job can reject any response that does not parse and send that transcript to Clarke.
import json
from openai import OpenAI
client = OpenAI(
api_key="YOUR_API_KEY",
base_url="https://api.radium.cloud/v1",
)
schema = {
"name": "call_summary",
"schema": {
"type": "object",
"properties": {
"summary": {"type": "string"},
"reason_for_contact": {"type": "string"},
"resolution": {
"type": "string",
"enum": ["resolved", "escalated", "pending", "no_action"],
},
"next_steps": {"type": "array", "items": {"type": "string"}},
"follow_up_required": {"type": "boolean"},
},
"required": [
"summary",
"reason_for_contact",
"resolution",
"next_steps",
"follow_up_required",
],
},
}
transcript = open("call_transcript.txt").read()
response = client.chat.completions.create(
model="tycho-1.0",
temperature=0,
seed=7,
messages=[
{
"role": "system",
"content": "Summarize this support call in three sentences or fewer. "
"Use only facts stated in the transcript.",
},
{"role": "user", "content": transcript},
],
response_format={"type": "json_schema", "json_schema": schema},
)
result = json.loads(response.choices[0].message.content)
print(result["summary"])
print(result["resolution"], result["next_steps"])Steps
- 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.
- Set RADIUM_API_KEY as a secret in the service or job that writes your summaries, and keep it out of the repository and out of browser code.
- Change the base URL and model name, then run Radium in shadow mode, with its summaries going to a log while your current provider keeps writing to the CRM.
- Compare the two sets of summaries on the same calls, then switch the job over.
Switching back means pointing the base URL at your previous provider. Guides for the OpenAI and Anthropic SDKs are in the Radium docs.
How to test it on calls you have already summarized
Cost is easy to compute and faithfulness is the part that takes work, because a summary that reads well can still state something the customer never said. Take 200 calls or tickets that already have a summary your team accepted, run each one through your current model and through Tycho with the same prompt and schema, and compare the output.
- Measure the noise first. Use temperature 0 and a fixed seed 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.
- Check every fact a machine can find. Pull the numbers, dates, amounts, order IDs and names out of each summary and confirm that each one appears in the transcript. A value that is not in the transcript is an invented fact, whichever model wrote it.
- Check the fields against your records. Confirm that the output validates against the schema and that the resolution field agrees with the disposition code the agent chose.
- Read the pairs that differ most, without labels. Sort the calls by how much the two summaries differ and give the top of the list to the people who read summaries every day, with the model names hidden. They decide which one they would rather have in the CRM.
Decide the threshold before you look at the results.
When Radium is the wrong choice
Radium fits when summarization is a meaningful share of your AI spend and your pipeline lets you choose the model. There are cases where switching is the wrong move.
- Your summaries are built into your contact center or help desk platform. Many platforms choose the model for you, and you can only change it if the platform accepts your own endpoint and key.
- Your pipeline runs on a batch API and can wait a day. OpenAI's Batch API and Anthropic's Message Batches API charge half the standard price. Radium has no batch endpoint, so compare against what you pay on batch.
- You want audio in and a summary out from one provider. Radium serves text models, so transcription stays with your speech-to-text provider.
- Your volume is small. If the bill is a few hundred dollars a month, the evaluation will cost more than the switch saves.
- Your contracts require a certification Radium has not published. Call recordings and tickets often carry personal data. Radium lists GDPR compliance and handles SOC 2 Type II, ISO 27001 and HIPAA questions through its security package, so request it before you send regulated transcripts.
If none of these apply, run the comparison on 200 calls your team has already summarized.
Frequently asked questions
Can Radium summarize call transcripts and support tickets as JSON?
Yes. All three Radium models support JSON mode and JSON schema through the response_format parameter. Send the transcript or ticket thread and a schema, and the summary, reason for contact, resolution and next steps come back as fields your CRM can store. Ask for every field in one call, so the transcript is sent once.
Which Radium model is best for summarization?
Use Tycho (tycho-1.0) for call wrap-ups, ticket and chat summaries, meeting notes and short documents. Use Clarke (clarke-1.0) for long documents, summaries people make decisions on and summaries that fail validation. Use Hal (hal-1.0) for synthesis across many documents.
How much does AI call summarization cost on Radium?
Tycho costs $0.50 per million input tokens and $2.25 per million output tokens. Summarizing a 10-minute call, at about 2,700 input tokens and 250 output tokens, comes to roughly $0.0019 per call, or about $337 for 176,000 calls a month. These token counts are assumptions, so measure your own transcripts.
Can Radium transcribe call audio?
No. Radium serves text models, so audio goes through your current speech-to-text step and the transcript is sent to Radium for the summary.
Does Radium have a batch API for summarizing a backlog?
No. Radium does not offer a batch endpoint or a batch discount. It does not publish rate limits either, so a backlog of calls or tickets runs as ordinary requests sent in parallel, with retries and backoff on 429 and 503 responses.
Does Radium train models on our call transcripts?
No. Radium does not train on customer data, and prompts and completions are used only to service the request. Radium lists GDPR compliance, and SOC 2 Type II, ISO 27001 and HIPAA questions go through its security package.