req_llm and Jev in Elixir

Jev in Elixir mostly means one of two routes: req_llm, an Elixir library that puts many model providers behind one Req-based interface, or a dedicated community client. Either way you're calling Jev, the decision model from TypeSafe AI, which answers closed questions with a probability per choice instead of writing prose. Elixir developers showed up early, and the reason is less fandom than fit.

The req_llm provider route

req_llm is a general-purpose library for LLM calls built on Req, the popular Elixir HTTP client. Its own public repository and issue tracker show work on Jev support framed as "a non-chat structured decision API," which is the right framing: Jev doesn't chat, so a provider for it has to expose verdicts rather than pretend to be another text model. Check the repo for the current state; provider support in a young ecosystem moves weekly, and we won't reproduce function names that may be renamed by Friday.

The appeal of this route is consolidation. If your app already calls a frontier model through req_llm for generation, adding the decision model through the same library keeps one config surface and one error-handling style. That split is the healthy one anyway: frontier model for prose, decision model for the closed fields.

The dedicated clients

Our directory catalogs two Elixir clients. The jev Elixir/OTP client is described as "designed around GenServer replies and pattern matching." The jev_elixir client, shared on Reddit, supports TypeSafe and OpenRouter with yes/no decisions, choices, scores, and multiple questions per request, as reported by its author, who lists spam detection, support routing, moderation, and transaction review as targets. A dedicated client trades req_llm's breadth for a closer fit to Jev's shapes.

Why the BEAM fits decision workloads

Verdict pipelines are many small, independent calls: several questions per item, many items at once, each one cheap. The BEAM was built for exactly that texture. Lightweight processes make fan-out natural, supervisors restart the call that timed out without taking the pipeline down, and pattern matching on a returned choice reads like the routing table it is.

The honest limits: concurrency on your side doesn't raise throughput on theirs. Spawning ten thousand processes just means ten thousand processes waiting politely on rate limits, so bound your pools. And like every sibling client, including the TypeScript jev-harness, these are community projects: pin versions and read diffs.

Where the API itself is concerned (auth, limits, request shape), the API overview maps what the ecosystem documents, and docs.typesafe.ai is the ruling source. New to the model entirely? What Jev is comes first.

Frequently asked questions

Is req_llm an official Jev SDK?

No. It is a community Elixir library for many providers; TypeSafe's documented official SDKs are Python and JavaScript.

Should I use req_llm or a dedicated Elixir client?

Use req_llm if you already route other models through it and want one interface; use a dedicated client like those in our directory if you want an API shaped around Jev specifically.

Does the BEAM make Jev faster?

It makes your side of the pipeline more concurrent and more fault-tolerant; per-verdict latency and account limits are set by the service.

Can I call Jev through OpenRouter from Elixir?

The jev_elixir client reports OpenRouter support, per its author; confirm current routing options in the official docs before relying on them.