Tīrtha is an OpenAI-compatible verified inference gateway. It is one thing, not a model marketplace: it routes each request by how hard it is, checks its own answers before returning them, and reuses work it has already solved. Below is what it exposes, what it accepts, what it retains, and, plainly, what we do not yet claim.
Capability honesty is the point. If a row says yes, it is dogfooded end to end through a real SDK. If it is not ready, it says so.
Capability
Support
Notes
Chat completions
Yes
Primary entry: POST /v1/chat/completions
Anthropic Messages
Yes
/v1/messages, system + multi-turn native
OpenAI Responses
Yes
/v1/responses dialect adapter
Streaming (all dialects)
Yes
SSE; final chunk carries usage with stream_options.include_usage
Tool / function calling
Yes
OpenAI wire format across all dialects; gated by an internal check before it is served
JSON / structured output
Yes
response_format:{type:"json_object"} passed through
Grounding check
Yes
Distinctive: POST /v1/verify returns allow / refuse
Vision / multimodal
No
Text in, text out
Embeddings / audio / images
No
Not offered
The product model
One dial. Lower cost by default, frontier when it must.
Tīrtha serves a fast, lower-cost tier when a check confirms the answer, and escalates to a frontier model only when a check actually disagrees. You do not pick a model. You pick how careful it should be, per request or per key.
How careful
Set body.tirtha.mode: auto (default, it decides) · max (best every time) · value (lean toward lower cost) · low (lowest cost). Request overrides key, key overrides account default.
What it does not claim
Not raw model ownership. Not "always frontier." Not "hallucination-free." The check is a consistency test against a source, not proof of truth about the world.
Config surface
Every knob, and the silent drops.
Buyers hate silently ignored params. Here is exactly what is honored and what is dropped.
Parameter
Honored
Notes
messages
Yes
Full history + system prompt passed through
tools · tool_choice
Yes
Triggers the tool-calling cascade
stream · stream_options
Yes
SSE; only include_usage honored under stream_options
response_format
Yes
JSON object mode
max_tokens
Yes
Capped to the serving tier's limit
temperature
Ignored
Fixed at 0. Determinism is a prerequisite for reusing solved work
model
Ignored
The gateway selects the tier; the model ID is tirtha/verified
top_p
Ignored
Declared for spec compliance; moot at temperature 0
stop
Soon
Declared, not yet wired
Tīrtha-specific extensions live under body.tirtha.*: mode (the care dial), tests (checks that must pass before an answer is trusted), and domain / subdomain (scope tags for reuse). See the config reference in the docs for the full list and defaults.
The verify endpoint
Ask if an answer is actually backed by its source.
Not part of the OpenAI standard, so it will not auto-discover. Point at it directly. It returns a verdict, not a rewrite.
# POST /v1/verify
{
"source": "the grounding text or trusted source",
"claim": "the assertion to check",
"context": "optional grounding context"
}
# -> 200 OK
{
"decision": "allow" | "refuse",
"confidence": 0.0 - 1.0,
"reasoning": "brief explanation",
"usage": { "tokens_in": n, "tokens_out": n }
}
Public, not cached, typically one to two seconds. It is a trusted-source consistency gate: the source says who is asserting, and verify checks whether the claim holds against it. Try it with no key at tirtha.ai/verify.
What it remembers
It only re-serves answers that passed a check.
Tīrtha can return a previously solved problem instead of paying to solve it again. The admission rule is strict, and it is a security boundary, not just a speed trick. This is the part most gateways get wrong.
The admission rule
Checked-only. An answer is remembered only after it passes a check. An unchecked answer is never stored and never re-served.
Deterministic by design. Same inputs, same answer (temperature 0). That is what makes a remembered answer safe to reuse instead of a stale guess.
Content-addressed. Entries are keyed by a server-derived hash of the request, so a crafted request cannot reach across accounts to pull an answer that is not yours.
Tenant isolation
Scoped to you. What you solve is scoped to your account. Another tenant's request cannot see it.
Provable air-gap. A Black Box tenant runs fully isolated: it never reads the shared pool, and an audit trail proves from data, not from our word, that its traffic never touched it.
Yours to inspect. You can ask what has been remembered for your account. Nothing you send is used to train a model.
Honest note: today the everyday hit-rate is near zero. The mechanism is proven and the isolation is real, but real traffic rarely repeats exactly, so most requests are solved fresh. We would rather tell you that than imply a reuse discount we are not yet delivering.
Limits & reliability
What binds, and what we do not guarantee.
Enforced today
Daily spend cap per key (default $120). Over it, requests degrade to the lower-cost tier and the response says spend_capped:true. Never a silent switch.
Rate + monthly quota per key. Returns HTTP 429 on exceed with Retry-After.
Concurrency gate (8 in-flight). Over it, HTTP 429 server_busy.
Timeouts: lower-cost tier 30s, frontier 120s. Context 200K, output up to the tier cap.
Not yet
No published SLA or uptime target. We alert on failures internally. Check the API directly: GET /healthz.
No public status page. Incidents go out by email.
No rate-limit headers yet. Read live state at /v1/keys/limits.
Cascade plus verify adds tail latency. If you need a hard p95, ask us.
Data & security
Plainly. What we hold, and what we haven't earned yet.
True today
No training on your data. Only providers whose terms meet that bar serve your traffic.
No prompt or response text in logs. We keep token counts, timing, and cost, never the content.
WAF in front of everything. Unauthenticated API paths are challenged.
Cache keyed by server-derived content hash. A crafted request cannot pull someone else's answer.
Structural tenant isolation. Private and Black Box scopes are database-enforced; Black Box is audit-provable.
Keys are stored hashed, shown once. Device grant (RFC 8628) for per-device auth.
Not attested
No SOC 2, HIPAA BAA, or GDPR DPA. We honor data export and deletion requests, but nothing is third-party attested. For regulated use, ask about the Black Box tier (dedicated stack + audit trail).
PHI redaction is not shipped. The default is conservative: treat all data as sensitive.
Scoped keys, auto-rotation, per-request cache bypass, and MFA are planned, not live.
We publish results, gaps, and how to reproduce. We hold the engineering recipe. A score without an n, a date, and a method is not a number.
Tool calling: about 94% on BFCL v4, single-tool 0 wrong-served on the reliability trap set. Measured on our harness, not the official Berkeley checker, pre-beta, roughly plus or minus 3 to 4 points per seed. The world-reproduces-it official run is still owed, and we will say so until it lands.
Long context: single-prompt retrieval verified to 208K tokens (6 of 6), above which the gateway returns an error rather than a wrong answer.
Cost: the system serves the lower-cost tier and escalates rarely, so the effective cost runs well under a frontier-only path on our workloads. The specific multiple depends on the config and the mix, and the pricing page carries the current figure. The efficiency comes from routing plus checking, not from re-serving remembered answers (that reuse is a proven mechanism whose organic hit-rate is near zero today).
Known gaps: parallel multi-call tool turns are the hardest category; long-horizon and adversarial-grounding failures are real; the lower-cost tier is not yet provider-diverse. We would rather you know these than discover them.
Reproduce or break us: hit /v1/verify yourself, or report a failure at tirtha.ai/report. We fix and send a receipt.
Get started
Point your client, paste your key.
It is OpenAI-compatible. Change the base URL and the key. Nothing else.
# any OpenAI SDK
base_url = "https://api.tirtha.ai/v1"
api_key = "sk-tirtha-…"
model = "tirtha/verified"