The spec sheet, with the gaps left in.
Tīrtha is an OpenAI-compatible inference endpoint that checks its answers. 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.
Authorization: Bearer sk-tirtha-…
What actually works today.
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 |
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.
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/auto |
| 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.
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.
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.
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
- Shared by default. Checked answers go into one store that every account draws from. Private scopes are available by arrangement; no account runs in one today.
- 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. Available by arrangement; no account runs in one today.
- 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.
What binds, and what we do not guarantee.
Enforced today
- Daily spend cap per key. 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 (32 in-flight). Over it, HTTP 429 server_busy.
- Timeouts: lower-cost tier 30s, frontier 120s. Context 200K, output up to the tier cap.
- Latency (measured, prod): tool-calling p50 0.85s, p90 1.36s, on 800 fixed BFCL items replayed through the production path (2026-07-29). Our coding latency was last measured on a configuration we no longer serve, so we do not quote it until it is re-run. Verification runs your tests (sub-second); the tail is model generation, and hard multi-step work escalates.
- 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.
- No guaranteed latency SLA yet. Measured p50/p90 are published (left), but not contractually guaranteed.
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.
- Usage records hold no content. They keep token counts, timing and cost, never the text. Separately, checked answers are cached together with the prompt that produced them; send
tirtha.no_cacheto skip the cache. - 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.
- 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, and MFA are planned, not live.
Full posture and disclosure at tirtha.ai/security. Security contact: [email protected].
The numbers, with the n and the caveats.
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: 749 of 800 on a single fixed pass of BFCL v4 Python through the production tool path. An official Berkeley AST re-score of the same saved outputs gives 751 of 800. Single pass: no multi-seed and no bootstrap interval, so it is not a leaderboard submission. On the adversarial trap set the primary path served no wrong tool across four shapes parameterised 50 ways each; the failover path scores 30 of 40, and we publish that beside it because availability is not identical safety. Corrected August 6, 2026: this line previously said "about 94%" with "plus or minus 3 to 4 points per seed" and that the official run was still owed. The official re-score has landed, and the per-seed spread described a multi-seed design we do not run.
- Long context: raw single-prompt retrieval measured clean to 208K tokens (6 of 6, 2026-06-28), with a hard cap above it where the gateway returns an error rather than a wrong answer. That is a configured infrastructure limit and it is raiseable; it is not the model's window, and raw stuffing is not how Tirtha ingests long inputs.
- Cost: the system serves the lower-cost tier and escalates rarely. Our blended cost was $0.000149 per request on our own monitor and benchmark traffic (n=1,615 over 54.5 hours, 2026-08-02), not a customer workload. We quote no multiple against a frontier-only path, because we have not yet measured one on the same workload. 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.
Point your client, paste your key.
It is OpenAI-compatible. Change the base URL and the key. Nothing else.
Free beta. Server info reviewed 2026-08-06.