Jev for ESP32: Typed AI Decisions for Microcontroller Devices
Jev fits ESP32 products because it returns a typed choice from a fixed list instead of free text, which matches firmware that accepts only bounded commands.
Author
Avik ArefinPublished
October 04, 2026
Jev for ESP32: Typed AI Decisions for Microcontroller Devices
Jev suits ESP32 devices because it answers with a typed choice from a fixed list, not free text. ESP32 firmware that accepts only a short list of commands can execute that choice directly, with no text parsing in between. Jev does not run on the ESP32; it runs on a gateway or server that the device talks to.
Jev: what TypeSafe's decision model does
Jev is an AI model from TypeSafe AI that picks among options instead of writing text. TypeSafe released it on September 15, 2026, and calls it a "System One" model, meaning a model for fast decisions rather than reasoning. You send it state, such as a user's request in plain words, plus typed questions. It answers each question in one of three forms:
- Choice: one option from a named list of up to 255, with a probability for each.
- Score: a rating on ordered levels, such as low, medium, high.
- Noul: the probability that a yes/no statement is true.
TypeSafe lists latency of 70–500 ms, $0.042 per million input tokens, and free output tokens. State plus the longest question must fit in 32,000 tokens. TypeSafe also reports Jev as 20–200 times faster and 40–400 times cheaper than large language models (LLMs); those are the vendor's own benchmarks.
Jev cannot write a reply, plan steps, or explain itself. TypeSafe positions it inside deterministic software, not as a standalone agent.
block-beta
columns 3
U["User: turn the fan down"] G["Gateway: Jev picks a command"] space
space P["Gateway: safety policy"] E["ESP32-S3: firmware checks pin policy"]
space space H["Fan driver"]
U --> G
G -- "Choice + probability" --> P
P -- "pwm set fan 30" --> E
E --> H
ESP32 command firmware: why typed output fits
An ESP32 that takes commands from AI needs those commands in a form it can check. The open-source jev-esp32s3-gateway project shows the pattern. Its ESP-IDF firmware accepts only commands such as pwm set fan 73 or servo set servo 90, on named targets with bounded values. PWM duty must sit between 0 and 100%, and servo angles between 0 and 180 degrees.
A Jev Choice question maps onto that list directly: each option is one allowed command. The answer is always a member of the list, so the gateway never has to extract a command from a sentence. An LLM that writes text can return a command outside the list, which the gateway then has to detect and reject.
The probability with each choice gives the gateway a second check. It can execute high-confidence choices and ask the user to confirm the rest. One caution: the json-render documentation for Jev states that "confidence is not a calibrated quality threshold," while TypeSafe describes the probabilities as calibrated. Measure the threshold on your own requests before trusting it.
If your device already takes a fixed command list, Jev adds plain-language control without changing the firmware's command set.
ESP32 security: keep the key and the authority apart
The gateway project separates intelligence from authority. Jev runs on the gateway, and the TypeSafe API key "stays on the gateway and is never installed on the ESP32." A device that someone extracts from the field therefore leaks no AI credentials.
The firmware holds the authority. All pins start disabled, and it rejects boot-strapping pins, flash and PSRAM pins, and duplicate pin assignments. It has no command for raw GPIO numbers, memory access, a shell, or firmware writes, so "Jev never writes a pin directly." The project still states that "software is not a safety system": the hardware must fail safe with pull resistors and normally-off drivers.
Copy this split when you add AI control to an ESP32 product: the model chooses, and the firmware decides what is allowed.
ESP32-S3 resources: what Jev control costs the chip
Jev control costs the ESP32 little, because the model runs elsewhere. The gateway firmware targets the ESP32-S3-MINI-1 with 4 MB of flash and no PSRAM. Its application is 1,049,856 bytes, in two over-the-air update slots of 1.8125 MB, each about 45% free. New devices onboard over Bluetooth LE with an X25519 key exchange and proof of possession, then take commands over Wi-Fi or Bluetooth.
The limits sit in the network path. The device's REST interface is plain HTTP, and the project restricts it to a trusted local network. A production build needs TLS, replay protection, command expiry, and stronger device identity. Jev's json-render integration is also marked experimental, and its APIs "may change in any release."
Budget for the security work, not the chip: the smallest ESP32-S3 module has room for the firmware, but the shipping version needs the network hardening the project lists.
CortexTech's perspective
Over at CortexTech, we added plain-language control to an ESP32-S3 device that drives a fan and a relay, using the jev-esp32s3-gateway split. Our first gateway used a general LLM with a JSON output format. It worked on clean requests, but on vague ones it sometimes returned a value outside the firmware's bounds, such as a duty cycle above 100% and also it was slow and costly. The firmware rejected those commands safely, but the user saw a failure instead of an answer.
We first considered a fixed-phrase parser, since the command list was short. It handled exact phrases but failed on paraphrases such as "it's too loud in here." We replaced the LLM with a Jev Choice question whose options were the device's canonical commands, plus a "none of these" option. Jev could no longer return an out-of-bounds value, because every option was already valid.
Below a confidence threshold that we tuned on our own logged requests, the gateway asks the user to confirm instead of acting. The lesson we reuse is to put the list of allowed actions into the question itself, so the model can only pick something the firmware will accept.