O que o playground do Jev realmente atinge — e o que muda quando você tem uma chave

Mesmo modelo, três portas de entrada

Nada por trás do playground é um mock ou uma build de demonstração: visitantes anônimos têm 30 execuções de playground por dia e visitantes logados têm 50, tudo rodando inferência upstream real que nenhum crédito paga. A quota do playground é limitada por um escopo derivado do IP (com hash, então endereços brutos nunca chegam aos logs), e o JSON que você vê no navegador é a forma que uma chamada com chave retorna.

As três diferenças na produção

• Endpoint: /api/playground (sessão de navegador) vs /api/v1/systemone (chave Bearer).
• Autenticação: o playground limita execuções por visitante; a API autentica cada requisição contra uma chave de workspace.
• Quota: limites diários de execuções vs limites de taxa do plano (free 20 req/min, Starter 120/min, Pro 600/min, Team 2,000/min) mais gasto de créditos.

Todo o resto é compartilhado: mesmo schema de requisição (1–8 perguntas nomeadas, estados de até 100,000 caracteres), mesmas formas de resposta com probabilidade e confiança, mesmos códigos de erro — exceto que o playground nunca retorna 401 ou 402, porque ali nada custa créditos.

Por que os limites existem

Os limites são, primeiro, um teto de gasto e, segundo, uma decisão de produto: execuções do playground são inferência real que nenhum crédito paga, então os limites restringem o que o tráfego gratuito pode custar. O reset diário é por visitante, não por workspace, então uma equipe não pode acumular uma quota gratuita maior — para isso existem os 5 créditos de cadastro e a chave de API.

Se você vê a mensagem de limite diário, o caminho é a chave de API: os 5 créditos gratuitos cobrem exatamente a ponte de "validei no navegador" para "estou enviando algumas centenas de chamadas reais". Nada muda entre esses dois mundos além do cabeçalho Authorization e da URL.

Uma ordem de migração prática

• Itere o wording dos criteria no playground (de graça) até dez casos reais retornarem as decisões que você teria tomado.
• Registre-se, crie uma chave e rode os mesmos corpos de requisição sob um cabeçalho Bearer — agora você observa tokens de uso reais e latency_ms dos seus workloads.
• Coloque o wrapper atrás de uma feature flag a 5% do tráfego; registre request_id e a ação da sua política por requisição.
• Escale quando os thresholds descansarem na distribuição observada em vez de em chutes.

Uma última nota sobre donosidade: o workspace é a fronteira de cobrança e acesso. Chaves pertencem a um workspace; créditos pertencem a um workspace. No Team, cada integrante cria chaves que compartilham o saldo — então rotacione e revogue chaves no nível do workspace.

Números de limite de taxa a esperar no primeiro dia

O primeiro pico da API geralmente encontra o X-RateLimit no tier gratuito: 20 requisições por minuto com 1 chamada concorrente. Os cabeçalhos dizem exatamente por quanto tempo esperar (Retry-After e X-RateLimit-Reset em segundos epoch), e um simples semáforo no lado do cliente — uma requisição em voo, recarga de tokens na taxa do plano — transforma 429s de erros em agendamento. No volume do Starter, um loop serial ingênuo ainda é confortável; acima de algumas requisições por segundo, você quer o semáforo; e acima dos planos Starter, as permissões de concorrência importam mais que os números por minuto.

A resposta, de ponta a ponta

{
  "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
}

Repare nos credits: 0 aqui — a assinatura de cobrança do playground. Sob uma chave Bearer, a mesma requisição mostra credits: 1 (401 tokens de entrada arredondam para 1 crédito) e um saldo de credits_remaining. Todo o resto é idêntico, e é isso que torna o playground um palco de ensaio confiável.