Diogo Almeida — co‑author of the InstructGPT paper and founder/CEO of TypeSafe AI — publicly launched Jev, which TypeSafe positions as a new class of model: a “System One” model meant to be consumed by code rather than primarily used as a chat interface by humans. The launch video has been viewed roughly 40 million times; for context the team cites view counts of GPT‑4o (22M), Fable 5 (15M), Navier Stokes (74M) and 6 Astra (137M).
TypeSafe’s stated goal is to build machine‑native, large programmable models that are optimized for being called from software. The company defines its primary optimisation metric as “intelligence per dollar” — how much useful intelligence you get for a given cost.
What differentiates Jev and System One models?
- Consumer of outputs: code (APIs, programs) rather than humans. The whole stack — including model internals and API primitives — is designed for programmatic consumption.
- Priorities: reliability, calibration (useful confidence estimates), cost‑efficiency and speed trade‑offs judged against intelligence per dollar.
- Benchmark stance: TypeSafe rejects public, gameable benchmarks and stresses internal, workflow‑specific evaluation and real usage metrics.
RLCD and the calibration argument
Almeida, who participated in early post‑training work at OpenAI, explained why he sees common post‑training directions (RLHF, RLVR) as flawed north‑stars for API‑served frontier models. TypeSafe’s alternative is a new, unpublished technique they call Reinforcement Learning for Calibrated Decisions (RLCD). Their argument in brief:
- RLHF (optimising for human‑rated outputs) can encourage mode collapse, sycophancy and overreliance on human labels.
- RLVR (optimising programmatically verifiable outputs and rubrics) can ace some benchmarks but produce jagged, brittle intelligence that doesn’t integrate well into composable software.
- RLCD aims to optimise for answers that carry epistemically honest probabilities on System One tasks — i.e., produce calibrated uncertainty estimates that are actionable for programs instead of just human preferences.
Almeida highlights what he calls the ‘bitterest lesson’: picking the right task (and the right form of data) matters more than simply throwing compute at the problem.
Product philosophy: refusals, safety and privacy
- Refusals: TypeSafe criticises models that routinely refuse tasks. Almeida’s point is practical: if a model is a background dependency inside software, stochastic refusals are unacceptable and break composability.
- Safety vs capability: TypeSafe separates product‑level safety choices (appropriate for consumer chat products) from the lower‑level engineering goal of producing reliable, composable intelligence for programs. They argue that technological layer restrictions intended to bias usage (for example to prevent harmful uses) can fracture intelligence and are better handled by policy, legal and product layers rather than by fundamental model behaviour.
- Data stance: TypeSafe calls itself a data lab; the team focuses on task‑specific, often synthetic or curated data and avoids training directly on users’ production data in order to prevent overfitting to present‑day usage patterns.
API primitives and programmatic integration
Jev exposes new, AI‑native primitives intended to map neatly onto programming constructs:
- choice — a discrete selection (maps to enums / switch logic)
- score — a continuous value for sorting or thresholding
- noulli — a Bernoulli‑inspired probability primitive (bool‑like but probabilistic)
These are designed so code can pass structured JSON state and receive structured outputs instead of relying on large string prompts and brittle system messages. Almeida advises developers to decompose workflows into small, verifiable decisions, structure state as typed data and write tests that lock in expected behaviour.
Determinism, robustness and versioning
- Determinism is not TypeSafe’s primary north star. Almeida argues that robustness — producing similar outputs for semantically similar inputs and providing calibrated confidence — is more important for automation than strict same‑input/same‑output determinism.
- Deterministic modes could be offered, but they typically reduce intelligence per dollar (higher compute cost for the same effective capability).
- Model versioning and LTS: TypeSafe plans fast iteration and new models frequently, but recognises developers’ dislike of breaking changes and will consider long‑term support (LTS) for popular model snapshots when necessary.
Launch traction and metrics
TypeSafe reports substantial developer momentum after launch. Public signals include the ~40M view launch video and, internally, very large token volumes: the team mentioned daily token usage crossing into the trillions, and that a meaningful share of calls are machine‑driven (i.e., not only ad‑hoc human trials but background, programmatic usage).
The company views rate limits, tokens per day and sustained background calls as better indicators of developer adoption than raw signup numbers.
Early use cases and cookbooks
TypeSafe shipped patterns and “cookbooks” for developers. Highlighted early use cases include:
- Computer use and voice + browser control demos (the launch showed examples where Jev could control apps and carry out multi‑step browser actions);
- Games: smart NPCs and in‑game automation (e.g., a Doom demo showcased interactive control patterns);
- Virtual try‑ons, Excalidraw‑style collaborative tools;
- Coding agents: linting, tool calls, and stateful agent orchestration (Diogo emphasised limits of current KV‑cache based coding‑agent designs and promised notes on alternatives);
- Analytics and dark‑data exploration: replay, user‑journey review, entity resolution and NL search over private datasets.
Almeida and the team emphasise that many demos and community contributions already outstrip their internal expectations, and that cookbooks reflect real customer problems and patterns discovered during product development.
Benchmarks and internal evaluation
TypeSafe is strongly critical of public benchmarks because they are easy to game and can encourage overfitting. Instead, the company uses internal evals and workflow‑specific testing to place models on a Pareto frontier of intelligence per dollar. Almeida admits the tension — teams want transparent comparisons — but argues long‑term trust will come from real workflow performance rather than leaderboard numbers.
Model sizes, fine‑tuning and deployment trade‑offs
- Almeida said he would not pre‑train anew even if given a large budget; the company favours alternatives (post‑training, data engineering, task design) over large‑scale pre‑training runs.
- Fine‑tuning is not off the table, but the firm is cautious: fine‑tuning can be a foot‑gun if not handled carefully and open‑source fine‑tuning experience has been mixed at major providers.
- The team considers offering multiple model sizes and dynamic routing (picking different Pareto points for different parts of a workload) as plausible future directions.
System One vs System Two, reasoning and multimodality
Almeida frames System One as the class of capabilities that pre‑trained condensed models are already strong at — fast, associative, programmatic judgments — while System Two reasoning (long chain, fragile symbolic reasoning) is different in nature and often better addressed by specialised approaches. He does not rule out adding reasoning capabilities, but stresses these are empirical questions about which methods actually produce robust, integrated behaviour when models are embedded in software. Vision and other modalities are also on the road‑map, but TypeSafe will weigh empirical benefits vs integration costs.
Coding agents, KV cache and agent orchestration
Diogo called out coding‑agent architectures currently dominated by a single model and a growing KV cache as a constraint: the cache‑first design tends to couple agents to one model and to append states that make routing and sub‑agent decomposition inefficient. He asked the community to explore alternatives:
- smarter state‑labeling and selective lookup instead of appending everything every time;
- hierarchical sub‑tasks with selective context retrieval;
- multi‑agent coordination with sensible read/write semantics and selective sharing of intermediate state.
These design questions could enable cheaper, more composable agent swarms and better memory management for long‑running agent systems.
Hiring, community and next steps
TypeSafe said they are hiring for data/model‑capability engineers, infra/platform engineers, DevRel and other roles. Almeida repeatedly emphasised the company’s developer focus: town halls, Discord community and cookbooks are central to how they plan to iterate and prioritise.
Bottom line
Jev is TypeSafe’s first public System One model and a concrete expression of a philosophy that prioritises programmatic integration, calibrated decisions and cost‑efficient intelligence for software. The launch attracted substantial attention, the platform reports meaningful token traffic and developer experimentation, and the firm is positioning itself to iterate quickly while emphasising internal, workflow‑oriented evaluation over public benchmarks. TypeSafe’s roadmap includes additional model shapes, improved tooling for agent orchestration and deeper integration patterns for software that wants intelligence to run reliably in the background.
