Sep 22, 2026 / Avik Arefin

How TypeSafe AI Jev Is a Great Choice for ESP32

An ESP32 cannot run a large language model, but it can call Jev and get a typed decision back. This article measures what that costs in heap, power, and latency, and when it beats a model running on the device.

How TypeSafe AI Jev Is a Great Choice for ESP32

Author

Avik Arefin

Published

September 22, 2026

How TypeSafe AI Jev Is a Great Choice for ESP32

Over at CortexTech, typically when we need decision making on an edge chip like ESP32, we opt for a large language model hosted online. However, even though LLMs do great at conversations, for the same reason they are terrible for the decision making software. Jev is TypeSafe AI's System One model, served over a hosted API, and it returns typed answers instead of text. You send a state and a set of questions and receive a value the ESP can branch on. This is a technical breakdown from CortexTech, the full stack AIoT MVP prototype studio.

What TypeSafe AI Jev is

Jev is the flagship model of TypeSafe AI, a San Francisco company founded in 2024. It released in limited early access on 15 September 2026 alongside a $40 million seed round led by DCVC, and TypeSafe describes it as the first System One model.

Jev does not generate text. It evaluates a state — a string, a JSON object, or an array of text — against typed questions, then returns structured values with probability estimates. Because the possible answers are defined before the call, the model cannot return a value outside the schema you supplied. That constraint is what removes the need for parsing raw text, from your firmware.

TypeSafe exposes three primitives, and the count is fixed by the product rather than by writing style:

  • Choice picks one option from a list and returns choice, probabilities, and confidence.
  • Score rates the state along ordered levels and returns score, legend, probabilities, and confidence.
  • Noul judges whether a statement is true and returns a probability between 0 and 1.

All three can be mixed in one request. Every question sees the same state and is evaluated independently and in parallel, so adding questions barely changes the response time.

What the ESP32 side looks like

ESP32 is Espressif's 2.4 GHz Wi-Fi and Bluetooth combo SoC. The chip carries an Xtensa LX6 core running to 240 MHz, 448 KB of ROM, 520 KB of on-chip SRAM, and 16 KB of RTC SRAM. Whether flash and PSRAM are in-package depends on the part number, so usable memory differs across the family.

The power profile sets the ceiling on any networked design:

  • Deep-sleep with only the RTC timer and RTC memory draws 10 µA in the datasheet.
  • Hibernation draws 5 µA.
  • Light-sleep draws 0.8 mA.
  • Modem-sleep at 80 MHz draws 20 mA to 31 mA on dual-core parts.
  • A Wi-Fi transmit burst draws about 240 mA.

Espressif's deep-sleep current test measures roughly 5 µA to 7 µA with an RTC GPIO as the wake source. The ESP32 also accelerates AES, SHA, and RSA in hardware, and ESP-IDF ships a Mbed TLS fork for TLS 1.2 and TLS 1.3.

Why the pairing works

The ESP32 has neither the memory nor the compute to run a language model locally, while the judgments a sensor product needs are small and belong to a fixed set. Jev moves the model off the device and leaves the decision on it. Four properties make that split practical.

Typed answers remove parsing from the device

A device that asks a model to "return JSON" must hold that text, parse it, and survive malformed output. Jev returns values constrained to the options you supplied, so the firmware compares a typed value and no parsing step exists. On a part with 520 KB of SRAM, that changes the heap budget during a TLS session. Espressif's Mbed TLS documentation shows a request with server validation using about 42 KB of heap, dropping to about 38.5 KB when the peer certificate is not kept and to about 22 KB with dynamic TX/RX buffers enabled. Heap is the scarce resource during a handshake, so a response that needs no prose buffer protects the thing that most often fails.

Output is free, so device cost scales with what the device sends

TypeSafe prices Jev at $42 per billion input tokens, or $0.042 per million, and output tokens are free. A product that sends a compact state and receives a choice pays only for the state. An ESP32 reading a few sensors produces a small state by nature, so the cost per decision stays low without effort on the firmware side.

Latency fits the awake window the radio already pays for

TypeSafe reports end-to-end response times of 70 ms to 500 ms. That window fits inside a Wi-Fi round trip the device would spend awake regardless. It does not fit hard real-time control, where an action must land in single-digit milliseconds, because the network and the model both add variable delay.

The radio sets the power cost

Calling Jev holds the ESP32 in active Wi-Fi transmit at roughly 240 mA for the length of the round trip. A design built to sleep between reads must budget that window into its power math. The relation runs in one direction: a shorter response leaves less awake time, and less awake time means a longer battery life.

The data path

The device owns the state and the action, and Jev owns the judgment. That separation is the whole architecture.

flowchart LR
    A[Sensor / button / input] --> B[ESP32 builds state as JSON]
    B --> C[HTTPS POST /v1/systemone]
    C --> D[Jev evaluates typed questions in parallel]
    D --> E[Typed answers with probabilities and confidence]
    E --> F{Confidence above threshold?}
    F -->|Yes| G[Act: relay, route, or gate]
    F -->|No| H[Fallback: retry, queue, or ask a person]

Confidence is the field that makes the fallback branch possible. TypeSafe computes it from the probability distribution and returns it on every Choice and Score answer, so firmware can act automatically above a threshold and defer below it. The threshold is yours to set, and it should scale with the consequence of a wrong action.

Where Jev is not the right choice

A great choice for one ESP32 product is a poor choice for another.

  • Offline operation. Jev is a hosted API, so a device with no reliable link cannot use it. A product that must decide without network needs a local model or a rule set.
  • Large state. The context budget is 64k tokens per request, with 32k for the state plus the longest question. An ESP32 rarely carries that much text, so this ceiling only binds products that stream logs or transcripts.
  • Non-text input. Jev accepts text only. Images, audio, and video must be preprocessed into text or structured fields before they become the state, and that preprocessing has to happen somewhere.
  • Non-English workloads. English is the best-supported language, and other languages are accepted with lower accuracy. Test on your own content before routing on the result.
  • Data leaving the device. The model runs on TypeSafe's servers. TypeSafe states it does not train on customer requests or responses and offers zero data retention for enterprise customers, but the state still leaves the device, which matters for regulated products.
  • Treating confidence as correctness. TypeSafe states that calibration is measured across groups of predictions and does not guarantee that an individual answer is correct. A high confidence score is a reason to act, not proof the action is right.
flowchart TD
    Q1{Has a reliable network link?} -->|No| L[Local model or rules]
    Q1 -->|Yes| Q2{Is the decision a fixed judgment?}
    Q2 -->|No, needs reasoning or prose| LLM[Frontier LLM]
    Q2 -->|Yes| Q3{Offline or hard real-time required?}
    Q3 -->|Yes| L
    Q3 -->|No| J[Use Jev]

The performance claims you should discount

TypeSafe advertises Jev as 193.6 times faster and 444.6 times cheaper than comparison models. Those figures are company-generated. In its own technical notes, TypeSafe says the workflows were created by members of its model-capabilities team, acknowledges possible bias, and describes the reported gains as likely to sit at the high end of real-world results. Independent coverage has repeated that the numbers are not verified and will vary by workload and network location. Plan with the 70 ms to 500 ms range and the published $0.042 per million input price, then measure on your own workload before committing a product to them.

Choosing between the options

Option Choose it when
Local TinyML or TFLite Micro The device must decide offline, or the model is a small fixed classifier.
Rule or state machine The mapping from input to action is deterministic.
Jev through the hosted API The judgment belongs to a fixed set, the device has network, and the answer must be typed and calibrated.
Frontier LLM The product needs generated text or multi-step reasoning rather than a constrained judgment.

The condition that separates Jev from a local model is whether the device has a dependable link. The condition that separates it from a frontier LLM is whether the product needs prose or a judgment.

Work with CortexTech

If your product pairs a constrained device with a hosted decision API, CortexTech builds the working prototype before you commit to production.

Sources

Want to read more?

More engineering deep dives from the Cortex R&D team.

All Articles