include_scores
The switch that controls whether the probe runs, what it changes in the response, and what it costs.
include_scores decides whether the hallucination probe runs for a request.
It is a boolean, it defaults to true, and it is the only field you need
to know about to control probing.
{
"model": "google/gemma-4-31B-it",
"messages": [{"role": "user", "content": "Hello"}],
"include_scores": false
}What it changes
true (default) | false | |
|---|---|---|
scores in the response | present | null |
tokens in the response | present | null |
scores on stream chunks | present | absent |
| Probe surcharge | $1.00 / 1M output tokens | not charged |
| Latency | probe pass included | no probe pass |
Everything else — the completion text, usage, finish_reason — is identical.
Turning scoring off does not change what the model writes.
Sending it
curl https://api.telluvian.ai/v1/chat/completions \
-H "Authorization: Bearer $TELLUVIAN_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "google/gemma-4-31B-it",
"messages": [{"role": "user", "content": "Hello"}],
"include_scores": false
}'A silently dropped field means you are still paying
If include_scores does not reach the API, the request is scored and billed
as scored. In Python, passing it as a plain keyword argument is an error
rather than a silent drop — but a framework that filters unknown fields can
drop it quietly. If you are opting out to save money, check that scores in
the response really is null.
When to turn it off
Scoring is on by default because it is the reason to use this API. Turn it off when a call genuinely does not need verification:
- Cheap intermediate steps in a chain — routing, classification, reformatting — where nothing factual is being asserted.
- Latency-critical paths where you will not act on the score anyway.
- Re-running a prompt you have already verified, e.g. regenerating output from a template with the same facts.
Keep it on for anything a user reads as a factual claim.
Per-request, not per-key
There is no account-level setting. Each request decides for itself, so a single API key can serve both scored and unscored traffic — one client can verify user-facing answers while another skips the probe for internal bookkeeping.
Verifying what you got
The honest check is the response itself, not the request you think you sent:
response = client.chat.completions.create(
model="google/gemma-4-31B-it",
messages=[{"role": "user", "content": "Hello"}],
extra_body={"include_scores": False},
)
assert response.scores is None, "still being scored — and still being charged"Your usage records also carry the per-request cost, so a scored request is
visible in the dashboard as a higher cost_micros than an
unscored one with the same token counts.