The model stack

One key. Three modes. You change one string.

model: "frodo-frontier"    maximum intelligence
model: "frodo-raw"         no system prompt, no persona
model: "frodo-private"     no prompt logs, zero-retention routing

That is the whole product surface. Everything below is what each mode means.

A mode is a routing profile, not a model we trained. Which model answers a mode is decided in the gateway per request. You never send an upstream model name and we never return one — that is the point of naming the lanes instead of the models.

#FRONTIER LIVE

frodo-frontier — maximum intelligence. The top models from the major labs, routed behind your key. This is the lane the marketplace catalogue draws from, and it is the one that opens the moment the key does.

Nothing exotic here. It is the mode you use when you want the best answer and do not care how you got it.

#RAW DESIGNED

No system prompt. No persona. No house style bolted onto a model that never asked for one.

Opens at P1.

Every hosted API wraps your message before the model reads it. A vendor system prompt, a tone, a personality some product team picked. You did not write any of it, you cannot read it, you pay for its tokens, and then you argue with the results it produces.

RAW takes the wrapper off.


System prompt	none injected
Persona	none applied
Reply style	the model's own
Key, endpoint, quotas	unchanged

What RAW is not. It is not a jailbreak, and it is not a promise that a model will say anything you ask it to. A model's own training still applies — we are removing our layer, not theirs. Refusals that come from the weights are the weights.

The candidates for this lane are open-weight, refusal-removed builds — abliterated and uncensored checkpoints, benchmarked against each other before one is pinned. The shortlist is on the marketplace. Those performance claims are maintainer-reported rather than independently certified, which is exactly why we benchmark rather than pick.

FRODO Backrooms turns RAW into a product you can watch. Two RAW agents continue from one seed and publish a bounded, branchable transcript. The visual preview is live, but room access remains sealed.

#PRIVATE DESIGNED

No prompt logs. Zero-retention routing.

Opens at P2.

Bitcoin is public by default: every payment lands on a ledger anyone can read forever. Zcash exists because sometimes that is not what you wanted, and a shielded lane turned out to matter more as the ledger got more valuable.

Inference has the same shape, and almost nobody has priced it in yet. Your prompts are the most revealing thing you type all day — the contract you are negotiating, the bug in your production code, the thing you are actually working on — and by default they land in someone else's logs.

PRIVATE is the shielded lane.


Prompt logs	none kept
Upstream retention	zero-retention routes only
What is stored	a request count, per key
Key, endpoint, quotas	unchanged

Privacy is not inside the model. No checkpoint is private on its own. It comes from where the model runs: dedicated inference, no request logging, no third-party fallback, encrypted transport, no stored prompts. That is why this lane uses clean official weights rather than community rebuilds — a modified checkpoint adds a question to a lane whose whole job is having fewer of them.

#How private is private

"Private" is four different products wearing one word, and a claim that does not say which one it means is not a claim. Each rung below answers the only question that matters: what can the machine running the model still see?

	Rung	What changes
L0	ROUTED	The default today. We keep nothing but a count; the operator serving the request sees the prompt like any hosted API.	LIVE
L1	NO-LOG	Routing restricted to endpoints under a zero-retention agreement. Still visible in flight, retained by nobody.	DESIGNED
L2	DEDICATED	Our own GPUs. No third-party fallback, so there is no second operator to have a policy about.	DESIGNED
L3	ATTESTED	Hardware-isolated inference in a trusted enclave, with an attestation you can check yourself.	PLANNED

frodo-private opens at P2 on L1 and L2. L3 is direction, not a date.

Rungs are contractual until they are cryptographic. L1 and L2 are promises backed by who we buy capacity from and what our own machines do — auditable, but you are trusting an operator. Only L3 replaces that trust with a proof. We would rather write that distinction down than let "private" quietly imply the strongest rung.

#Proving it PLANNED

A privacy claim you cannot check is marketing. At L3 the gateway exposes an attestation for the enclave that served you, bound to a nonce so a stale report cannot be replayed at you:

NONCE=$(openssl rand -hex 16)
curl "https://thering.lol/api/frodo/v1/attestation?mode=frodo-private&nonce=$NONCE" \
  -H "Authorization: Bearer frodo_sk_…"

bash

{ "mode": "frodo-private", "rung": "L3", "verified": true, "nonce": "…", "measured_at": "…" }

jsonc

Until that route exists this page says PLANNED and the site says P2 — there is no partial version of a proof.

#What this does not cover

The honest edges, stated rather than discovered later:

Only the inference path. A mode governs the request that reaches a model. Anything you attach yourself — a tool call out to a third-party API, a retrieval step, a web fetch — runs under that service's policy, not ours.
Your own client. Editors keep local history. That is between you and your editor.
The count is real. Quotas are counted per key or they are not enforced at all, so the gateway stores a number and a timestamp per key. It is not a prompt, and it is the complete list.

	Content	Metadata
What it is	prompts, completions, tool payloads	request count, last-used timestamp
Stored	never	yes, per key
Used for training	never — not ours to give	n/a
Where	nowhere; streamed through (proxy.js)	the key record (keys.js)

There is no opt-in that turns content logging on. It is not a setting, because the feature does not exist to be switched.

#Variants DESIGNED

Three modes, but not everyone wants the biggest model in the lane. A suffix picks the trade-off without leaving the mode:

frodo-raw            the strongest RAW model
frodo-raw:fast       smaller, cheaper, quicker to first token
frodo-raw:code       tuned for code and agent loops

The same three exist on frodo-private. frodo-frontier takes :fast for the same reason.

Suffix	Picks	Use it when
(none)	the strongest model in that lane	you want the best answer
`:fast`	a smaller model, lower latency and cost	high-volume, short turns, agent scaffolding
`:code`	a coding-tuned model	editors, patches, tool loops

A suffix never changes the mode's promise. frodo-private:fast is still no-logs and zero-retention — the suffix picks a model inside the lane, not a weaker version of the lane. That is the whole reason to attach it to the mode rather than offer a fourth mode.

Which model each variant resolves to is a shortlist decision, published on the marketplace and pinned to an exact commit before it ships. Variants land at P1 for RAW and P2 for PRIVATE — the build.

#Using a mode

Same key, same base URL, same SDK. Change the model string:

curl https://thering.lol/api/frodo/v1/chat/completions \
  -H "Authorization: Bearer frodo_sk_…" \
  -H "content-type: application/json" \
  -d '{"model":"frodo-raw","messages":[{"role":"user","content":"say ok"}]}'

bash

A mode that has not opened yet is a 403, and it costs you no quota. GET /v1/models always lists exactly the modes that are live for you right now — read that rather than guessing.

#Next

Endpoint catalog — how the mode layer is wired
Routing — what a request passes through before any of this
Marketplace — the candidate models behind RAW and PRIVATE