Why Is Your “Fast” System 1 AI Still Sitting Behind an HTTP Call? (Jev) A developer has released Glacier.Clavier, an open-source .NET library that runs System 1 decision primitives — Choice, Score, and Noul — as native in-process evaluations instead of HTTP calls to cloud APIs. Benchmarks cited in the project show P50 latency of roughly 140 microseconds versus about 110 milliseconds for a cloud decision API, with zero heap allocations via blittable structs. The author argues that wrapping discrete decisions in TLS, JSON serialization, and gateway round-trips makes remote engines a bottleneck for high-throughput backends and multi-step AI agents. The entire industry spent the last week talking about Jev . TypeSafe AI correctly diagnosed a fundamental pathology in modern software architecture: we have been renting slow, expensive System 2 generative LLMs to make mundane System 1 decisions . You don’t need an autoregressive 70B parameter model spitting tokens to decide which queue an incident belongs in, whether a SQL query needs human approval, or which tool an agent should run next. Jev solved the output waste by bounding the problem space to three typed primitives— Choice , Score , and Noul boolean confidence —and running them in a single parallel pass without token-by-token generation. The thesis is spot on. But take a hard look at the telemetry coming out of production: Why are we celebrating a 200ms round-trip for a discrete decision? If you operate high-throughput distributed backends, game loops, local agent runtimes, or high-frequency order routers, 200 milliseconds is an eternity . The moment your "System 1" engine sits behind TLS handshakes, JSON serialization, HTTP headers, and external cloud gateways, you haven't built an intuitive reflex—you’ve built a slightly cheaper remote bottleneck. What does a real System 1 decision engine look like when it lives where your code actually executes? When you call an external decision model like Jev over the wire, where does your time actually go? The compute itself was fast, but the plumbing around it ate 80% of the budget. If you are coordinating an AI agent that takes 15 discrete tool-choice steps per turn, that’s 3 full seconds of your user staring at a spinner just waiting for routing decisions. In high-performance .NET systems, we treat allocations and boundaries as first-class constraints. If an operation doesn't mutate memory or generate arbitrary text, it should run: This was the design motivation behind Glacier.Clavier https://github.com/ian-cowley/Glacier.Clavier?utm source=gemini . Instead of treating Choice , Score , and Noul as HTTP endpoints, Clavier treats them as native, in-process evaluation primitives backed by low-overhead C .NET 10 runtimes and unified local memory such as AMD ROCm / RDNA unified APU memory or bare-metal local compute . To get sub-millisecond execution, you cannot allow the GC to track intermediate state. Everything sent to and returned from the evaluation engine must be blittable: // 8-byte blittable decision primitive - zero heap allocation StructLayout LayoutKind.Sequential, Pack = 1 public readonly record struct ChoiceDecision byte SelectedIndex, Half Confidence, Half MarginToSecond ; When feeding state to the engine, instead of allocating JSON buffers, the engine operates directly over contiguous spans of memory: ReadOnlySpan