JEPA, Jev, and faster decisions for agent memory

A small decision inside a larger system

A memory system makes many small judgments: does this passage support the question, does this claim concern a project, and should it appear under Dev or Accounting? Those decisions sit between ordinary application code and models that extract or write text. We tested whether a specialized model could make them faster.

TypeSafe’s Jev accepts state and typed questions and returns values and probabilities. Its Choice primitive selects from supplied options, Score evaluates a rubric, and Noul assesses a statement on a 0–1 scale. Our application combines those results with explicit rules.

Sources: TypeSafe introduction and primitives

JEPA is a research approach; Jev is the API we tested

JEPA stands for Joint Embedding Predictive Architecture. An embedding is a numerical representation of information. A JEPA learns to predict a target representation from a context representation, rather than reconstructing every detail of the original input. In I-JEPA, a 2023 image-learning model, context from one image region predicts representations of other regions.

That is a useful example of learning without generating a human-readable answer. It does not identify Jev’s architecture. The TypeSafe documentation we reviewed describes a custom architecture and training method but does not establish that Jev implements JEPA. Our measurements evaluate Jev’s hosted API, not I-JEPA or a JEPA research model.

Sources: Assran et al., Self-Supervised Learning from Images with a Joint-Embedding Predictive Architecture; TypeSafe’s Jev announcement

Why a constrained answer can arrive quickly

TypeSafe attributes Jev’s speed to giving up free-form string generation and sampling structured decisions in parallel. A conventional autoregressive model generates successive output tokens; Jev’s interface asks for predefined decisions instead. TypeSafe also describes training for calibrated decisions. These are the provider’s explanations, not architecture details we independently measured.

We know less about the contribution of model size, serving hardware, and internal implementation. Our timings include the network and the work performed by each tested adapter. They cannot isolate an architectural speedup.

Structured output still needs a correctness check. A valid category or probability can be wrong. We keep response validation, conservative thresholds, and a way to abstain or correct the result.

Sources: TypeSafe’s description of parallel structured outputs

The comparison: Jev versus GPT-5.6 Luna

We ran the same 81 synthetic evidence questions through Jev 1.13.0, Luna with reasoning disabled, and Luna with low reasoning. The arms were randomly interleaved, once per case, with one excluded warmup each and no retries. These cases had already informed development; they were not an independent holdout.

An exact match requires both the expected passages and their relevance labels. An unsupported question should return no evidence. The table measures evidence assessment after candidate passages are supplied, excluding retrieval, embeddings, database work, and storage.

Jev’s median was about 4.4 times lower than Luna with reasoning disabled and 11.7 times lower than Luna with low reasoning. The small difference in exact matches does not establish general quality superiority. Jev confused similarly named entities in two unsupported questions, including Foal and Foals.

The adapters also do different work. Luna retains Space’s internal answer drafting, extracted-quote verification, and conditional conflict check. Jev uses a rubric developed in our earlier experiments and selects supplied passages. Jev reused an HTTP connection in this run; Luna opened clients per call. Those differences matter when interpreting speed.

At the observed cache reuse, Jev and Luna with reasoning disabled cost almost the same. Luna reused about three quarters of its input tokens. Costs are estimates from API usage and tariffs recorded on September 17, including cache writes and reasoning output; they exclude taxes, credits, and other app costs. Changing cache reuse changes the comparison.

Sources: Space benchmark cases, measurements, and recorded tariffs (JSON)

The deployed route keeps a fallback

Space uses Jev for eligible short passages and sends uncertain, conflicting, or longer inputs to the text assessor. The integration replay called the actual relevance-selection code, including response checks and every fallback call. It used fresh HTTP clients per request, no warmup, and no retries.

Across 97 synthetic cases, this route matched 94 complete passage-and-label sets and 95 passage sets. It returned unsupported evidence for 1 of 42 unanswerable questions. Median assessment time was 721 ms and p95 was 6,060 ms. Sixty cases finished directly through Jev, 34 fell back, two used the text model directly, and one empty case needed no model.

For a comparison on matching questions, the table below uses only the 81 reused cases. Luna’s numbers come from the earlier run, so provider load and cache behavior were not controlled between these measurements.

Typical assessment was faster, but estimated cost was about 27% higher. Some requests pay for both Jev and Luna. The p95 result also shows that a quick median does not make every request quick. This is the trade-off we accepted for staging, rather than a claim that the integrated route is always cheaper.

Sources: Space benchmark cases, measurements, and recorded tariffs (JSON)

Classification improved when we described the labels clearly

We then tested a different task: assigning a memory to user-defined categories, sections, and projects. This was a separate Jev evaluation with eight catalog items: three categories, two sections, and three projects. An exact match requires the correct scope and every assignment set.

The initial broad instructions matched only 8 of 20 cases, mostly because Jev abstained. We replaced the shared instructions with a specific question, target description, and rubric for each label type. The same 20 development cases then matched exactly. Ten additional cases were frozen before their first live run.

The fresh-case miss assigned Food correctly but left a lasting cilantro preference’s scope unassigned: its global probability was 0.80, below our 0.90 threshold. Category and section matches use 0.85; project and global matches use 0.90. Those are operating choices, not guarantees of accuracy.

The improvement came from clearer decision rules, not adding the expected answer to the input. This small, agent-authored test is useful development evidence, not a production accuracy estimate. We did not compare Luna on memory classification, and its per-claim costs should not be compared with the earlier multi-passage relevance assessments.

Sources: Space benchmark cases, measurements, and recorded tariffs (JSON)

What is running in Space now

On September 17, we enabled Jev relevance assessment and memory classification in the staging API and extraction worker. Users can create categories and sections, link projects to sections, and inspect or correct assignments. A manual assignment stays pinned through automatic updates to the same claim. Existing memories require explicit classification; we did not silently backfill them.

Each classification receives a memory’s title and text plus the catalog’s names, descriptions, and kinds. Space validates the response and maps it to saved IDs. Automatic classification currently supports at most 32 active catalog items combined; larger catalogs are left unassigned. Labels do not change access permissions or the source citation.

A live smoke test produced three memories from a synthetic document and verified automatic assignments, manual corrections, and reclassification. The whole queued extraction took 139.27 seconds. A separate Jev-only request from the operator machine took 766 ms. The first includes queue and startup time, extraction, embeddings, classification, and persistence. We did not measure those stages individually, so this is not evidence that classification caused the delay.

Sources: Space benchmark cases, measurements, and recorded tariffs (JSON)

The measurements we still need

Jev has earned a narrow role in Space: fast judgments over supplied context with application rules around the result. It does not replace the model that extracts text or the embeddings used to retrieve candidates. Typed answers remain fallible.

Next we need representative user corpora, larger catalogs, repeated measurements, better tests of similarly named projects, and a profile of the full extraction pipeline. We also need to measure how often people correct labels. A fast decision is useful when it reliably puts the right context in front of the user.