What the Jev playground actually hits — and what changes when you get a key

Same model, three doors in

Nothing behind the playground is a mock or a demo build: anonymous visitors get 30 playground runs per day and signed-in visitors get 50, all running real upstream inference that no credit pays for. The playground quota is bounded by an IP-derived scope (hashed, so raw addresses never reach logs), and the JSON you see in the browser is the shape a keyed call returns.

The three differences in production

• Endpoint: /api/playground (browser session) vs /api/v1/systemone (Bearer key).
• Authentication: the playground bounds runs per visitor; the API authenticates every request against a workspace key.
• Quota: daily run caps vs plan rate limits (free 20 req/min, Starter 120/min, Pro 600/min, Team 2,000/min) plus credit spend.

Everything else is shared: same request schema (1–8 named questions, states up to 100,000 characters), same answer shapes with probability and confidence, same error codes — except the playground never returns 401 or 402, because nothing there costs credits.

Why the caps exist

The caps are a spend ceiling first and a product decision second: playground runs are real inference that no credit pays for, so the caps bound what free traffic can cost. The daily reset is per visitor, not per workspace, so a team cannot pool a bigger free quota — that is what the 5 signup credits and the API key are for.

If you see the daily-limit message, the path forward is the API key: the 5 free credits cover exactly the bridge from "I validated in the browser" to "I am sending a few hundred real calls". Nothing changes between those two worlds except the Authorization header and the URL.

A practical migration order

• Iterate criteria wording in the playground (free) until ten real cases return the decisions you would have made.
• Register, create a key, and run the identical request bodies under a Bearer header — now you observe real usage tokens and latency_ms for your workloads.
• Put the wrapper behind a feature flag at 5% of traffic; log request_id and your policy action per request.
• Scale up once thresholds rest on the observed distribution instead of guesses.

One last note on ownership: the workspace is the billing and access boundary. Keys belong to a workspace; credits belong to a workspace. On Team, each teammate makes keys that share the balance — so rotate and revoke keys at the workspace level.

Rate-limit numbers to expect on day one

The first API burst usually meets X-RateLimit at the free tier: 20 requests per minute with 1 concurrent call. The headers tell you exactly how long to wait (Retry-After and X-RateLimit-Reset in epoch seconds), and a simple client-side semaphore — one request in flight, refill tokens at plan rate — turns 429s from errors into scheduling. At Starter volume a naive serial loop is still comfortable; above a few requests per second you want the semaphore, and above Starter plans the concurrency allowances matter more than the per-minute numbers.

The response, end to end

{
  "request_id": "req_fe17d05411092c4f7f97947a",
  "model": "jev-1.14.0",
  "answers": {
    "refund_requested": { "type": "noul", "noul": 0.28 },
    "policy_supports":  { "type": "noul", "noul": 0.98 }
  },
  "usage": {
    "input_tokens": 401,
    "output_tokens": 39,
    "credits": 0
  },
  "latency_ms": 523
}

Note credits: 0 here — the playground's billing signature. Under a Bearer key the same request shows credits: 1 (401 input tokens ceil to 1 credit) and a credits_remaining balance. Everything else is identical, which is what makes the playground a trustworthy rehearsal stage.