How to Get a Jev API Key and Set Up Your Environment

Before you send a single judgment question, you need an API key and an environment that keeps it safe. The fastest path to a working Jev setup runs through OpenRouter, the model’s main demo channel: it exposes Jev through an OpenAI-compatible endpoint, so the key you get there works with the request shape you already know. This guide walks through getting the key, wiring it into your environment, setting up credits, and the security habits that prevent an expensive accident.

TL;DR: Sign up on OpenRouter, add credits, and create an API key. Store it in an environment variable (OPENROUTER_API_KEY), never in code. Jev is listed at roughly $0.0462 per 1M input tokens on third-party listings — confirm current pricing on the OpenRouter model page. For the official TypeSafe AI channel and its own endpoints, follow the official documentation at typesafe.ai.

Before you start: accounts, projects, and key scopes

The OpenRouter model for organizing access is straightforward but worth understanding before you click “Create Key.” OpenRouter ties keys to your account, and your account can belong to multiple organizations. If you are the only person involved, your personal account is fine. If a team will share the same credit pool, create an organization first — keys issued under an organization count against the organization’s balance, not your personal one.

A project in this context is your mental model, not a formal OpenRouter concept. The practical equivalent is one API key per logical application: one for your production scoring pipeline, one for your staging environment, one for local experiments. You will thank yourself later when you look at the usage breakdown and can see “ah, it was the nightly batch job that spiked, not the real-time path.”

OpenRouter keys currently do not have granular capability scopes the way some platforms do (read vs. write vs. admin). What you can configure is spend limits — treat those as your scope control: a key for read-only research queries gets a low cap, a production key gets headroom proportional to your expected traffic. Principle of least privilege applied to dollars.

For teams that need audit trails, formal access control, or SLA guarantees, the official TypeSafe AI channel offers enterprise terms and direct endpoints separate from OpenRouter. Weigh those against OpenRouter’s simpler onboarding in the API channels guide.

Step-by-step: Jev API key setup

1. Create your OpenRouter account

Go to OpenRouter and register. Email-and-password or OAuth (GitHub, Google) both work. Once you are logged in, verify your email if prompted — some credit top-up paths require a verified account.

2. Navigate to the Keys page

The dashboard URL pattern is openrouter.ai/settings/keys. Click Create Key. You will see two fields:

• Name — use a naming convention you will still understand in six months. Something like prod-scoring-01, staging-jev-01, or local-dev-blue beats “my key” by a wide margin. The name shows up in usage reports and is the first thing you read when you need to revoke something at 2 AM.
• Credit limit — set this now, not later. For a first test key, $5 is more than enough. For a production key, calculate your expected monthly volume and add 20% headroom (see the cost and latency guide for a worked example).

3. Save the key immediately

The key is shown exactly once. Some dashboards show a masked version afterwards for identification, but the actual sk-or-v1-... string is gone after you close that dialog. Copy it to your password manager or a secure note before doing anything else. If you lose it, create a new key and revoke the old one — there is no recovery flow.

4. Find the Jev model slug

On the OpenRouter models page, search for Jev. As of this writing the model identifier is typesafe/jev-1.13. That slug is what goes in your API request’s model field. Version numbers change with releases, so always confirm the exact slug rather than copying it from an old tutorial. The model page also shows the pricing breakdown for input tokens, output tokens, and context length limits.

Environment variables and security practices

The .env file pattern

Create a .env file at your project root:

# .env — never commit this file
OPENROUTER_API_KEY=sk-or-v1-your-key-here
OPENROUTER_BASE_URL=https://openrouter.ai/api/v1

Add .env to your .gitignore on day one — before you git add anything:

echo ".env" >> .gitignore
echo ".env.local" >> .gitignore

This matters more than most people think. A key committed to a public GitHub repo is typically scraped by bots within minutes. OpenRouter’s abuse detection may catch it first and lock your account, but do not count on it.

CI/CD secrets

In GitHub Actions, add your key as a repository secret (Settings → Secrets and variables → Actions → New repository secret), then reference it in your workflow:

env:
  OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}

The same pattern applies in GitLab CI (CI/CD variables), Vercel (Environment Variables), and most deployment platforms. The key never touches source control — it is injected at runtime.

For local automation tools like n8n, use the tool’s own credential store rather than pasting the key into a workflow node. The n8n workflow guide shows the exact steps for wiring it up.

Rotation schedule

Rotate keys every 90 days as a baseline, shorter if your team is large or the key has broad access. The rotation process is:

1. Create a new key with the same name pattern (e.g., prod-scoring-02).
2. Update the secret in your secrets manager / CI environment.
3. Deploy and verify the new key works.
4. Revoke the old key.

Do not revoke first — you will cause downtime. Create, verify, then revoke.

Compromise response

If a key leaks (shows up in a log, a screenshot, a PR diff, a Slack message), the playbook is:

1. Revoke immediately. Do not wait to investigate first. A minute of lost service is cheaper than an unknown credit drain.
2. Check usage. In the OpenRouter dashboard, look at usage by key for the last 24 hours. Any volume spike you did not cause is a signal that the key was picked up.
3. Rotate all related secrets. If the leaked key was in an .env file that also had other values, rotate those too.
4. Update your detection. Add a secret scanner (truffleHog, git-secrets, or GitHub’s built-in secret scanning) to prevent the same leak path next time.

Your first API call

curl

Confirm the exact model slug on the OpenRouter model page, then:

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "typesafe/jev-1.13",
    "messages": [{"role": "user", "content": "Judgment question: is the sky blue?"}]
  }'

A 200 response with a structured answer in the message content means the key, the credits, and the model slug are all correct.

Python requests

import os
import requests

api_key = os.environ["OPENROUTER_API_KEY"]  # raises KeyError if missing — intentional

response = requests.post(
    "https://openrouter.ai/api/v1/chat/completions",
    headers={
        "Authorization": f"Bearer {api_key}",
        "Content-Type": "application/json",
    },
    json={
        "model": "typesafe/jev-1.13",
        "messages": [{"role": "user", "content": "Judgment question: is the sky blue?"}],
    },
    timeout=30,
)
response.raise_for_status()
data = response.json()
print(data["choices"][0]["message"]["content"])

The parsed answer — example fixture, confirm exact field names in the official documentation:

{
  "answer": "yes",
  "confidence": 0.99,
  "rationale": "Visible-sky blue coloration is the expected answer to this common-knowledge question."
}

Common error reference

The troubleshooting guide has deeper walkthroughs for each of these, including common environment-specific causes.

Quotas, rate limits, and billing

Free tier and credits

OpenRouter does not offer a permanent free tier for most models. You start with a small credit grant when you register (amount varies; check the dashboard). After that, it is prepaid credits. For Jev specifically, the listed rate of about $0.0462 per 1M input tokens means:

• 1,000 short judgment calls (~100 tokens each) ≈ $0.005 — essentially free for testing
• 100,000 calls with 200-token prompts ≈ $0.92
• 1M calls per day at 150 tokens average ≈ $6.93/day

These are input-token estimates. Output tokens are typically much shorter for judgment-style responses, so the real cost is usually close to the input figure. Work through your own numbers in the cost and latency guide.

Rate limit headers

OpenRouter returns these headers on every response:

Log these in your batch jobs. If X-RateLimit-Remaining drops below 10, introduce a small sleep before the next batch. A simple token bucket implementation is about 15 lines of Python and prevents 90% of 429s in batch workloads.

Spend limit as a safety net

Set a per-key spend limit in the Keys settings. This is the single most effective control against runaway costs from a bug or a compromised key. A $20 limit on a test key means the worst-case outcome of any mistake is $20, not $2,000. Raise the limit only after you have validated your pipeline’s behavior in production.

FAQ

Can I use one OpenRouter key for both Jev and other models? Yes. OpenRouter keys are not model-specific — the same key can call any model available on the platform. The per-key spend limit applies across all models, so account for that in your budgeting if you mix models.

I set a spend limit but OpenRouter is still charging me. What happened? Spend limits are best-effort, not hard cutoffs. A burst of requests processed just before the limit takes effect can push you slightly over. Treat the limit as a warning signal, not a guaranteed hard cap.

What is the difference between OpenRouter rate limits and the model’s own throughput? OpenRouter enforces its own rate limits by tier. The underlying model may have separate capacity constraints. If you need guaranteed throughput with no rate-limit variability, the API channels guide covers the TypeSafe AI direct channel, which offers SLA-backed capacity tiers.

Security habits that matter

• One key per project. When usage spikes, you know which project to look at, and revoking is surgical.
• Set spend limits per key. A leaked key with no cap is an open tab.
• Rotate every 90 days. Calendar it now. It takes five minutes and prevents the slow-burn exposure where a key that “probably” wasn’t compromised quietly drains credits for months.
• Never commit .env files. Add them to .gitignore on day one.
• Revoke first, investigate second. When in doubt about a key’s exposure, revoke it immediately. Downtime from a missing key is minutes. Unauthorized usage of a live key is unbounded.
• Treat the key like a password, because it is one — with your credit card behind it.

Once the key verifies, continue to the first API call tutorial for the full request walkthrough, or the ticket triage case to see the key used in a real workflow.

When a key leaks: response order and rotation

If a key appears in a public place — a GitHub commit, a Slack message, a pastebin link — assume it has been scraped within minutes. Automated scanners run continuously against GitHub and common paste sites, looking for strings that match patterns like sk-or-v1- or Bearer . Some of these scanners belong to security researchers; many belong to credential-harvesting bots that will test the key against OpenRouter within seconds of finding it. The exposure window is not hours. It is minutes, often less.

The response order matters more than the thoroughness of the investigation. First, revoke the key immediately from the OpenRouter Keys dashboard — do not wait to confirm whether the key was actually used. The cost of a false alarm is creating a new key and updating one variable. Second, create a replacement key with a fresh name, the same or adjusted spend limit, and update every environment that held the old key. Third, check the usage logs on OpenRouter for any requests you did not make. Look at the timestamp window around when the exposure happened and compare model slugs and request volumes against your normal patterns. Only after the replacement is live and validated should you spend time on forensics.

Automated .gitignore checking helps but is not a substitute for not committing secrets. Tools like git-secrets or GitHub’s native secret scanning will flag a push before it lands, but they only help on the push that triggers them. Any key committed before you set up scanning may already be in your repository history. If you suspect historical exposure, use git log -S 'sk-or-v1-' --all --source to search the entire commit history — not just the working tree — and treat any positive hit as a confirmed leak regardless of whether the key still appears in the latest version.

Verifying a new key without burning through credits

The smallest valid Jev AI request is one message with a short prompt and max_tokens capped low. A prompt like "Classify: positive or negative? Text: great." with max_tokens: 5 will return a Jev AI judgment and consume roughly 20 input tokens and 3 to 5 output tokens — under $0.000001 at current listed rates. Use this pattern, not a real production prompt, to confirm the key works before wiring it into a pipeline. Running your full test suite against a new key before the key is validated wastes both time and credits if there is a configuration mistake.

Watch for two distinct failure modes when a key is “valid but not working.” A 429 Too Many Requests response means the key authenticated correctly but you have hit a rate or credit threshold — this is a billing issue, not a key issue. A 402 Payment Required means the account has no credits or the spend limit is set to zero. Both differ from 401 Unauthorized, which means the key itself is wrong or revoked. Each error points to a different fix, and conflating them wastes debugging time. Check the response body for the error.message field; OpenRouter usually includes a human-readable explanation alongside the status code.

Return the raw response body on the first test call, not just the parsed content field. The usage object in the response shows prompt_tokens and completion_tokens — confirm both are non-zero and plausible for your input length. A completion that returns null in the content field with a finish_reason of content_filter means the key works but the request hit a content policy, not a key problem. See the troubleshooting guide for a full breakdown of each finish reason and the diagnostic steps for each.

Managing keys across local, CI, and production environments

The three environments need different storage strategies because their threat models differ. Local development uses a .env file at the project root, loaded by dotenv or equivalent. This file must be in .gitignore and must never be committed. The discipline here is simple: add .env to .gitignore before you create the file. If you reverse the order even once, the file can slip into a commit while the gitignore entry is still pending. A .env.example file with placeholder values is safe to commit and useful for onboarding — it documents what variables are needed without revealing their values.

CI/CD environments (GitHub Actions, GitLab CI, CircleCI) have a dedicated secrets store — use it. In GitHub Actions, a secret named OPENROUTER_API_KEY becomes the environment variable ${{ secrets.OPENROUTER_API_KEY }} in your workflow YAML. The value is masked in logs so it will not appear even if a step prints all environment variables. Never set the key in a workflow env: block with a literal string value, and never pass it as a build argument in Docker builds — build arguments are visible in the image metadata and in docker history output. A leaked key via Docker history is particularly insidious because it persists in every layer that references it, even after you update the image.

Production environments vary by platform, but the principle is the same: use the platform’s native secret injection (AWS Secrets Manager, GCP Secret Manager, Heroku Config Vars, Render environment variables) rather than baking the key into an image or a configuration file. The NEXT_PUBLIC_ prefix in Next.js deserves a specific warning: any variable prefixed NEXT_PUBLIC_ is inlined into the client bundle and sent to every browser that loads your app. A Jev API key in a NEXT_PUBLIC_ variable is effectively public. Calls to the Jev API must go through a server-side route — a Next.js API route, an edge function, or a dedicated backend — never from the browser directly.

This guide applies to Jev 1.13.