Local servers
Point jev.api_url at a Jev-compatible server on your network. No API key, no per-row billing, rows stay inside.
jev.api_url can point at any server that speaks the same POST /v1/systemone contract as TypeSafe. Rows then never leave your network and there is no per-row billing. Two such servers are stuntd (Laya behind the Jev API; it also records answers and trains a head per question, so a table's decisions can move local over time) and laya-server.
-- stuntd's default address
SET jev.api_url = 'http://127.0.0.1:8787/v1/systemone';
-- persist it for one database
ALTER DATABASE app SET jev.api_url = 'http://127.0.0.1:8787/v1/systemone';Everything else stays the same: batching, read-ahead, the session cache, and the spend guards work exactly as against TypeSafe. Plain http:// and https:// both work.
Keyless local servers need pgjev 0.2.1 or later. An existing install upgrades in place:
ALTER EXTENSION jev UPDATE;
SELECT jev_version();API key
A key is only required when jev.api_url is a *.typesafe.ai host. Against any other host:
- With no key set, requests go out without an
Authorizationheader. - With a key set, it is still sent as
Bearer <key>. That includesTYPESAFE_API_KEYfrom the server environment, so a TypeSafe key in the server's env also reaches the local server. - An endpoint that wants auth and does not get it surfaces as
jev: TypeSafe API error 401 ....
Reachability
The request is made by the PostgreSQL server process, not by your psql client. The URL has to resolve from the database host. If Postgres runs in Docker, 127.0.0.1 is the container itself: use host.docker.internal (on Linux add --add-host=host.docker.internal:host-gateway to docker run) or put both containers on one Docker network.
Cost figures
The token counts and estimated_cost_usd in jev_stats() and the per-batch NOTICE always use TypeSafe's list price, whatever the server. Against a local server, read them as a size measure, not a bill.