typesafe.pro

How we reviewed this: we ran its own CI — 185 tests against real PostgreSQL and Redis, plus ruff — then started the proxy locally, pointed it at an upstream we controlled by changing one line, and watched what crossed the boundary. We made no Jev calls, and we sent nothing to the live service.

What it is

api.typesafe.pro accepts the TypeSafe request shape and answers it. No account, no key:

curl https://api.typesafe.pro/v1/systemone --request POST \
  --header 'Content-Type: application/json' \
  --data '{"model":"jev-latest","state":"The light is on.",
           "questions":{"is_on":{"type":"noul","instructions":"Is the light on?"}}}'

It is not a reimplementation and it is not an open model. It is a proxy, and this repository is its whole server.

What we watched cross the boundary

We ran the proxy with our own master key and sent one request through it carrying a bearer token of our own:

what the upstream received:
  authorization: Bearer apikey_MASTERKEY_CANARY
  body         : {"model":"jev-latest","state":{"text":"STATE_CANARY"},
                  "questions":{"is_on":{"type":"noul","instructions":"INSTRUCTION_CANARY"}}}

canary	reached the upstream
the operator’s master key	yes — it is the Authorization
our own bearer token	no
the request state	yes, verbatim
the question instructions	yes, verbatim

So the shape of the arrangement is: your state goes to TypeSafe, under somebody else’s account, paid for by them. A token of your own, if you are issued one, changes your rate limits rather than whose key is spent — and the README says as much: “Missing, malformed, duplicate, or unknown tokens receive anonymous access.”

That is a generous thing for the operator to run. It is also a third party between you and TypeSafe, and it is the fact to weigh before pointing anything at it.

The privacy section is true to the code

This is the part we can usefully check for you, and it is unusual. Every sentence in the README’s Privacy section matched what we found in the source:

the README says	what the code does
retains activity and error events for seven days	cleanup() deletes proxy_error_events older than retention_seconds
including real client IP addresses	0002_observability.py adds a client_ip inet column
client token identifiers are hashed	lookup_token(token_hash); no raw token column
error records omit request bodies	we grepped: the request body is never stored or logged
and omit authorization values	sanitize() rewrites Bearer … before anything is written
keep a bounded, sanitized portion of an upstream error	ERROR_BODY_BYTES = 8192, truncated and redacted

The redaction is more careful than most. It replaces the master key in three encodings — raw, JSON-escaped and URL-escaped — because “raw, JSON-escaped and URL-escaped credentials can all be echoed by upstream”, and then walks backwards from the end of the truncated text in case the buffer cut off mid-credential. Their own test suite has a case named test_body_rejection_never_reserves_master, which is the right thing to be worried about.

We found no path that stores a request body. On an error it keeps the upstream’s response, not yours.

The caveat that cannot be tested

We verified the code in this repository. We did not verify the code running at api.typesafe.pro, and no amount of reading can do that — AGPL-3.0 obliges a network operator to offer the source, but it does not prove the deployment matches it.

So: the published server is honest about what it keeps. Whether the live one is that server is a matter of trust, exactly as it would be with any hosted endpoint. Send it the same things you would send any third party you do not control.

Engineering

185 tests pass against PostgreSQL 15.18 and Redis 7.4.2, ruff check and ruff format --check are clean across 26 files. Our first run reported 82 errors, all of them ours — the fixtures say Install PostgreSQL or set TEST_DATABASE_URL to a dedicated test database, and once we ran the services the CI declares, everything passed.

The service refuses to start on a missing or weak setting rather than defaulting: Missing required settings: TOKEN_HASH_SECRET, and a TOKEN_HASH_SECRET under 32 characters is rejected. Deployment is checked in CI too — shellcheck on the deploy scripts, docker compose config, an image build and an nginx configuration check.

AGPL-3.0, fifty-one stars, created three days before we tested it.

Verdict

As software, this is the most carefully built proxy in this directory, and the privacy statement is one of the few we have been able to check line by line against the code.

As a service, understand what you are using: a free, anonymous front door to TypeSafe, paid for by its operator, which sees your states in the clear on the way past. For trying the request shape, reading the error semantics, or a demo, that is a fine trade and cheaper than an account. For anything you would not paste into a stranger’s server, get a key from TypeSafe and call them directly.

And if you like the design, the more interesting use is the one the licence enables: run it yourself. Everything we exercised above, we ran on our own machine.

For a local gateway that records your calls instead of proxying them anonymously, see Jeview; for what a routing proxy that mishandles keys looks like, solar-mini4-jev.

See how it compares with other tools in Best Jev tools, tested hands-on.

Review updated Sep 22, 2026. Numbers quoted from the project are its author's own; we don't publish our own measurements of Jev.