---
name: The Daily Diff
tagline: An Engineering Newspaper Curated By Arpit Bhayani
curator: Arpit Bhayani
curator_url: https://arpitbhayani.me/
date: 2026-07-07
edition_label: "Tuesday, July 7, 2026"
canonical_url: https://tdd.cat/2026-07-07/
---

# The Daily Diff — Tuesday, July 7, 2026

> An Engineering Newspaper curated by [Arpit Bhayani](https://arpitbhayani.me/)

--------------------------------------------------------------------------------

## [Engineering deployment harnesses drives recursive self-improvement in agents](https://lilianweng.github.io/posts/2026-07-04-harness/)

**By:** Lilian Weng  
**Why read:** Read this to understand how orchestration harnesses surrounding base models enable recursive self-improvement. You will learn key architectural patterns for managing context, tool execution, and agentic workflows.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48814583)  

The real performance ceiling for modern AI agents is rarely the raw foundation model; it is almost always the execution harness wrapped around it. Pretrained intelligence provides the reasoning engine, but the harness governs how the system perceives state, structures memory, and interacts with tools over long horizons.

Successful production harnesses, like those powering advanced coding agents, converge on clear structural patterns. They treat the file system as persistent external memory, structure sub-agent delegation through explicit backend jobs, and enforce aggressive context pruning rather than dumping raw tool traces back into the prompt.

This harness layer is also where true recursive self-improvement happens in practice. Models can optimize their own workflows, write specialized evaluation functions, and tune their execution scaffolds through evolutionary search without modifying underlying model weights.

Building capable agents is fundamentally a systems architecture problem, not just a model training exercise.

---

## [Why existing Postgres connection poolers introduce leaky abstractions](https://pgdog.dev/blog/why-yet-another-connection-pooler)

**By:** levkk  
**Why read:** Read this to understand how traditional Postgres connection poolers corrupt session state and why seamless pooling requires preserving client settings.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48819308)  

Connection poolers like PgBouncer achieve high performance by enforcing a strict UNIX philosophy, but that design introduces subtle state leaks into production systems.

When you pool database connections at the transaction level, session configuration commands become dangerous. Executing a statement such as SET statement_timeout or assigning session variables for Row Level Security alters the underlying physical connection. If that connection is recycled back into the pool without a complete reset, the subsequent client inherits that modified state. This often leads to silent security bypasses or runaway queries.

Engineers usually work around this behavior by banning SET statements entirely or rewriting application code to use local transaction parameters. In large codebases with thousands of queries, retrofitting these workarounds carries substantial risk and operational burden.

PgDog addresses this architectural friction by actively tracking connection state inside the proxy itself. By maintaining visibility into session parameters and cleaning them up before returning connections to the pool, the proxy eliminates the leaky abstraction without forcing teams to overhaul their existing database queries.

---

## [New runtime executes primitives directly on compressed vectors](https://lv1.sh/)

**By:** skruger  
**Why read:** Read this to understand how the l runtime accelerates array programming by operating directly on compressed data to overcome hardware memory bandwidth bottlenecks. You will learn how transparent compression and automatic vectorization modernize high-performance K and Q execution without modifying existing code.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48821378)  

Modern analytical hardware starves for memory bandwidth long before it runs out of compute capacity. A new runtime for k and q, dubbed l, addresses this memory wall by treating transparently compressed vectors as its core unit of execution instead of materializing full arrays in memory.

Traditional database engines decode compressed columnar blocks into memory buffers before evaluating filter or aggregation expressions. In contrast, l evaluates vector operations directly over compressed structures across storage, memory, and transit. Because primitives operate natively on packed representations, data movement between CPU caches and main memory drops significantly.

The runtime also injects automatic SIMD vectorization using AVX-512 and Apple Silicon NEON alongside multi-threading without requiring manual query annotations. For analytical engines handling high-frequency market data, keeping bytes compressed through the execution pipeline solves the real physical bottleneck: memory bus saturation.

Operating directly on compressed memory is the most effective way to beat modern hardware bandwidth limits.

---

## [Optimizing full pipeline inference with hybrid sliding window attention](https://mimo.xiaomi.com/blog/mimo-v2-5-inference)

**By:** theanonymousone  
**Why read:** Read this to understand how hybrid sliding window attention drastically reduces memory overhead during long-context inference. You will learn the concrete engineering challenges of translating theoretical attention architectures into production systems.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48814170)  

Scaling context length in large language models always runs straight into memory bandwidth bottlenecks. In standard full-attention architectures, memory consumption and attention computation grow quadratically, forcing teams to make painful trade-offs between context size and hardware spend.

The engineering team behind MiMo v2.5 solved this by combining sparse Mixture of Experts with Hybrid Sliding Window Attention. By interleaving local attention across most layers with global attention across only a few critical layers, they compressed Key-Value cache storage down to one-seventh of traditional full attention while preserving long-range dependency tracking.

Theoretical savings do not automatically produce production speedups. The real engineering difficulty lies in cache management, handling prefix matching across split layers, and synchronizing asynchronous prefetching across multi-tiered memory without stalling execution pipelines.

Memory architecture and cache eviction design determine inference viability far more than raw model parameter counts.

---

## [Tool calling failures in open models are harness problems](https://twitter.com/MrAhmadAwais/status/2050956678502420612)

**By:** Ahmad Awais  
**Why read:** Read this to understand the finite, predictable schema mistakes open models make during tool calling and how a lightweight repair layer can fix them.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48820182)  

Open-weight models often fail at tool calling not because the underlying weights are deficient, but because the harness mishandles schema errors. Teams frequently abandon open models after watching validation libraries reject malformed outputs, incorrectly assuming the model cannot execute complex instructions.

In reality, tool calling failures follow a small, predictable set of patterns. Models consistently emit null for optional parameters, serialize lists as JSON strings instead of actual arrays, supply empty object brackets instead of lists, or pass bare strings where a collection is required. Because the model receives raw validation errors rather than readable feedback, it fails to recover.

Introducing an ordered, lightweight repair layer directly resolves this breakdown. Parsing array strings and wrapping naked values before validation rescues the vast majority of dropped tool calls, allowing models like DeepSeek to reliably match or outperform closed alternatives on complex multi-step tasks.

Resilient agent design requires robust context and schema engineering rather than blindly upgrading to expensive proprietary endpoints.

---

## [Final token preference optimization reduces repetitive reasoning loops](https://www.liquid.ai/blog/antidoom)

**By:** dataminer  
**Why read:** Read this to understand how targeted final token optimization stops repetitive doom loops in reasoning models without degrading generation quality.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48820127)  

Repetitive degeneration remains one of the most frustrating failure modes when running inference on small reasoning models. A model encounters uncertainty during a chain-of-thought trace, emits a discourse marker like 'Wait, let me reconsider', and promptly enters an unrecoverable doom loop until context limits hit.

Standard inference-time fixes like repetition penalties are blunt instruments that distort token probabilities across the board and degrade downstream reasoning accuracy. Running online reinforcement learning loops with custom rewards works better, but rollouts are computationally expensive.

Final Token Preference Optimization offers an elegant surgical fix. Instead of penalizing loops globally or rerunning full rollouts, it identifies the single token position where the repetitive sequence triggers. The model is trained on chosen and rejected pairs specifically at that junction, leaving the rest of the probability distribution untouched.

On an early LFM2.5 checkpoint, this single-token intervention slashed math and coding loop failures from 10.2 percent down to 1.4 percent while boosting overall evaluation scores.

Targeting the exact pivot point of a failure mode beats bludgeoning the entire probability distribution every time.

---

## [Git hash chains are malleable despite valid cryptographic signatures](https://arxiv.org/abs/2607.02820)

**By:** Jacob Ginesin  
**Why read:** Read this to understand how signature encoding quirks allow attackers to alter signed Git commit hashes without breaking cryptographic verification. You will learn how hash chain malleability undermines dependency pinning and reproducible build pipelines.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48825356)  

A valid cryptographic signature on a Git commit does not guarantee that the commit hash is immutable. Security researchers have revealed that Git hash chains are inherently malleable, allowing an adversary without private keys to alter commit identifiers while retaining valid verification badges.

The vulnerability stems from structural slack inside signature envelopes rather than flaws in hashing algorithms. By applying algebraic inversion to ECDSA signature components, injecting unhashed OpenPGP subpackets, or exploiting non-canonical DER length encodings in CMS envelopes, one can generate distinct commit hashes for identical file trees and author metadata. Git command-line verification and major hosting platforms both evaluate these forged commits as fully verified.

This invalidates a central assumption in modern software supply chains. Systems like Nixpkgs, Go module proxies, and continuous integration workflows frequently treat Git commit hashes as content-addressable primary keys for integrity checks and dependency pinning. When distinct hashes map to equivalent signed states, hash-based blocking rules and cryptographic audit trails lose their immutability guarantees.

Commit verification proves who authorized the code, but it cannot prevent silent identity drift.

---

## [Deterministic folding replaces expensive LLM summarization for agents](https://github.com/dogtorjonah/context-warp-drive)

**By:** dogtorjonah  
**Why read:** Understand how deterministic CPU-based folding preserves prompt prefixes and cuts costs in long-running LLM agents without relying on lossy summarization.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48819050)  

Using an LLM to summarize conversation history in an agent loop is an anti-pattern that quietly wrecks prompt caching. Every time a summarization pass rewrites previous turns, it invalidates prompt cache prefixes, incurs extra token latency, and risks dropping critical variable names or exact identifiers that tool execution requires.

Deterministic context folding offers a cleaner architectural path. By executing pure CPU-based folding with exact byte-level token boundaries, the system preserves reusable prompt prefixes across long-running sessions without making any extra model invocations. In offline benchmarks, this approach reduced token costs by over 70 percent compared to generative summarization. Paging folded sections back into memory only when referenced keeps active context compact while hitting a 92.6 percent prompt cache-read rate.

Context management in agent harnesses should be treated as a deterministic memory paging problem rather than an open-ended generative task.

---

## [Composing independent TLA+ specifications using state machines](https://www.hillelwayne.com/post/composing-tla/)

**By:** Jimmc414  
**Why read:** Read this to understand how to modularize and compose complex TLA+ specifications that share state without introducing conflicting constraints. It provides a practical architectural pattern for integrating large formal models independently.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48825164)  

Composing formal specifications in TLA+ is notoriously difficult because shared state variables inevitably create contradictory constraints. Standard practice usually forces engineers to write monolithic specifications, which quickly collapse under the weight of state-space explosions and unmaintainable invariants.

When modeling distributed protocols, you often want separate state machines for workers and servers that can evolve independently. The core problem appears when a worker reads a server response: the worker specification cannot assert that the variable never changes without preventing the server from mutating it.

By introducing explicit state machine boundaries and treating shared interactions as synchronized message steps rather than direct variable bindings, you can verify subsystems in isolation before evaluating global system invariants. This drastically reduces the verification footprint and allows teams to modularize critical safety proofs across service boundaries.

Formal verification only scales when your models can be modularized just like your code.

---

## [Signed GitHub commits are not unique due to signature malleability](https://www.internationalcyberdigest.com/new-research-a-verified-github-commit-is-not-unique/)

**By:** Jacob Ginesin  
**Why read:** Read this to understand how signature malleability breaks the assumption that verified Git commit hashes are unique. You will learn the exact mechanisms attackers can use to alter commit hashes while retaining valid forge verification.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48823878)  

A verified Git commit hash is not an immutable identifier for signed code. New research from Carnegie Mellon University shows that an attacker without your private signing key can generate a completely different commit hash that still carries a valid signature and displays the green Verified badge on GitHub.

The attack exploits cryptographic signature malleability across GPG, SSH, and S/MIME rather than finding collisions in SHA-1 or SHA-256. For ECDSA, an attacker flips the signature from (r, s) to (r, n-s). For RSA and EdDSA OpenPGP packets, RFC 4880 permits unhashed subpackets that attackers can append without invalidating the signature.

Because Git commits incorporate their parent hash, this malleability cascades down the entire commit tree. Continuous integration pipelines and package managers that lock dependencies to specific commit hashes can be tricked into accepting alternative serializations with altered parent histories.

Verifying a commit signature alone does not protect your supply chain if your verification logic does not explicitly tie the signature payload to the expected commit object hash.

---

## [Fast write-ahead logs overcome object storage write latency](https://rockwotj.com/blog/chorus/)

**By:** Tyler Rockwood  
**Why read:** Read this to understand how appendable object storage primitives can eliminate write latency bottlenecks in modern distributed storage systems.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48825008)  

Building storage engines directly on top of cloud object storage has always run into a brutal wall: write latency. While systems like SlateDB and TurboPuffer hide read latency behind pre-warmed NVMe caches, writes to traditional S3 buckets require multiple network hops and high round-trip times that make synchronous durable logging painful.

Chorus tackles this problem by rethinking the write-ahead log layer over modern appendable object primitives. Instead of treating object storage as a rigid block of immutable keys, this architecture leans into cloud APIs that expose native append semantics, such as Google Cloud Rapid Storage Buckets backed by Colossus.

With appendable primitives and synchronous flushes enabled, durable commit latency drops to 2 milliseconds at the ninety-ninth percentile. That latency level matches dedicated disk volumes while retaining the auto-scaling and bottomless capacity guarantees of object storage. Distributed system engineers no longer need to sacrifice operational simplicity just to achieve fast, durable writes.

The future of cloud databases will belong to designs that turn appendable object storage into first-class write-ahead logs.

---

## [Running untrusted LLM agents safely using transparent egress interception](https://github.com/apoxy-dev/clrk)

**By:** dilyevsky  
**Why read:** Read this to understand how CLRK isolates untrusted agent workloads inside gVisor sandboxes with transparent network interception. You will learn how to enforce security policies, gain observability, and manage costs across LLM and tool calls without altering agent code.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48822750)  

Running untrusted AI agents in production environments presents a massive security and observability challenge.

CLRK tackles this runtime dilemma by isolating agent workloads inside gVisor micro-containers on Kubernetes. Rather than waiting on sluggish pod startup times, it operates an internal scheduler that dispatches workloads instantaneously onto warm sandbox pools.

The key architecture choice is transparent network interception. CLRK places a man-in-the-middle proxy on sandbox egress, capturing all HTTP and TLS traffic without modifying client code or requiring custom SDKs. Whether an agent executes a Python script, talks to the Model Context Protocol, or hits external vendor APIs, platform teams can inspect, enforce policy, and rate-limit egress out of the box.

This design decouples governance from application logic. Platform engineers gain fine-grained cost telemetry and audit logs, while agent developers write standard code without proprietary wrapper libraries.

Securing autonomous agents requires isolation at the kernel and network boundaries, not in prompt guidelines.

---

## [Scaling PgBouncer across CPU cores using socket reuse and peering](https://clickhouse.com/blog/pgbouncer-clickhouse-managed-postgres)

**By:** Kaushik Iska  
**Why read:** Read this to understand how to overcome PgBouncer's single-threaded limitation across multi-core systems using SO_REUSEPORT. You will learn the mechanics of handling query cancellations across independent pooling processes.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48814152)  

PgBouncer is fundamentally single-threaded, meaning a single process leaves all but one CPU core idle on multi-core servers. On a 16-core machine, connection pooling saturates throughput on one core while the remaining fifteen cores sit completely unused.

The standard workaround is binding multiple PgBouncer processes to the same port using the SO_REUSEPORT socket option. This allows the Linux kernel to distribute incoming connections across the worker fleet. However, scaling out this way creates a subtle and dangerous failure mode: query cancellation stops working reliably.

In Postgres, a query cancellation request arrives over a completely separate connection carrying a cancellation key. When using SO_REUSEPORT, the operating system kernel can route that new cancel connection to an entirely different process than the one holding the client session. That target process has no memory of the running query, causing the cancellation attempt to silently do nothing.

ClickHouse solved this failure mode by implementing an inter-process peering layer across the PgBouncer fleet. When a cancellation packet lands on an arbitrary process, it immediately checks the fleet, locates the process that owns the actual session, and forwards the command directly.

This architecture scales pooling throughput cleanly by four times without breaking client protocol expectations.

---

## [Compiling recorded agent behavior into verified wasm binaries](https://github.com/RightNow-AI/auto)

**By:** RightNow AI  
**Why read:** Learn how repetitive frontier model interactions can be converted into fast, capability-confined execution artifacts. This architecture treats foundation models as interpreters that can be compiled down to deterministic logic and specialized models.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48822488)  

Running multi-step agentic workflows directly against frontier models for routine tasks is becoming an unsustainable economic pattern. Most repetitive agent loops do not need massive neural parameter counts once their state transitions and tool invocations stabilize.

Auto approaches this bottleneck by treating frontier models as interpreters rather than static endpoints. The system traces agent interactions, identifies deterministic symbolic execution paths, distills remaining stochastic operations into tiny specialist models, and compiles the entire execution graph into capability-confined WebAssembly binaries.

When edge cases break behavioral guarantees, a tiered runtime dynamically falls back to the frontier model and schedules recompilation. This drops per-invocation costs to microdollars while maintaining verifiable execution guarantees inside a sandboxed runtime.

Compiling deterministic behavior out of probabilistic model loops is the logical next step for scalable agent infrastructure.

---

## [Normative specification enables standard Python compilation to native code](https://post-py.org/)

**By:** incognito124  
**Why read:** Read this to understand how POST Python establishes a normative, statically typed subset of Python that compiles directly to native code without a runtime. You will learn how one codebase can run under CPython while simultaneously serving as a native C kernel and a NumPy ufunc.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48816273)  

Python performance tooling has long suffered from fragmentation. Projects like Cython, Numba, Codon, and Pythran each invent their own informal Python subset, forcing engineers to rewrite code for specific compiler quirks rather than writing standard Python.

POST Python tackles this from the opposite direction by establishing a normative specification rather than just another one-off compiler. It defines a compilable, statically typed subset that remains 100 percent valid Python code under standard CPython, while allowing an ahead-of-time compiler to emit pure C99 translation units without a bundled runtime.

A single annotated function definition can simultaneously serve as standard interpreted Python, compile down to a native C shared library with a stable C ABI, or export directly as a fast numpy ufunc with vectorization.

Defining language subsets through a strict specification rather than compiler implementation details is a massive step forward for high-performance Python infrastructure.

---

## [OpenAI scales low-latency WebRTC voice using stateless relays](https://blog.bytebytego.com/p/how-openai-delivers-low-latency-voice)

**By:** ByteByteGo  
**Why read:** Read this to understand how OpenAI rearchitects WebRTC for massive one-to-one voice workloads on Kubernetes. You will learn how separating stateless packet routing from stateful transceivers achieves low latency at scale.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48825411)  

Scaling WebRTC for single-user real-time AI audio introduces a nasty architectural tension. Kubernetes expects disposable pods and transient IP addresses, while WebRTC depends entirely on fixed endpoints and stateful sessions. Traditional media architectures use Selective Forwarding Units (SFUs), but that model is wasteful when traffic is simply one human talking to one inference engine.

OpenAI solved this problem by decoupling their audio edge into two distinct layers: an ultra-fast stateless relay at the network perimeter and stateful transceivers running deeper inside the cluster. Instead of terminating connections or maintaining complex session affinity tables, the relay extracts the ICE ufrag directly from the first packet of a session and uses it as a deterministic routing key.

This simple architectural inversion removes the need for centralized connection brokers or shared connection state on ingress. By treating the existing protocol handshake as a routing primitive, edge nodes forward raw UDP packets to the right transceiver pod with minimal latency and negligible memory overhead.

When scaling stateful protocols on cloud-native infrastructure, do not fight the orchestrator. Find a native protocol attribute that can serve as an immutable shard key before you touch the payload.

---

## [Shared local databases preserve state across AI coding sessions](https://github.com/mazen160/backlog)

**By:** mazen160  
**Why read:** Learn how offloading context and task queues into a shared SQLite database prevents memory loss and enables cost-effective multi-agent workflows.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48824120)  

Most AI coding workflows suffer from state exhaustion. Engineers continuously feed hundreds of thousands of tokens into a single chat window, paying compounding inference costs while watching model accuracy degrade as historical noise pollutes the prompt context.

Backlog tackles this problem by externalizing agent state into a structured, local SQLite database shared across the CLI, UI, and subagents. Instead of relying on conversational recall across long-lived chat sessions, tasks, architectural plans, and contextual findings are recorded as signed database writes tied directly to specific actors.

This decoupled architecture enables a stateless worker pool pattern for coding agents. A coordinator spawns a short-lived subagent with only the relevant task row and essential schemas, allows the agent to execute its diff, writes the outcome back to the SQLite store, and immediately tears the process down.

Moving memory from conversational history into a queryable relational database cuts token spend by roughly 90 percent and prevents reasoning drift. Treat your agent context as transient compute, not an unbounded append-only log.

---

## [Coding agent hidden states anticipate future code edit outcomes](https://arxiv.org/abs/2607.05188)

**By:** André Silva, Han Tu, Martin Monperrus  
**Why read:** Read this paper to discover how coding agents internally represent program correctness and predict the outcomes of edits dozens of steps before they are written. It provides compelling mechanistic evidence that language models maintain forward-looking internal representations during multi-step reasoning.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48815591)  

Language models driving coding agents formulate execution outcomes well before writing a single line of code to disk.

Recent research into agent hidden states reveals that residual streams linearly encode key properties of the evolving program, such as whether upcoming edits will compile or pass unit tests. Using simple linear probes on model activations, researchers achieved an AUC of 0.83 for predicting program correctness across standard benchmarks.

Even more remarkably, these internal representations run up to 25 steps ahead of actual token emission. The model anticipates regressions and test suite reductions long before generating the modifying syntax. This phenomenon, termed the latent programming horizon, transfers across benchmark tasks without retraining.

Instead of waiting for costly test execution loops to fail after dozens of tool calls, agent runtime harnesses could monitor internal probes to abort doomed trajectories early.

Looking at model activations rather than just text tokens might be the missing ingredient for reliable agent orchestration.

---

## [How HotSpot C2 compiler optimizes redundant bitwise masks](https://questdb.com/blog/jvm-jit-known-bits/)

**By:** rowbin  
**Why read:** Read this to understand how HotSpot's C2 compiler tracks numeric constraints and bit patterns to eliminate redundant bitwise operations.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48819225)  

Optimizing compilers can quietly eliminate redundant bitwise logic, but the mechanics behind this optimization are far more sophisticated than simple constant folding.

Consider an expression like (x << 2) & -4. Because shifting an integer left by two positions guarantees that the lowest two bits will always be zero, masking it against -4 (1111 1100 in two's complement) is completely redundant. However, for most of HotSpot's history, the C2 compiler represented variables using basic signed ranges [lo, hi]. While ranges work well to eliminate array bounds checks, a range cannot cleanly capture the fact that specific interior bits are guaranteed to be zero or one.

To solve this, modern compilers introduce a known-bits analysis abstraction. Instead of merely tracking a min and max value, the compiler tracks bitmasks of bits that are proven zero and bits that are proven one. Propagating these masks through abstract interpretation allows C2 to prove that the bitwise AND adds no new information, completely deleting the operation from machine code.

Understanding how compilers track value constraints helps engineers write idiomatic code without fear of artificial abstraction penalties.

---

## [Decomposition of trillion-parameter serving steps exposes critical engine overhead](https://brainsless.com/the-decoding-step.html)

**By:** Cortad Research Lab  
**Why read:** Read this to understand how profiling inference step-by-step reveals that engine overhead bottlenecks trillion-parameter model serving more than hardware limits. You will learn how resolving engine inefficiencies unlocked record-breaking throughput on four B200 GPUs.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48816719)  

Serving a trillion-parameter language model at production speeds usually demands dozens of clustered accelerators. A rigorous performance breakdown of Kimi-K2.6 demonstrated that four B200 GPUs can sustain 511.6 tokens per second in a single stream, beating multi-node setups.

The key finding came from decomposing every sub-millisecond phase of the execution step. At a 10,000 token context window, the bare forward pass took 6.6 milliseconds, while verifying a drafted speculative token required only 0.397 milliseconds. Surprisingly, doubling the compute node from four to eight GPUs yielded zero latency improvement.

Profiling revealed that the dominant delay was runtime engine scheduling overhead rather than raw tensor compute. Migrating the exact same weights and draft head to an optimized execution engine stripped 2.1 milliseconds out of every decoding step. That single architectural adjustment produced a fifteen percent gain over top hosted providers.

When scaling inference infrastructure, your bottleneck is frequently software orchestration rather than hardware bandwidth.

---

## [Transparent data encryption for native PostgreSQL without forks](https://github.com/commandprompt/open_pg_tde)

**By:** Command Prompt, Inc.  
**Why read:** Read this to understand how open_pg_tde provides transparent data-at-rest encryption for upstream PostgreSQL without requiring server forks. You will learn how its custom access method secures tables, indexes, and write-ahead logs transparently.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48825643)  

Transparent Data Encryption has historically been one of the primary reasons organizations remained trapped on proprietary database distributions or heavy enterprise forks. Most open-source solutions rely either on operating system disk encryption, which exposes decrypted data in the system page cache, or manual application-level column encryption that destroys indexing capabilities.

The open_pg_tde project solves this cleanly by implementing the PostgreSQL Table Access Method API through tde_heap. Because it integrates natively at the access method layer, PostgreSQL encrypts table pages, TOAST segments, indexes, and Write-Ahead Logs before writing to disk, while leaving query planning and execution completely unaltered.

Engineers can run this as a standard extension on upstream PostgreSQL 16 through 18 without patching the core database engine. Keys remain securely managed through modern external key managers, removing the operational baggage of fork maintenance.

True database-level encryption should belong in core open source infrastructure, not behind vendor paywalls.

---

## [Agent harnesses matter more than semantic layers on benchmarks](https://motley.ai/blog-posts/bird-interact-benchmark-top-score/)

**By:** Egor Kraev  
**Why read:** Read this to understand how agent harnesses and semantic layers interact to boost text-to-SQL accuracy on benchmarks. You will learn why execution scaffolding can matter even more than semantic abstraction when querying relational databases.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48820308)  

Building an effective text-to-SQL agent requires focusing on the harness architecture rather than purely polishing database semantic layers.

In recent evaluations on the BIRD-INTERACT benchmark, adding an open-source semantic layer boosted accuracy from 71.7 percent to 75.3 percent. However, moving from an off-the-shelf framework to a dedicated Claude SDK agent harness produced a much larger leap, jumping from 36.3 percent to over 71 percent. The harness orchestration determined whether the model could effectively self-correct and handle tool execution loops.

The semantic layer still serves a critical architectural role. Instead of generating raw, error-prone SQL strings directly, the agent outputs structured JSON that compiles into validated SQL. This design prevents syntax errors, normalizes metric definitions like net revenue, and feeds the model clean schema metadata.

Furthermore, benchmark gold datasets often contain erroneous labels. Building a dedicated annotation agent to verify benchmark targets boosted the final evaluated score to 83.7 percent against verified answers.

Framework wrappers often hide latency and context bloat, making raw SDK integration the superior choice for production agent infrastructure.

---

## [Preventing credential leakage by keeping secrets outside agent sandboxes](https://declaw.ai/blog/credentials-agents-can-never-read)

**By:** ShivamNayak11  
**Why read:** Learn how to safely grant credentials to untrusted AI agents by attaching secrets at an egress proxy rather than inside the sandbox. This design ensures that even a fully compromised agent can only leak placeholder strings.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48819806)  

Handing sensitive credentials directly to an untrusted AI agent inside its execution sandbox is an architectural antipattern. When an agent is vulnerable to prompt injection or malicious dependencies, any secret placed in its local environment variables or process memory can be dumped and exfiltrated instantly.

A cleaner pattern isolates the secret entirely from the agent runtime. The real secret resides in an external write-only vault, while the sandbox container receives only a harmless placeholder string such as a reference identifier. When the agent initiates an external API call, outbound network traffic routes through an egress proxy.

This egress proxy intercepts the request, identifies the reference placeholder in the headers, swaps it for the real authenticated token on the fly, and dispatches the payload. The agent never observes the raw secret value in its filesystem, memory space, or network responses.

Even under total sandbox compromise, attackers extract nothing more than an inert proxy token. Shifting authentication to the egress boundary turns credential isolation into an infrastructure guarantee rather than a fragile prompting rule.

---

## [Governance dose must match model capacity to avoid degradation](https://zenodo.org/records/21222310)

**By:** Taiko Toeda  
**Why read:** Read this to understand how prompt-based behavioral governance impacts language models across different parameter scales. You will learn why heavy governance overlays degrade smaller models and why reasoning architectures tolerate higher governance doses.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48819945)  

Piling extensive governance instructions and safety checks into a system prompt often degrades model output quality instead of improving it.

An empirical evaluation measuring prompt governance across 27 model sizes demonstrated that heavy guardrails do more harm than good. Below four billion parameters, any behavioral governance prompt degrades generation benchmarks. Once models cross the four billion threshold, light governance comprising just three metacognitive checks consistently outperforms elaborate rule sets.

In fact, heavy governance overlays around 42 kilobytes produced net-negative evaluation scores across almost all non-reasoning models up to 120 billion parameters. The lone exceptions were reasoning-focused architectures like DeepSeek-R1 distills, which possess the capacity to absorb structured behavioral constraints without derailing their execution.

System designers should stop treating system prompts as infinite catch-alls for organizational policy. Keep your inference-time steerability lightweight, or you will actively degrade the reasoning ability of your models.

---

## [Balancing mmap and pread prevents Go runtime thread stalls](https://internals-for-interns.com/posts/mmap-vs-pread-go-storage-engine/)

**By:** valyala  
**Why read:** Learn why combining mmap and pread prevents goroutines from stalling OS threads during major page faults. This guide illustrates practical file access patterns inside a real-world Go storage engine.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48822178)  

Relying purely on mmap inside a Go storage engine can quietly degrade runtime performance under heavy load. While memory-mapped files seem like an elegant way to let the operating system kernel handle page caching, they introduce hidden latency traps.

When a goroutine touches cold memory backed by mmap, the operating system triggers a major page fault. Unlike standard network operations or file system calls that Go can cooperatively park, a kernel page fault blocks the underlying operating system thread completely. If multiple goroutines fault on cold blocks simultaneously, the Go runtime exhausts its worker threads, stalling unrelated goroutines.

High-throughput storage engines like VictoriaLogs resolve this through a hybrid abstraction layer. The storage engine uses mmap when target data is already cached in memory, but routes cold random reads through pread system calls. Because pread runs through standard runtime system call wrappers, the Go scheduler can detach the thread and keep executing active goroutines.

Fast disk I/O requires treating the kernel page cache and the language runtime scheduler as cooperative partners rather than isolated layers.

---

## [How token minting mismatches break model context protocol authentication](http://blog.dwornikowski.com/posts/mcp-auth-explained/)

**By:** Darek  
**Why read:** Read this guide to understand how authentication flows operate between MCP clients, servers, and proxy gateways. You will learn the mechanics behind common token validation failures and how OAuth with PKCE resolves them.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48816794)  

Authentication remains the most common failure mode when building production Model Context Protocol architectures. The typical symptom appears when an agent client holds a valid token, yet the downstream MCP server rejects the request. In almost every case, the authorization server minted the token for an entirely different audience.

Direct MCP communication requires standard OAuth 2.1 with PKCE, where the server acts strictly as an RFC 9728 protected resource. Problems multiply once you introduce an enterprise gateway proxy. A gateway must choose between passing client tokens downstream, minting dedicated assertion tokens, or handling impersonation directly against individual tool servers.

Getting this boundary wrong exposes internal tools or breaks agent delegation silently. Treating MCP servers as standard resource servers rather than independent authorization actors makes cross-tool coordination reliable.

Securing agent protocols requires the exact same identity rigor as any enterprise microservice mesh.

---

## [Preventing false sharing requires spacing atomics across cache lines](https://monoid.github.io/posts/false-sharing-alignment/)

**By:** signa11  
**Why read:** Understand the mechanics of false sharing between CPU cores and learn how proper memory alignment eliminates costly cache line contention.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48816486)  

Aligning atomic variables to sixty-four bytes is no longer sufficient to prevent false sharing on modern hardware. While standard x86 cache lines are sixty-four bytes wide, hardware spatial prefetchers have paired adjacent cache lines since the Intel Sandy Bridge generation.

When two independent atomic variables share a one-hundred-and-twenty-eight-byte window, concurrent writes on separate CPU cores can still trigger costly cache invalidation cycles. The hardware prefetcher loads both lines together into the local cache, causing cores to fight over cache lines even when individual variables do not overlap.

High-throughput concurrent libraries such as Folly and Crossbeam resolve this by padding atomics to one hundred and twenty-eight bytes instead of the nominal sixty-four. Applying this spacing to concurrent queues and per-thread counters eliminates hidden cache contention across modern Intel, AMD, and Apple Silicon chips.

Cache line spacing must account for hardware prefetchers, not just theoretical CPU architecture specs.

---

## [Blocking architectural drift in agent code using virtual asts](https://github.com/lambda-alpha-labs/Graphenium)

**By:** lambda-alpha-labs  
**Why read:** Discover how Graphenium enforces structural boundaries on AI coding agents using virtual ASTs and Datalog. You will learn how pre-flight linting prevents architectural drift before code changes land.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48815458)  

AI coding agents excel at completing local tasks but routinely destroy system architecture by crossing boundaries and introducing silent circular dependencies.

Graphenium tackles this problem by placing an external architecture gate between the agent and your repository. Instead of relying on system prompts or post-hoc linting, it parses virtual abstract syntax trees using tree-sitter and GitHub Stack Graphs, evaluating module boundaries via Datalog rules powered by the Salsa incremental computation framework.

When an assistant like Claude Code or Cursor modifies files, the engine intercepts the proposed changes pre-flight. It validates every new symbol resolution and import edge against mechanical containment policies, rejecting changes that bypass service layers or violate dependency direction before the code touches your branch.

Preventing architectural drift at the AST level removes the need to babysit automated refactors.

---

## [Lazy layer pulling drastically accelerates ephemeral container builds](https://clipper.dev/blog/buildkit-profile)

**By:** a_t48  
**Why read:** Learn how decoupling layer metadata from file content enables lazy pulling and solves cache persistence issues on ephemeral CI runners.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48819764)  

Ephemeral CI runners quietly destroy one of the best performance optimizations in Docker BuildKit: cache mounts. When running inside environments like GitHub Actions, BuildKit provides no native mechanism to persist cache mounts across distinct jobs. As a result, compilation and package caches are discarded after every run, forcing teams to pay full re-download and re-compilation penalties.

Another major bottleneck is layer transfer overhead. Monolithic OCI image layers bundle build-time dependencies together with runtime assets into compressed tarballs. CI builders pull gigabytes of runtime binaries that the compiler never inspects during the actual build phase.

Clipper tackles both bottlenecks with a custom BuildKit driver and registry protocol. Instead of shipping monolithic tar files, it separates metadata into an index while storing file blobs independently. This allows build workers to pull only the exact bytes accessed during compilation. Combined with remote cache mount exports, this pattern dropped llamacpp build times on GitHub Actions from 427 seconds to just 56 seconds.

Treating container layers as queryable file indexes rather than opaque tarballs changes CI economics completely.

---

## [Removing control-plane lookups cuts serverless request latency dramatically](https://modal.com/blog/serverless-servers)

**By:** birdculture  
**Why read:** Read this to understand how Modal redesigned its routing layer to achieve single-digit millisecond latency for real-time inference. You will learn how bypassing control-plane lookups and queues eliminates hot-path overhead.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48816128)  

Shaving thirty milliseconds off a request path is the difference between a sluggish agent and an interactive experience. Modal recently restructured their serverless routing architecture, reducing median proxy latency from 39 milliseconds down to 6 milliseconds for real-time model inference.

The bottleneck in traditional serverless layers is not standard HTTP proxying. The bottleneck is the synchronous coordination needed for authentication, placement decisions, and replica state lookups. Modal achieved this speedup by pairing Cloudflare Pingora and Envoy with Google Cloud Spanner, eliminating control plane lookups entirely from the hot path.

Instead of routing incoming requests through shared queues or synchronous coordinator services, regional edge proxies access cached replica metadata directly. Worker health and replica registration update asynchronously, allowing the data plane to route traffic with minimal overhead while preserving strict tenant isolation and autoscaling guarantees.

Latency optimization at this scale requires pushing all platform coordination out of the critical request lifecycle.

---

## [AI sandbox vulnerability allows full cross-tenant account takeover](https://www.sandsecurity.ai/blog/writeout-writer-ai-cross-tenant)

**By:** SAND Security  
**Why read:** Read this to understand why runtime sandboxes cannot serve as standalone security boundaries in enterprise AI platforms. You will learn how the WriteOut vulnerability enabled complete account takeover through session isolation flaws.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48821400)  

A code execution sandbox is not an absolute security boundary for multi-tenant AI agents.

Security researchers uncovered WriteOut, a critical isolation vulnerability in Writer AI that allowed attackers to escalate from an unauthenticated link to full tenant takeover. By manipulating the execution context inside the agent sandbox, an attacker could breach session isolation and extract private enterprise data, custom models, system prompts, and API credentials across accounts.

Teams designing agentic infrastructure often assume that running model-generated code in microVMs or containers neutralizes untrusted inputs. However, if the orchestration runtime shares metadata services, session tokens, or internal network interfaces with the sandbox, the agent becomes an attacker proxy. The boundary is only as sound as the network and credential isolation wrapping the runtime.

Treat agent runtimes as hostile environments from day one, not trusted internal components.

---

## [Offloading observability state to object storage eliminates operational friction](https://blog.triplecloud.tech/posts/observability-ingestion-on-s3)

**By:** mineev  
**Why read:** Read this to understand why stateful storage creates an operational grind in self-hosted observability and how object storage offers an alternative architecture.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48823003)  

Operating self-hosted observability at scale almost always hits a wall at the stateful tier. Tools like Grafana Loki, ClickHouse, or Elasticsearch scale query compute cleanly, but the stateful ingestion path leaves teams nursing degraded disks, replication lag, and fragile local write-ahead logs.

Loki relies heavily on object storage like Amazon S3, but its ingestion architecture still keeps a stateful buffer on local NVMe drives before flushing. Eliminating this local disk dependency completely changes the operational calculus. By accepting slightly higher read latency, telemetry pipelines can ingest directly into object storage, removing WAL corruptions and node-recovery headaches from on-call rotations.

Designing this requires strict batching algorithms and memory management to avoid ballooning API call costs. S3 PUT requests add up fast if ingestion micro-batches too aggressively, meaning engineers must balance flush timers, memory buffers, and catastrophic node termination risk.

Trading local disk guarantees for stateless ingestion on top of object storage is one of the most effective ways to lower operational burden in high-throughput infrastructure.

---

## [Random rotations enable calibration-free low-bit quantization on Apple silicon](https://github.com/pythongiant/mlx_turboquant)

**By:** pythongiant  
**Why read:** Learn how TurboQuant uses orthogonal random rotations to compress weights and KV caches without calibration data. It demonstrates a practical implementation optimized for Apple silicon using custom Metal kernels.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48816446)  

Quantizing KV caches for local LLM inference usually demands careful data calibration or suffers severe accuracy drops from coordinate outliers. TurboQuant introduces an elegant mathematical workaround that runs directly on Apple silicon.

The core mechanism relies on a Randomized Hadamard Transform. Rotating input vectors randomly across coordinate space distributes outliers evenly, converting skewed activation distributions into near-Gaussian marginals. Because orthogonal rotations strictly preserve inner products, attention scores calculated between queries and keys remain mathematically intact.

This implementation integrates directly with mlx-lm using a custom Metal kernel for non-uniform Lloyd-Max look-up tables alongside randomized rotations. It allows engineers to aggressively compress weight matrices and long-context KV caches without running offline calibration datasets.

For systems engineers optimizing on-device inference, structural mathematical transforms often beat brittle empirical tuning.

---

## [Self-reinforcing injections enable persistent control of self-evolving agents](https://arxiv.org/abs/2602.15654)

**By:** Xianglin Yang, Yufei He, Shuo Ji, Bryan Hooi, Jin Song Dong  
**Why read:** Read this to understand how untrusted web content can exploit agent memory mechanisms to maintain cross-session persistence and trigger unauthorized actions. You will gain a clear mechanistic mental model of vulnerabilities inherent in long-term memory architectures like sliding-window and retrieval-augmented systems.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48815301)  

Self-evolving LLM agents that persist memories across sessions introduce an insidious attack surface: memory injection persistence. When an agent summarizes web content and commits entries to its long-term memory, poisoned payloads can survive indefinitely and hijack downstream tool invocations.

Researchers formalized this as the Zombie Agent attack. Unlike single-turn indirect prompt injections that disappear when the context window clears, these payloads specifically craft their structure to survive sliding-window truncation and RAG semantic relevance filters. The poisoned memory entry masquerades as normal behavioral guidance, causing unauthorized tool calls across subsequent, completely benign sessions.

Securing stateful agents requires treating internal memory with the same distrust as raw user input. Simple similarity pruning or rolling windows will not protect persistent agent runtimes from self-reinforcing contamination.

---

## [Typed knowledge graphs eliminate language model memory hallucinations](https://github.com/anthropics/claude-code/issues/75291)

**By:** parrik  
**Why read:** Learn how structuring user memory as a typed graph with explicit fetch-before-cite constraints prevents language models from hallucinating past context.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48818581)  

Most LLM memory failures stem from treating past context as a flat blob of text rather than an auditable database. Feeding raw conversation history into prompts inevitably triggers drift, where the model invents plausible details about the user that never happened.

A proven solution models long-term memory as a typed graph with explicit provenance. Nodes represent concrete entities such as observations, interpretations, and forecasts. Edges explicitly define relationships like grounding, superseding, or counter-evidence. When the user updates a preference, the system creates a new node that supersedes the prior one with an exact timestamp rather than overwriting historical records.

The critical architectural constraint is a strict fetch-before-cite protocol. Search queries across the graph return only node identifiers and relationship edges, never the body text. The agent cannot cite an assertion without executing an explicit second tool call to fetch that specific node content.

Constraining the context harness stops hallucinations far more reliably than prompt engineering.

---

## [Backups protect against data loss rather than bad writes](https://explainanalyze.com/p/before-the-bad-write/)

**By:** rtolkachev  
**Why read:** Read this to understand why standard disaster recovery mechanisms fail when dealing with silent data corruption. You will learn why preserving raw input feeds and maintaining data provenance are critical for recovering from bad writes.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48818083)  

Database backup and replication architectures are designed for sudden loss, not for silent logical corruption. If a server crashes or a table is dropped, point-in-time recovery and warm replicas can restore state. However, when bad code silently corrupts data, that corruption replicates downstream within milliseconds and enters every snapshot.

Consider a real case where an ID truncation bug mapped high-value equipment to wrong rows. Every row was syntactically valid and passed schema checks, but every valuation downstream was contaminated. Because the issue was discovered forty days later, point-in-time recovery was useless: the retention window was fourteen days, and reverting forty days of production activity would destroy thousands of legitimate transactions.

Standard disaster recovery assumes that failures are fast and obvious. Logical corruption breaks this assumption completely. Replicas merely mirror the corruption, while write-ahead logs expire before discovery.

The only reliable recovery path in these scenarios is data provenance. If you do not retain immutable upstream raw events, you cannot replay history and excise corrupted writes without wiping legitimate work.

Your backup strategy must account for errors that go unnoticed for months.

---

## [Calling C functions from Go without using Cgo](https://github.com/ebitengine/purego)

**By:** eatonphil  
**Why read:** Learn how Purego enables direct invocation of C functions and shared libraries in Go without the overhead and toolchain dependencies of Cgo. It offers a practical look at implementing foreign function interfaces using dynamic linking and architecture-specific assembly stubs.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48820680)  

Cgo introduces substantial friction to the Go ecosystem by inflating compile times, breaking cross-compilation, and imposing measurable call-overhead penalties across goroutine stack boundaries.

Purego bypasses Cgo entirely by implementing foreign function interfaces directly through architecture-specific assembly stubs and dynamic library loader symbols like dlopen and dlsym. It provides runtime bindings on amd64 and arm64 targets without requiring an external C toolchain during build time.

The Go runtime can invoke external C functions directly by matching platform application binary interface rules inside handwritten assembly routines. This approach preserves fast Go compilation speeds while allowing binaries to link dynamically with native system libraries like libSystem on macOS or libc on Linux.

Removing Cgo from the build pipeline transforms cross-platform distribution from an operational headache into a standard Go build workflow.

---

## [Workload and scheduling variations drastically change database benchmark results](https://www.paradedb.com/blog/benchmarker-iteration)

**By:** James Blackwood-Sewell  
**Why read:** Read this to understand why single-run database benchmarks can be misleading and how workload distribution and open-loop scheduling expose dramatic performance gaps.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48815260)  

A database benchmark showing two engines within ten percent of each other can swing to a forty-seven times performance gap simply by changing the load test harness.

When testing ParadeDB against standard PostgreSQL full-text search on identical hardware and data, a single hardcoded term tested in a closed loop showed both backends performing within ten percent. The database cache hid the underlying index overhead because the exact same query kept hitting memory.

Once the workload shifted to rotate through forty different search terms, ParadeDB pulled ahead with twenty-nine times higher throughput. Switching further from a closed loop to a fixed-rate open-loop model caused the P99 latency gap to explode to forty-seven times under identical search volume.

Closed-loop benchmarks artificially mask queueing delays because the client waits for each response before dispatching the next request. Real traffic arrives independently of database completion times.

Benchmarking database engines without varying query terms and modeling open-loop arrival rates measures cache locality rather than production capability.

---

## [Observability data must be shaped before AI can consume it](https://ryantsuji.dev/posts/ai-observability-design)

**By:** Ryan Tsuji  
**Why read:** Learn why raw production telemetry overwhelms language models and how to systematically shape application, infrastructure, CI, and LLM monitoring data for AI consumption.  
**Discussion:** [HN Thread](https://news.ycombinator.com/item?id=48817455)  

Dumping unstructured telemetry directly into an LLM context window causes the same failure modes as passing an entire repository as raw text.

Production logs overwhelm attention mechanisms with volume and noise, obscuring root causes and driving hallucinations. Making a system truly observable to autonomous agents requires transforming high-volume operational metrics into pre-filtered, semantic representations before prompting.

In a mature architecture, this separation divides cleanly across telemetry layers. Application traces and logs flow through standard collectors into Loki and Tempo, but CI logs must be pulled on demand rather than pushed via webhooks to prevent saturation. Furthermore, model observability requires bifurcated telemetry: lightweight client-side cost estimates routed to Prometheus, alongside full LLM audit records ingested into BigQuery for complex SQL aggregation.

When you pre-aggregate time-series data and provide structured dynamic facts instead of raw log streams, agents diagnose system anomalies with substantially higher accuracy and lower token consumption.

Reliable agentic operations demand curated telemetry pipelines, not broader context windows.

---