
Customer Support Chat
Run customer support chat on Clarke at $1.50 / $7.00 per 1M tokens. OpenAI and Anthropic compatible, so you change the base URL, key and model.
What drives the cost
Support chat is an input-heavy workload. Every turn of a conversation resends the system prompt, the policy or help centre context and the conversation so far, so the bill grows with the length of your instructions and the number of turns long before it grows with the length of the answers.
The cost of one conversation is the input tokens multiplied by the input price, plus the output tokens multiplied by the output price, divided by one million. On Clarke that is $1.50 per million input tokens and $7.00 per million output tokens.
A worked example to replace with your own numbers
| Assumption | Value |
|---|---|
| Turns per conversation | 6 |
| System prompt and policy context, resent every turn | 2,500 tokens |
| Customer message | 60 tokens |
| Reply | 300 tokens |
| Input tokens per conversation | 20,760 |
| Output tokens per conversation | 1,800 |
| Cost per conversation on Clarke | $0.044 |
| Cost per 100,000 conversations | About $4,370 before prompt caching |
In this example input is more than 90 percent of the tokens and about 70 percent of the cost, which is why a tighter system prompt and prompt caching do more for the bill than shorter replies. Radium prices prompt caching separately, and repeated prompts can be up to 90 percent cheaper with it.
Shorter instructions are the cheapest optimization available.
Which model to use
Clarke is the default for support chat. It is comparable to Claude Sonnet 5.5 and GPT-6 Sol, and it handles what most support conversations need, which is reading retrieved policy, following instructions about tone and escalation, calling tools to look up an order or an account and writing a reply the customer can act on.
Tycho belongs in front of Clarke once volume is high. It is the right model for classifying intent, routing a conversation to the right queue, detecting language and pulling an order number or email address out of a message, and at $0.50 per million input tokens it costs a third of Clarke on input.
Hal is for the small share of conversations that carry real consequences, such as policy exceptions, refunds above a threshold, multi-step troubleshooting and summarizing a long case history for the human agent who takes over. Sending only those to Hal keeps the average cost per conversation close to Clarke's.
| Step in the conversation | Model | Model ID |
|---|---|---|
| Intent classification and routing | Tycho | tycho-1.0 |
| Drafting replies from retrieved policy | Clarke | clarke-1.0 |
| Escalations, exceptions and case summaries for human agents | Hal | hal-1.0 |
One conversation can use all three.
What this workload needs from the API
A support bot depends on a short list of API capabilities, and each one should be confirmed against your own client before production traffic moves.
| Capability | Why support chat needs it | On Radium |
|---|---|---|
| Streaming | Customers expect the reply to start appearing straight away | Documented, including streaming responses with tools |
| Tool calling | Looking up orders, accounts and tickets in the middle of a conversation | Documented on the Anthropic-compatible Messages API |
| Structured output | Returning intent labels, escalation flags and ticket fields as JSON | Supported for JSON, classifications and summaries |
| Context window | Holding the policy context and the conversation history | Hal 250,000 tokens, Clarke 1,000,000, Tycho 125,000 |
| Prompt caching | Reusing the same system prompt on every turn | Available and priced separately |
Radium does not execute tools. Your application runs them and returns the results, the same way it does with OpenAI or Anthropic today.
Run a smoke test before the cutover.
How to switch
Radium serves OpenAI-compatible and Anthropic-compatible APIs, so an existing support bot 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 on the server.
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!"}]
}'To stream replies, set stream to true in the OpenAI SDKs or use the streaming helper in the Anthropic SDKs. Both work the way they do against the original providers.
Steps
- Create an account at deploy.radium.cloud and generate a key at deploy.radium.cloud/keys. Signup happens in a browser and needs a person to complete it, and new accounts get $25 in credit with no card required.
- Set RADIUM_API_KEY in the environment that runs your bot, and keep the key on the server, never in browser code.
- Change the base URL and model name, then send a controlled share of conversations to Radium while your current provider handles the rest.
- Compare resolution rate, escalation rate, customer satisfaction and cost per conversation, then move the rest.
Switching back means pointing the base URL at your previous provider. Guides for the OpenAI and Anthropic SDKs are in the Radium docs.
When Radium is the wrong choice
Radium fits when support chat is a meaningful share of your AI spend and the bot runs on a frontier API through a standard SDK. There are cases where switching is the wrong move.
- Your support volume is small. If the bill is a few hundred dollars a month, the evaluation will cost more than the switch saves.
- Your bot is built on one provider's platform features, such as hosted assistant threads, built-in file search or voice, which do not move with a base URL change.
- The model is your product. If your edge is a model you train yourself and you have ML engineers who want to run the infrastructure, running open weights directly will suit you better.
- Your bot takes autonomous actions on customer accounts in long multi-step loops. Move one bounded step first, such as drafting or routing, measure it and then move the next.
If none of these apply, the comparison is worth running.
Frequently asked questions
Can I move a customer support chatbot off OpenAI or Claude without rewriting it?
Yes. Radium serves OpenAI-compatible and Anthropic-compatible APIs, so you change the base URL to https://api.radium.cloud/v1, the API key and the model name, and your SDK, prompts and tool definitions stay the same.
Which Radium model should I use for customer support chat?
Use Clarke (clarke-1.0) to draft replies, Tycho (tycho-1.0) to classify intent and route conversations, and Hal (hal-1.0) for escalations, policy exceptions and case summaries for human agents.
How much does customer support chat cost on Radium?
Clarke costs $1.50 per million input tokens and $7.00 per million output tokens. A six-turn conversation with a 2,500-token system prompt uses about 20,760 input tokens and 1,800 output tokens, which comes to roughly $0.044 before prompt caching.
Will customers notice a difference in answer quality?
Test it on your own conversations. Send a controlled share of traffic to Radium and compare resolution rate, escalation rate and customer satisfaction against your current provider before you move the rest.
Does Radium train models on our customer conversations?
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.
Does Radium support streaming and tool calling for support bots?
Yes. Streaming and tool calling are documented, including streaming responses with tools on the Anthropic-compatible Messages API. Your application runs the tools and returns the results, and the docs recommend a smoke test against your own client before production.
Can I switch back if it does not work out?
Yes. Point the base URL, key and model name back at your previous provider. Nothing else in the integration changes.