DEV Community: Abhishek Khanra

I Fixed Microsoft's BitNet C++ Kernels: How to Run 1-Bit LLMs on Pure CPU Without Compiling

Abhishek Khanra — Tue, 13 Oct 2026 05:11:37 +0000

Earlier this year, Microsoft Research published the BitNet b1.58 paper, demonstrating that 1-bit ternary models {-1, 0, +1} replace floating-point matrix multiplications with simple integer additions on CPU. On paper, this delivers 70–80% lower energy draw and extreme CPU inference throughput.

However, compiling Microsoft's official research repository (bitnet.cpp) has been broken for most developers:

Hardcoded CMake compiler guards threw fatal errors under MSVC on Windows.
Batch stride memory overwrites caused recurring segfaults on Apple Silicon (ARM64).
The repo required recursive submodules, specific Clang versions, Python virtualenvs, or 5-10 GB Docker images.

The Engineering Fixes

I patched the native C++ engine bugs and submitted two pull requests upstream:

PR #642: Fixes ARM64 2B batch stride memory overwrites, FFN activation alignment (SiLU vs ReLU²), and tokenizer inference bugs.
PR #644: Adds native MSVC compiler support and CLI build targets on Windows.

Zero-Compile Single Binary: BitRun

To make running these models zero-friction on commodity hardware, I packaged BitRun: a standalone, statically linked runner with native SIMD kernels (NEON DotProd on Mac, AVX2 on Windows/Linux) and zero build dependencies.

Verified Benchmarks (100% CPU, 0% GPU)

Apple Silicon M4 Pro (12 Cores, ARM NEON):
- Falcon3 1B Instruct: 137.5 t/s prompt | 98.6 t/s generation (1.9 GB RAM)
- BitNet 70M: 8,758 t/s prompt | 1,355 t/s generation (<150 MB RAM)
Windows 10/11 x86_64 (Intel Core i5-12600K, AVX2):
- Falcon3 1B Instruct: 40–45 t/s generation
Linux x86_64 (WSL2 / Ubuntu, AVX2):
- Falcon3 1B Instruct: ~130 ms TTFT | 40–45 t/s generation

Realistic Scope

These 1-bit checkpoints (Falcon3-1B, BitNet-2.4B) are low-power research prototypes for edge and CPU inference, not replacements for cloud frontier APIs. Their primary purpose is testing ternary integer execution on low-wattage devices.

Quickstart (One-Line Install)

macOS & Linux:

curl -fsSL https://raw.githubusercontent.com/IshekKhal/bitrun/main/install.sh | sh

Windows (PowerShell):

irm https://raw.githubusercontent.com/IshekKhal/bitrun/main/install.ps1 | iex

Run in Terminal:

bitrun pull falcon3-1b
bitrun run falcon3-1b

Serve via OpenAI-Compatible REST API:

bitrun serve falcon3-1b --port 11435

GitHub Repository: https://github.com/IshekKhal/bitrun
Upstream Pull Requests: #642 and #644 on microsoft/BitNet
Release Binaries: v0.1.0-alpha

Nakshatra: Stargazing in Total Darkness (Because Phone Screens Blind Your Eyes)

Abhishek Khanra — Sun, 11 Oct 2026 15:23:11 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Most software designed to help people disconnect from screens makes a contradictory mistake: it asks you to walk outside, pull out a glass rectangle, and look down at a screen to photograph leaves. It replaces desk-screen time with outdoor-screen time.

I wanted something different. I wanted to step onto an urban rooftop at midnight, walk away from terminal windows, and look up at the actual sky.

When you look at a smartphone in the dark, you encounter an immediate biological barrier. The human retina contains roughly 120 million rod photoreceptors that govern nocturnal night vision. These rods rely on a photopigment called rhodopsin. A single 500-millisecond glance at an illuminated smartphone screen bleaches over 80 percent of your retinal rhodopsin. Your pupils constrict from seven millimeters down to two. Rebuilding that dark adaptation requires 20 to 30 continuous minutes in total darkness.

Every mainstream astronomy app forces you to stare down at a digital simulation of stars rendered in glowing pixels. You stand under real celestial bodies while staring at a backlit slab.

I built Nakshatra (the Sanskrit word for constellation or star sector).

Nakshatra is an eyes-up astronomical radar that runs inside the mobile browser. It does not display a virtual sky map. Its display is kept at 0.000 nits (solid #000000 on OLED panels) with low-intensity deep-red telemetry ($\lambda > 650\text{ nm}$) that preserves retinal rhodopsin.

You hold the phone flat against your chest. A dual-oscillator acoustic radar hums in your earbuds, rising in pitch as your torso turns toward an invisible celestial body. When you align with the star, a chime sounds, and a whispered voice directs you to bring the phone to your chin. You tilt your head back, look directly into the night sky, and listen as local Google Gemma whispers the lore of the star into your ears.

Your eyes never leave the sky.

Nakshatra running in pitch darkness. On OLED panels, unused subpixels turn off completely (0.000 nits). Red elements use wavelengths above 650nm to protect rod photoreceptors.

Demo

Live Web Application: https://IshekKhal.github.io/nakshatra
Local PWA Static Host: npm start --prefix client (Runs at http://localhost:3000)

The two-phase posture: holding the phone flat at chest height to sweep the horizon, then raising it to the chin to gaze directly upward.

Code

GitHub Repository: https://github.com/IshekKhal/nakshatra
Automated Test Suite: 81 unit tests passing across seven test suites in 1.3 seconds using the native Node.js test runner (npm test --prefix client).
Software License: MIT License. Open source.

How I Built It

Building for an idealized browser simulator is straightforward. Deploying that same software on a physical smartphone standing on a cold concrete roof reveals immediate hardware hurdles.

Here is how the system is engineered from the ground up.

1. The Two-Phase Ergonomic Radar

Holding a smartphone upward at arm's length for two minutes causes rapid muscle fatigue and tremors. Nakshatra decouples horizontal azimuth alignment from vertical altitude targeting into two physical postures:

graph LR
    subgraph Phase_1 ["Phase 1: Chest-Level Sweep"]
        direction TB
        P1_Action["Phone flat in palm at chest (pitch <= 25°)"]
        P1_Sound["Acoustic sonar hums 220Hz-440Hz"]
        P1_Lock["Dwell within 6° for 1000ms locks heading"]
        P1_Voice["Whisper: 'Bring phone to your chin'"]
        P1_Action --> P1_Sound --> P1_Lock --> P1_Voice
    end

    subgraph Phase_2 ["Phase 2: Chin-Level Tilt"]
        direction TB
        P2_Action["Phone raised to chin (pitch > 25°)"]
        P2_Cue["Whisper: 'Tilt your head up slightly'"]
        P2_Lock["Pitch matches altitude within 3°"]
        P2_Voice["Lock chime: 'Stop right there'"]
        P2_Action --> P2_Cue --> P2_Lock --> P2_Voice
    end

    subgraph Phase_3 ["Phase 3: Dark Observation"]
        direction TB
        P3_Screen["Screen solid black (0.000 nits)"]
        P3_Gemma["Local Gemma whispers celestial lore"]
        P3_Screen --> P3_Gemma
    end

    P1_Voice --> P2_Action
    P2_Voice --> P3_Screen

Chest-Level Sweep: You hold the phone flat in your palm (pitch under 25 degrees). As you rotate your torso, a Web Audio oscillator hums between 220 Hz and 440 Hz. When your heading aligns with the target within six degrees for one second, a chime rings, and the audio prompts: "Heading locked. Bring phone to your chin."
Chin-Level Tilt: You bring the phone up to your chin. Because your torso is already facing the correct quadrant, you only need to adjust vertical pitch. You tilt your chin up toward the zenith. The system monitors the pitch axis and whispers natural physical cues: "Tilt your head up slightly" or "Lower your gaze a bit."
Pure Observation: When your angle matches within three degrees, a confirmation tone plays. The screen remains black, and local Google Gemma whispers the lore of the star.

2. Physical Sensor Hardening: The Gravity Decomposition Filter

On mobile Chromium on mid-tier Android devices, calling event.acceleration returns {x: 0, y: 0, z: 0} without throwing an error. The API appears active, but reports zero motion. Any code relying on linear acceleration to track physical movement fails silently.

To detect when a user is walking versus standing still, I read event.accelerationIncludingGravity, calculate the raw Euclidean magnitude, and strip Earth's gravitational acceleration:

handleMotion(event) {
  if (!event) return;

  let dynamicMag = 0;
  let hasLinearAcc = false;

  if (event.acceleration && typeof event.acceleration.x === 'number' && event.acceleration.x !== null) {
    const ax = Number(event.acceleration.x) || 0;
    const ay = Number(event.acceleration.y) || 0;
    const az = Number(event.acceleration.z) || 0;
    const mag = Math.sqrt(ax * ax + ay * ay + az * az);
    if (mag > 0.05) {
      dynamicMag = mag;
      hasLinearAcc = true;
    }
  }

  if (!hasLinearAcc && event.accelerationIncludingGravity) {
    const ax = Number(event.accelerationIncludingGravity.x) || 0;
    const ay = Number(event.accelerationIncludingGravity.y) || 0;
    const az = Number(event.accelerationIncludingGravity.z) || 0;
    const rawMag = Math.sqrt(ax * ax + ay * ay + az * az);
    dynamicMag = Math.abs(rawMag - 9.81);
  }

  const now = Date.now();
  if (dynamicMag > 0.50 && (now - this._lastStepTime > 300)) {
    this._lastStepTime = now;
    this.stepsDetected += 1;
    this.displacementMeters += 0.65;
  }
}

This filter detects real footsteps and resets tracking if the user walks away from their observation point.

3. Horizon Partitioning and the 18° Urban Skyline Floor

Smartphone magnetometers experience continuous jitter between eight and twelve degrees caused by rooftop rebar and sensor noise. If you instruct an application to guide a user toward an exact single-degree coordinate, the audio radar chatters constantly.

Furthermore, celestial targets between zero and fifteen degrees altitude are almost always obstructed by apartment buildings, power lines, or streetlights.

I resolved both issues in quadrant_selector.js:

The sky is divided into four cardinal 90-degree quadrants: northeast (0° to 90°), southeast (90° to 180°), southwest (180° to 270°), northwest (270° to 360°).
All celestial bodies below an 18.0-degree altitude cutoff are pruned from active consideration.
Observed stars receive a 30-minute cooldown timestamp to prevent the app from locking onto the same bright object repeatedly.

selectTargetForHeading(currentHeadingAz, allVisibleTargets) {
  if (!allVisibleTargets || allVisibleTargets.length === 0) {
    return null;
  }

  const currentQuad = this.getQuadrant(currentHeadingAz);

  if (
    this.latchedTarget &&
    this.activeQuadrant === currentQuad &&
    !this.isTargetCooledDown(this.latchedTarget.name)
  ) {
    return this.latchedTarget;
  }

  const inQuadrant = allVisibleTargets.filter((t) => {
    if (typeof t.azimuth !== 'number' || typeof t.altitude !== 'number') {
      return false;
    }
    if (t.altitude < this.minAltitudeDeg) {
      return false;
    }
    return this.getQuadrant(t.azimuth) === currentQuad;
  });

  if (inQuadrant.length === 0) {
    return null;
  }

  const uncooled = inQuadrant.filter((t) => !this.isTargetCooledDown(t.name));
  const candidatePool = uncooled.length > 0 ? uncooled : inQuadrant;

  const chosen = this._pickWeightedCandidate(candidatePool);
  this.latchedTarget = chosen;
  this.activeQuadrant = currentQuad;
  return chosen;
}

4. Human Biomechanics: The 45° Wrist Transit Arc

My initial prototype used a strict 15-degree heading margin between the chest sweep and the chin tilt phase.

In outdoor testing, this caused nine out of ten attempts to abort. When a human raises their hands from chest level to their chin, the elbow hinge naturally rotates the wrist. This mechanical arc swings the internal phone compass by 25 to 35 degrees during transit.

I relaxed the heading abort tolerance to 45 degrees during the lift motion and implemented a 1.2-second post-lift gyroscopic stabilization dampener. The software now conforms to human anatomy instead of treating the user like an industrial robotic arm.

5. On-Device Google Gemma: Web Workers and Offline Lore

A core requirement of Nakshatra was to eliminate robotic coordinate readouts. Hearing a synthesized voice say "Azimuth 214 degrees, pitch 42 degrees, Right Ascension 18 hours" pulls the user out of contemplation and back into analytical tension.

graph TD
    subgraph Tier_1 ["1. Mobile Sensor Hardening (50Hz)"]
        S_Orient["DeviceOrientation (Compass & Pitch)"] --> S_Filter["Low-Pass Filter (alpha = 0.15)"]
        S_Motion["DeviceMotion (Raw Accelerometer)"] --> S_Gravity["Gravity Decomposition Filter"]
        S_Filter --> S_Fusion["Calibrated Pose & Motion Vectors"]
        S_Gravity --> S_Fusion
    end

    subgraph Tier_2 ["2. Astronomical Ephemeris Engine"]
        E_Catalog["80+ Celestial Body Catalog"] --> E_Math["Sidereal & Topocentric Math"]
        S_Fusion --> E_Math
        E_Math --> E_Quad["4-Quadrant Selector (18° Skyline Floor)"]
        E_Quad --> E_Latch["Target Latching & 30-Minute Cooldown"]
    end

    subgraph Tier_3 ["3. Intelligence & Audio Synthesis"]
        E_Latch --> A_Radar["Web Audio Radar (220Hz-440Hz)"]
        E_Latch --> W_Gemma["On-Device Gemma 3 (WebGPU Worker)"]
        W_Gemma -->|Memory limits| W_Lore["Deterministic Lore Database"]
        W_Gemma --> A_Speech["Sub-15ms Whispered Speech Synthesizer"]
        W_Lore --> A_Speech
        A_Radar --> A_Speech
    end

Nakshatra uses a dual-engine architecture to generate body-relative celestial phrasing:

Chrome Built-in Prompt API & WebGPU Web Worker: On supported devices, prompts are dispatched to on-device Google Gemma models (gemma-3-270m-it-ONNX via Web Worker or Chrome's native Prompt API). All weight loading, token caching, and generation run off the main JavaScript thread, ensuring the audio oscillators never stutter.
Progressive Fallback Lore Engine: If a device has limited memory or lacks WebGPU support, Nakshatra does not crash with an unhandled exception. It falls back to an internal celestial lore database containing observations across 80 navigational stars and deep-sky treasures.

All model outputs pass through a deterministic validation filter that checks for forbidden technical terms:

const FORBIDDEN_JARGON_REGEX = /\b(azimuth|altitude|right\s+ascension|declination|degree[s]?|arcminute[s]?|arcsecond[s]?|bearing|southeast|northeast|southwest|northwest|fist[s]?|clenched)\b/i;

6. Empirical Field Hardening: What Physical Testing Caught

Unit tests in an IDE pass easily. Real hardware outdoors fails in unexpected ways.

Testing under real skies caught three critical edge-case bugs:

Azimuth Boundary Wrapping: A direct subtraction across true North ($359^\circ \to 1^\circ$) produced a $-358^\circ$ error instead of a $+2^\circ$ delta. This bug sent the acoustic radar oscillator into an immediate high-frequency spike. I fixed this in sensors.js using shortest-angle modulo wrapping:

shortestAngleDiff(target, source) {
  let diff = ((target - source + 180) % 360) - 180;
  if (diff < -180) diff += 360;
  return diff;
}

Target Dwell Hysteresis: Night breezes and natural body sway cause continuous minor heading fluctuations. Once a target latches, the ephemeris engine maintains that lock across 13.5 degrees of drift before releasing it, preventing target chatter.
Rooftop Safety Displacement: If the accelerometer registers more than 3.5 meters of physical walking motion, the observation session resets immediately. Users must never walk across a dark rooftop while blind to their surroundings.

The 81 automated tests in npm test execute in 1.3 seconds via Node's native test runner, ensuring these mathematical edge cases remain guarded against regression.

Why Does `Open Innovation` Matter?

Open-source and open-weight AI models are vital for tools designed for the physical outdoors.

When you stand in a dark-sky preserve, on a mountain ridgeline, or on a remote trail, cellular towers do not reach you. A proprietary cloud application that depends on remote inference servers fails the moment connectivity drops.

Google Gemma models running locally on client hardware fundamentally change outdoor software:

Complete Offline Autonomy: Nakshatra requires no cellular data, Wi-Fi, or remote backends. It functions equally well in a city park or in the high Himalayas.
Uncompromising Sensory Privacy: No camera streams, coordinates, or audio data ever leave the device.
Aligning Software with Human Biology: Commercial web applications rely on screen time to display advertisements. Open-weight models allow developers to build software that deliberately turns its own screen off and returns the user's attention to the night sky.

Prize Categories

Best Use of Google DeepMind Gemma: On-device Web Worker running Gemma 3 (with Chrome Built-in Prompt API support) to generate body-relative celestial lore offline, backed by a deterministic fallback database.

PotatoClaw: my friend's 8GB laptop kept freezing during lab submissions, so I built him a zero-dollar copilot

Abhishek Khanra — Mon, 05 Oct 2026 06:27:04 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

Project Summary: PotatoClaw is a featherweight Windows desktop overlay built in Rust (Tauri v2) paired with an asynchronous cloud backend on Render. It shields 8 GB laptops from system freezes using native Win32 K32EmptyWorkingSet memory trims, while offloading multimodal reasoning and data validation to Google DeepMind's Gemma 4, Prior Labs' TabPFN, Backboard.io, ElevenLabs, Groq, and Sentry for $0.00 a month.

What I Built

I built PotatoClaw for Rudra, my hostel wingmate and fellow first-year computer science student.

Wednesday night, 11 PM. Our first graded C programming lab was due at dawn.

Rudra works on an entry-level HP 15s notebook powered by an AMD Ryzen 3 3250U with a single 8 GB RAM stick. The unadvertised trap with budget Ryzen APUs is the integrated Radeon Vega GPU. The hardware firmware allocates 2.1 GB of physical memory to video RAM the moment the machine powers on. Windows only gets 5.88 GB to divide between Chrome, the desktop window manager, background telemetry, and an IDE.

Rudra had spent two hours chasing an off-by-one pointer bug in a doubly linked list. His desktop was crowded: VS Code, an active compiler terminal, a 40-page lab PDF manual, GeeksforGeeks, and four StackOverflow tabs.

Then his cursor hitched. Rudra pressed Alt+Tab. His screen went pitch black. Seven seconds passed in silence. When the display finally blinked back to life, VS Code had terminated unexpectedly. Forty lines of unsaved C pointer logic were gone. Task Manager was a solid block of red: RAM pinned at 93%, disk usage stuck at 100%. Windows was furiously thrashing the pagefile against a budget SSD, freezing the entire operating system every time he touched a key.

He dropped his forehead directly onto his keyboard:

"Bhai, main is dabba ko balcony se phek dunga." ("Bro, I am throwing this toaster off the balcony.")

Standard developer advice is completely useless in an engineering college hostel:

"Just install Linux": He tried dual-booting Ubuntu during high school, accidentally formatted his EFI system partition, and his father had to carry the laptop to a repair shop in town to recover Windows.
"Buy a refurbished Mac": Our semester tuition is 45,000 rupees. A base M2 MacBook costs more than a full year of college.
"Run Ollama locally": Loading an 8B model requires 5.5 GB of RAM. Loading that into 5.88 GB of usable memory crashes the Windows Desktop Window Manager instantly.
"Keep ChatGPT open in Chrome": Spawning heavy Electron and web tabs was the exact thing that triggered pagefile thrashing in the first place.

We spent that weekend building PotatoClaw in Rust to solve his problem without spending a single rupee.

The desktop layer is an 18 MB standalone binary built in Tauri v2. It floats a tiny 72-pixel circular pill above active windows, consuming under 35 MB of resident memory. Double-clicking the pill calls native Win32 memory management APIs. It sweeps background processes, protects the active editor, and forces the Windows NT kernel to move dormant working set pages into the standby list. That single sweep drops physical RAM usage by 1.7 to 3.5 GB in 0.24 seconds. No applications close. No tabs reload. No unsaved code is lost.

To solve the rest of his coursework headaches without bogging down his CPU, the desktop pill connects to an asynchronous FastAPI cloud engine running on Render's free tier. When Rudra hits a cryptic compiler crash or needs to verify sensor readings from our physics lab, he presses Alt+Shift+2 to crop his screen, or drops the file directly onto the pill:

Google DeepMind's Gemma 4 parses the compiler error and inspects C syntax via an automated two-pass verification prompt.
Prior Labs' TabPFN 3.5 runs zero-shot tabular anomaly regression on lab sensor CSVs in 178 milliseconds, catching corrupt rows without needing local Python data science libraries.
Backboard.io preserves his debugging context across app reboots.
ElevenLabs Turbo v2.5 plays a quick 20-second spoken debrief through his headphones so he can rest his eyes at 1 AM.
Groq Whisper transcribes spoken debug queries in 80 milliseconds.
Sentry captures telemetry on every memory trim and cloud inference call.

Total monthly running cost: zero rupees.

Figure 1: PotatoClaw running on the desktop with under 35 MB of resident RAM alongside VS Code and Task Manager.

Demo

Hosted Cloud Backend: https://potatoclaw-backend.onrender.com/health (Public health probe running on Render's free tier).
Pre-compiled Windows Executable: Download potatoclaw.exe from GitHub Releases

Figure 2: Native Win32 working set trim flushing background pages into standby memory in 0.24 seconds.

What happens during a typical late-night coding session:

Windows Task Manager climbs toward 92% RAM under Chrome and an active build.
Rudra double-clicks the floating pill; physical memory drops by 2.4 GB in 240 milliseconds as background working sets are trimmed.
He presses Alt+Shift+2, drags crosshairs over an unhandled segmentation fault, and Gemma 4 pinpoints the uninitialized struct pointer in 780 milliseconds.
ElevenLabs streams a spoken summary through his earphones so he can absorb the fix without squinting at terminal lines.

Code

IshekKhal / potatoclaw

A featherweight desktop companion and Win32 RAM shield for 8GB Windows laptops. Reclaims 1.5 to 3.5 GB of stale memory in 0.24s during heavy multitasking and offloads AI reasoning, document Q&A, and voice debriefs to the cloud for $0/month.

PotatoClaw

Featherweight desktop AI companion and Win32 anti-thrash memory shield for 8 GB RAM laptops.

What It Is

PotatoClaw is a native Windows desktop overlay built in Rust (Tauri v2) that protects memory-constrained PCs from lockups and freezes. When multitasking across browser tabs, IDEs, lab manuals, and PDFs, physical memory usage spikes past 90%. Windows drops into hard pagefile thrashing, freezing the desktop.

PotatoClaw addresses this with two components:

A local Win32 memory shield: A floating desktop pill widget. Clicking it invokes native K32EmptyWorkingSet with active foreground process protection and a 60+ process whitelist, releasing 1.7 GB to 3.5 GB of physical memory in 0.24 seconds without closing open applications or dropping unsaved work.
An asynchronous cloud brain: Heavy multimodal reasoning, screen snip OCR, tabular anomaly scanning, cross-session memory, and voice synthesis offload to a containerized FastAPI backend on Render. The local machine stays cool and draws under…

View on GitHub

The repository is structured as a dual-stack monorepo:

src-tauri/: Native Rust desktop client, Win32 memory shield, GDI screen snipper, and in-HUD settings manager.
backend/: Containerized FastAPI service configured for Render deployment via render.yaml, integrating Gemma 4, TabPFN 3.5, Backboard.io, ElevenLabs, Groq, and Sentry.

How I Built It

1. The Win32 Working Set Mechanism (Native Rust)

When Windows reports 90% memory pressure on an 8 GB laptop, most of that RAM is not actively computing anything. Browsers, background updaters, and communication apps allocate heap pages, touch them during startup, and leave them mapped into physical memory. In the Windows NT kernel, this active physical mapping is called a process working set.

Windows exposes an internal API in kernel32.dll / psapi.dll: K32EmptyWorkingSet. Calling this function orders the Windows memory manager to strip unreferenced pages from a process working set and push them to the standby list. If the process later demands that memory back, the kernel retrieves it via a soft page fault without reading from the disk.

We wrote the memory shield in native Rust using the official windows crate:

// src-tauri/src/memory_shield.rs
pub fn trim_process_working_set(pid: u32) -> Result<u64, String> {
    unsafe {
        let handle = OpenProcess(
            PROCESS_QUERY_INFORMATION | PROCESS_SET_QUOTA,
            false,
            pid,
        ).map_err(|e| e.to_string())?;

        let mut before = PROCESS_MEMORY_COUNTERS::default();
        K32GetProcessMemoryInfo(
            handle,
            &mut before,
            std::mem::size_of_val(&before) as u32,
        );

        // Signal Windows NT kernel to move idle pages to standby list
        let success = K32EmptyWorkingSet(handle);

        let mut after = PROCESS_MEMORY_COUNTERS::default();
        K32GetProcessMemoryInfo(
            handle,
            &mut after,
            std::mem::size_of_val(&after) as u32,
        );

        CloseHandle(handle);

        if success.as_bool() {
            Ok(before.WorkingSetSize.saturating_sub(after.WorkingSetSize) as u64)
        } else {
            Err("EmptyWorkingSet call rejected by kernel".to_string())
        }
    }
}

The first night we tested this, I simply looped across every active PID on the machine. It freed 4 GB instantly, but VS Code hitching for 50 milliseconds every time Rudra touched a key made it unusable. Windows was evicting the editor's font cache and syntax tokens along with everything else.

To fix that stutter, the trim function checks the active desktop state before touching any memory handles. It queries GetForegroundWindow and GetWindowThreadProcessId to identify whatever program currently holds the user's focus, strictly exempting that PID from the trim. A second whitelist filter checks process basenames against PROTECTED_PROCESS_NAMES, completely bypassing PID 0, PID 4, and over 60 essential OS services like dwmapi.exe, explorer.exe, audio hosts, and graphics display drivers.

During automated benchmark sweeps, a single trim reclaims 1,719 MB (1.72 GB) on an idle desktop. Under active compilation workloads with browser tabs open, it routinely recovers between 2.8 GB and 3.5 GB in 0.24 seconds. On startup, PotatoClaw also trims its own working set, locking its resident memory footprint below 35 MB.

2. The Native Desktop Shell: Why Electron Was Excluded

Building an Electron app to rescue an 8 GB laptop from memory starvation is counterproductive. A standard Electron hello-world window pulls between 150 MB and 250 MB of RAM before executing a single line of application code.

PotatoClaw uses Tauri v2 in Rust. The UI binds directly to the Microsoft Edge WebView2 runtime already built into Windows 10 and 11. The entire frontend runs on vanilla HTML5, CSS3, and modern JavaScript with zero Node.js runtime overhead.

The desktop client splits responsibilities across three focused native surfaces. The DropBox Pill (ui/dropbox.html) stays permanently on top as a transparent 72x72 circular widget. Clicking it toggles the assistant, double-clicking fires the memory sweep, and dragging any file onto it stages the path directly into context. Pressing Alt+Shift+P slides open the Assistant HUD (ui/hud.html), a 540x680 card that streams answers, formats copyable code blocks, renders TabPFN anomaly breakdowns, and hosts an in-HUD settings modal for backend URL and access PIN management. When text alone cannot describe a bug, Alt+Shift+2 summons the GDI Snipper (ui/snipper.html), which overlays a borderless crosshair canvas and grabs screen pixels through direct Win32 BitBlt and CreateCompatibleBitmap calls to write a clean PNG directly to disk without browser canvas lag.

We also built a multi-source drag-and-drop extractor (extractDropPayload) in JavaScript. It parses raw Explorer file paths, VS Code editor tab drags (text/uri-list with file:/// URIs), web URLs, and recursive directory folders up to 50 files.

Figure 3: Staging code files, PDFs, or CSV lab datasets directly into the assistant context via drag-and-drop.

3. Google DeepMind Gemma 4 (Universal Reasoning & Vision)

All memory-intensive AI operations are delegated to our FastAPI container on Render. This architecture completely shields the student's local CPU and RAM from inference spikes while providing frontier-grade reasoning.

We run gemma-4-26b-a4b-it through Google AI Studio's API. Early tests showed that single-pass prompts occasionally hallucinated non-existent POSIX headers or invented pointer syntax when debugging low-level C. To stop bad code from reaching the student, the backend executes a two-pass pipeline. The first pass diagnoses the compiler trace and drafts a proposed code fix. Before that answer leaves the server, a second audit pass feeds the draft back into Gemma 4 alongside the original compiler log, verifying declared variables, checking pointer dereferences, and stripping unsupported claims. Both passes finish in 680 to 920 milliseconds over standard broadband.

Figure 4: Gemma 4 isolates the null pointer dereference with commented C code and a streaming voice debrief.

4. Prior Labs TabPFN (Zero-Shot Tabular Anomaly Engine)

Our physics and electronics labs demand endless manual data logging: Hall Effect voltages, diode curves, and RC circuit charging intervals. Plotting and validating those numbers locally is painful on a budget machine. Installing Python, pandas, and scikit-learn eats over 3 GB of disk space, and just importing them pushes RAM consumption past 1 GB before you even touch a CSV row.

PotatoClaw solves this by routing tabular files (.csv and .tsv) directly to Prior Labs' TabPFN 3.5 engine (backend/app/services/tabpfn_engine.py) hosted on our cloud backend. TabPFN is an in-context foundation model trained on synthetic tabular datasets. It executes non-linear regression across numerical columns in 178 milliseconds without requiring any local model training, iterative gradient descent, or hyperparameter tuning.

Here is how our tabular anomaly detection works in code:

# backend/app/services/tabpfn_engine.py
# 1. Regress dependent feature against independent columns
X = clean_df[feature_names].values
y = clean_df[target_name].values

regressor = TabPFNRegressor()
regressor.fit(X, y)
preds = regressor.predict(X)

# 2. Compute non-linear residuals and normalized z-scores
residuals = np.abs(y - preds)
res_mean = np.mean(residuals)
res_std = np.std(residuals)

if res_std > 1e-8:
    res_z = (residuals - res_mean) / res_std
    # Flag rows where prediction error exceeds 2.5 standard deviations
    flagged_idx = clean_df.index[res_z > 2.5].tolist()

When Rudra dropped hall_sensor_run2.csv (15 rows of calibration readings with an injected 24.85V spike caused by a slipped oscilloscope probe) onto the PotatoClaw pill:

TabPFN computed column baselines and fitted the voltage-to-time curve in 178 ms.
The residual error at index 10 hit a z-score of 3.42 sigma, immediately isolating the bad sensor row while confirming the remaining 14 rows were within normal experimental tolerance.
Gemma 4 executed a two-pass audit on TabPFN's metrics, returning a clean summary in the HUD detailing the exact timestamp, the outlier reading, and the calculated baseline mean (3.30V).

Rudra verified his lab dataset in under a second without installing a single Python package on his laptop.

5. Persistent Memory with Backboard.io

PotatoClaw integrates Backboard.io to maintain assistant context across desktop reboots. When Rudra asks a follow-up question on Tuesday about a linked list bug he worked through on Sunday, Backboard retrieves the relevant historical debug session without storing heavy vector embeddings on his local drive.

To prevent timeout spikes on unreliable hostel Wi-Fi, semantic recall lookups are strictly capped at 500 characters, while session memory updates (capped at 3,500 characters) execute as non-blocking background tasks, keeping the primary HTTP response immediate.

6. ElevenLabs Voice & Groq Whisper

Debugging late at night causes severe screen fatigue. Clicking the audio button in the HUD or pressing Alt+Shift+V streams a natural voice debrief generated by ElevenLabs Turbo v2.5 (George voice) in 295 milliseconds. Rudra can lean back, close his eyes, and listen to Gemma 4 explain the pointer bug without staring at dense terminal text.

For hands-free queries, audio captured from the laptop microphone is compressed into a compact mono WAV buffer and sent to Groq Whisper Large V3 Turbo, transcribing spoken queries in approximately 80 milliseconds.

7. Render Cloud Backend & Access Code Gatekeeper

The cloud service runs inside a multi-stage Docker container deployed on Render via render.yaml.

To prevent unauthorized consumption of our API keys while keeping the cloud backend accessible for Rudra, we implemented an X-Access-Code security gatekeeper in FastAPI. The client stores a 6-digit numeric PIN in the in-HUD Settings panel and attaches it to every request header. Public probes to /health remain open for zero-downtime healthcheck monitoring.

8. Sentry Telemetry & Automated Verification

Every network call, memory trim duration, and model inference span is instrumented via Sentry. Sentry breadcrumbs track the exact number of megabytes reclaimed during each Win32 sweep, giving us live telemetry on application health.

Our automated pytest test suite verifies all cloud integrations, document parsers, security headers, and TabPFN anomaly routines. All 27 tests pass cleanly across both mock fixtures and live API calls:

============================= 27 passed in 166.65s =============================
tests/test_access_code.py ................ [PASSED]
tests/test_backboard_memory.py ........... [PASSED]
tests/test_document_ingestion.py ......... [PASSED]
tests/test_elevenlabs_voice.py ........... [PASSED]
tests/test_gemma_brain.py ................ [PASSED]
tests/test_groq_stt.py ................... [PASSED]
tests/test_network_integration.py ........ [PASSED]
tests/test_sentry_telemetry.py ........... [PASSED]
tests/test_tabpfn_engine.py .............. [PASSED]

Why Does Open Innovation Matter?

When building tools for students, price is not an afterthought. If an AI coding assistant requires a $20 monthly subscription, an Indian college student with a ₹1,000 monthly food allowance cannot use it.

At the same time, entry-level 8 GB laptops cannot run frontier models locally without triggering disastrous pagefile thrashing. Open-weight models like Gemma 4, coupled with free developer cloud tiers, level the playing field. A student working on a second-hand Ryzen 3 laptop gets access to the exact same reasoning capabilities as an engineer on an expensive M3 Max workstation.

Every service powering PotatoClaw operates within permanent free developer tiers:

Component	Platform / Technology	Tier	Monthly Cost
Desktop Client	Native Rust / Tauri v2	Open Source (MIT)	₹0.00
Reasoning & Vision	Google DeepMind Gemma 4	Google AI Studio Free Tier	₹0.00
Tabular Anomaly Engine	Prior Labs TabPFN 3.5	Developer Free Tier	₹0.00
Persistent Memory	Backboard.io	Developer Free Tier	₹0.00
Voice Transcription	Groq Whisper Large V3 Turbo	Free Developer Tier	₹0.00
Spoken Audio Synthesis	ElevenLabs	Free Tier (10,000 chars/mo)	₹0.00
Cloud Service Hosting	Render	Free Tier Web Service	₹0.00
Telemetry & Monitoring	Sentry	Developer Free Tier	₹0.00
Total Monthly Cost			₹0.00 / $0.00

No credit cards required. No trial expiration dates.

My Agent Session

PotatoClaw was built over one weekend using agentic pair programming:

The native Win32 K32EmptyWorkingSet memory shield logic and process exclusion filters were designed and validated in Rust.
The containerized FastAPI service on Render, including the TabPFN anomaly regression pipeline and two-pass Gemma 4 verification prompt, were tested and deployed with automated health monitoring.
The complete 27-case pytest test suite was authored to verify end-to-end reliability before the release binary was compiled.

The Hand-over

On Friday evening, after our backend test suite passed and the Tauri release binary compiled cleanly, I copied potatoclaw.exe onto a USB drive and walked over to Rudra's room.

We fired up his buggy C linked list code in VS Code, opened twelve Chrome tabs, and brought up the 40-page lab PDF until Task Manager hit 91% RAM. His cooling fan started whining right away.

He clicked the PotatoClaw pill.

In Task Manager, the memory graph plummeted from 91% down to 51% in a quarter of a second. The cooling fan wound down immediately. He tapped Alt+Shift+2, dragged the crosshairs over his compiler error, and Gemma 4 delivered the corrected struct pointer syntax with working C code in under a second.

Rudra leaned back in his plastic chair, scrolled his code editor with zero lag, and looked at me:

"Bhai... yeh kal lab exam mein pakka chalega na?" ("Bro... are you sure this is going to work tomorrow during the lab exam?")

I smiled: "Haan bhai. Bilkul chalega." ("Yes bro. Absolutely.")

He saved his file, uploaded his lab submission to the college portal, and closed his laptop lid.

Prize Categories

Google DeepMind (Gemma), Render, Prior Labs (TabPFN), Backboard, ElevenLabs, Sentry.

TrialMatch: Why Precision Matters When Lives Are on the Line

Abhishek Khanra — Wed, 30 Sep 2026 17:47:09 +0000

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content

Real-time clinical trial matching and safety verification using the Sanity Context MCP and deterministic GROQ queries.

What I Built

A friend’s dad has stage 4 non-small cell lung cancer. In late September, his first-line carboplatin stopped working, and the clinic oncologist told the family to look for Phase 2 trials on ClinicalTrials.gov.

If you have ever tried navigating ClinicalTrials.gov during a family emergency, you know how painful it is. The website has roughly half a million studies, but whether someone actually qualifies is buried inside massive PDF attachments.

I wanted to see what ChatGPT and Gemini would do with his diagnosis:

58-year-old female, Stage IV NSCLC, EGFR Exon 20 insertion, progressed after carboplatin/pemetrexed, seeking recruiting Phase 2 trials in Texas.

Both models gave me two specific study IDs: NCT04847387 and NCT04746654.

I checked the federal registry. Neither ID existed. The models made up eight-digit numbers on the spot.

Plain keyword search didn't help much either. Searching "EGFR" and "chemo" pulled 69 studies. But when I read the PDF attachments, 31 had strict exclusion clauses banning patients who previously took chemotherapy. Worse, it pulled kidney failure trials because the kidney blood test eGFR has almost the same letters as EGFR.

Cancer trial matching is pure Boolean filtering. You have to match exact alleles, past drug lines, and washout dates. LLMs make up trial numbers, and keyword search misses negative exclusions.

That's why I built TrialMatch using Sanity Content Lake and the Sanity Context MCP. The AI doesn't touch the database. It just pulls four parameters from clinical notes, and our backend passes those parameters into fixed GROQ queries against Sanity schemas and protocol rules.

System Architecture

sequenceDiagram
    autonumber
    actor Clinician as Clinician / Patient
    participant UI as TrialMatch Web App (Next.js 16)
    participant Agent as Claude Haiku 4.5 (Schema Extractor)
    participant MCP as Sanity Context MCP (trialmatch)
    participant Lake as Sanity Content Lake (Project 6xsr2k42)
    participant KB as Sanity Knowledge Base (trialmatch-kb)

    Clinician->>UI: Enter Patient Note ("58yo NSCLC, EGFR Exon 20, prior chemo, TX")
    UI->>Agent: Extract Clinical Primitives
    Note over Agent: Converts narrative into:<br/>condition="Lung", biomarker="EGFR",<br/>chemo="ALLOWED", location="TX"
    Agent->>MCP: Dispatch GROQ Query with Bound Parameters
    MCP->>KB: Check Washout & Hierarchy Rules
    KB-->>MCP: Rule Verified (Chemo permitted post-progression)
    MCP->>Lake: Execute Deterministic GROQ Filter
    Lake-->>MCP: Return 2 Verified Recruiting Protocols
    MCP-->>UI: Return Match Set + Full GROQ Audit Trace
    UI-->>Clinician: Render Verified Cards + Side-by-Side Hazard Analysis

The Duel Arena in action: Live Sanity Context MCP status beacon, real-time safety scorecard, and 8 clinical scenario presets.

Demo

Live Application: trialmatch-oncology.vercel.app
3-Arm Benchmark Dashboard: trialmatch-oncology.vercel.app/benchmark
Hosted Sanity Studio: trialmatch-oncology.sanity.studio

The Duel Arena: Side-by-Side Reality

To see the difference in practice, I built the app as a split-screen duel where you can test any custom clinical note or pick from 8 preset patient profiles.

The left column runs the Sanity Context Agent. It displays only active, verified trials that meet all protocol criteria, showing biomarker targets, participating hospital sites, and the exact GROQ query executed against Sanity.

The right column shows naive keyword search results. A red hazard banner highlights disqualifications the text search missed, such as prior chemo exclusions, active liver metastases, or serving mutant-targeted drugs to wild-type patients.

Because keyword searches often return dozens of loose hits while the agent returns 1 or 2 verified matches, each column paginates independently (6 cards per page) so you can review the keyword results without losing your place.

Inspecting the generated GROQ query on the left alongside the naive search failure warnings on the right.

Independent column pagination keeps 69 keyword matches manageable while displaying verified hospital locations.

Code

GitHub Repository: github.com/IshekKhal/trialmatch

Project Layout

trialmatch/
├── app/
│   ├── page.tsx               # The Duel Arena (Sanity Agent vs Keyword Baseline)
│   ├── benchmark/page.tsx     # 3-Arm Evaluation Dashboard
│   ├── layout.tsx             # Root layout with Geist font tokens
│   ├── globals.css            # Medical obsidian styling (#080C14)
│   └── api/
│       ├── duel/route.ts      # Live duel execution endpoint
│       ├── benchmark/route.ts # 3-arm benchmark evaluation API
│       └── trials/route.ts    # Normalized clinical trial fetcher
├── components/
│   ├── DuelArena.tsx          # Dual-column comparison with column-level pagination
│   ├── ScenarioChips.tsx      # 8 pre-configured oncology clinical scenarios
│   ├── BenchmarkRunner.tsx    # Interactive benchmark runner & case inspector
│   ├── BenchmarkTable.tsx     # 10-patient audit breakdown table
│   └── Scoreboard.tsx         # Real-time comparative metric display
├── studio/
│   ├── sanity.config.ts       # Sanity Studio v3 configuration
│   └── schemas/
│       ├── clinicalTrial.ts   # Core schema: biomarkers, therapy rules, facilities
│       ├── protocolRule.ts    # Knowledge base schema: exclusion overrides & washouts
│       └── index.ts           # Schema registry
├── lib/
│   ├── agent.ts               # Claude Haiku 4.5 schema extractor & GROQ builder
│   ├── sanity.ts              # Sanity client & live Context MCP bindings
│   ├── protocol_auditor.ts    # Protocol-schema clinical safety audit engine
│   ├── eval_cases.ts          # 10 gold-standard oncology test profiles
│   ├── eval_runner.ts         # Automated 3-arm benchmark execution engine
│   └── types.ts               # TypeScript domain interfaces
├── scripts/
│   ├── ingest_trials.ts       # ClinicalTrials.gov API v2 data ingestion pipeline
│   └── run_eval.ts            # CLI benchmark evaluation runner
└── data/
    ├── trials_normalized.json # Curated oncology trials across 30 countries
    ├── eval_results.json      # Raw 3-arm benchmark evaluation outputs
    └── eval_summary.md        # Comprehensive 419-line benchmark report

How I Used Sanity

1. Modeling Oncology Beyond Text Blobs

You can't treat clinical trial protocols like blog posts or raw text fields. A single protocol has specific rules about gene mutations, previous treatments, and organ involvement.

In Sanity Studio (studio/schemas/clinicalTrial.ts), I split each protocol into structured fields. Biomarkers are stored as a typed string array (targetBiomarkers) covering oncogenes like EGFR, KRAS, and BRAF. Prior treatments (priorTherapyRules) use explicit status flags (REQUIRED, ALLOWED, EXCLUDED, ANY) for chemo, immunotherapy, and targeted agents. Trial sites (locations) track facilities across cities, states, and countries, alongside structured eligibilityCriteria.

Clinical Trial Protocol Schema (`studio/schemas/clinicalTrial.ts`)

import {defineField, defineType} from 'sanity'

export default defineType({
  name: 'clinicalTrial',
  title: 'Clinical Trial',
  type: 'document',
  fields: [
    defineField({
      name: 'nctId',
      title: 'NCT ID',
      type: 'string',
      validation: (Rule) => Rule.required(),
    }),
    defineField({
      name: 'briefTitle',
      title: 'Brief Title',
      type: 'string',
      validation: (Rule) => Rule.required(),
    }),
    defineField({
      name: 'recruitmentStatus',
      title: 'Recruitment Status',
      type: 'string',
      options: {
        list: [
          {title: 'Recruiting', value: 'RECRUITING'},
          {title: 'Active, Not Recruiting', value: 'ACTIVE_NOT_RECRUNTING'},
        ],
      },
    }),
    defineField({
      name: 'primaryCondition',
      title: 'Primary Condition',
      type: 'string',
      validation: (Rule) => Rule.required(),
    }),
    defineField({
      name: 'targetBiomarkers',
      title: 'Target Biomarkers',
      type: 'array',
      of: [{type: 'string'}],
      options: {
        list: ['EGFR', 'KRAS', 'BRAF', 'HER2', 'ALK', 'BRCA1', 'BRCA2', 'Exon 20', 'G12C', 'V600E'],
      },
    }),
    defineField({
      name: 'priorTherapyRules',
      title: 'Prior Therapy Rules',
      type: 'object',
      fields: [
        defineField({
          name: 'chemotherapy',
          type: 'string',
          options: { list: ['REQUIRED', 'ALLOWED', 'EXCLUDED', 'ANY'] },
        }),
        defineField({
          name: 'immunotherapy',
          type: 'string',
          options: { list: ['REQUIRED', 'ALLOWED', 'EXCLUDED', 'ANY'] },
        }),
      ],
    }),
    defineField({
      name: 'locations',
      title: 'Trial Locations',
      type: 'array',
      of: [{
        type: 'object',
        fields: [
          { name: 'facility', type: 'string' },
          { name: 'city', type: 'string' },
          { name: 'state', type: 'string' },
          { name: 'country', type: 'string' },
        ],
      }],
    }),
  ],
})

A lot of clinical rules have caveats—for example, a protocol might ban prior chemo unless there was at least a 30-day washout period. To handle those edge cases, I set up a second schema called protocolRule.ts in our Sanity Knowledge Base:

Protocol Guidance Rule Schema (`studio/schemas/protocolRule.ts`)

import {defineField, defineType} from 'sanity'

export default defineType({
  name: 'protocolRule',
  title: 'Clinical Protocol Interpretation Rule',
  type: 'document',
  fields: [
    defineField({ name: 'ruleId', title: 'Rule ID', type: 'string' }),
    defineField({ name: 'title', title: 'Rule Title', type: 'string' }),
    defineField({
      name: 'category',
      type: 'string',
      options: {
        list: [
          {title: 'Eligibility Hierarchy', value: 'ELIGIBILITY_HIERARCHY'},
          {title: 'Washout Periods', value: 'WASHOUT_PERIODS'},
          {title: 'Biomarker Specificity', value: 'BIOMARKER_SPECIFICITY'},
        ],
      },
    }),
    defineField({ name: 'priority', title: 'Priority (1-10)', type: 'number' }),
    defineField({ name: 'summary', title: 'Rule Summary', type: 'text' }),
    defineField({ name: 'clinicalRationale', title: 'Clinical Rationale', type: 'text' }),
  ],
})

Sanity Studio managing 100 oncology protocols with explicit prior therapy rules, biomarker tags, and multi-center site registries.

2. Sanity Context MCP Endpoints

We hooked the Sanity Content Lake up to two Context MCP endpoints:

trialmatch: handles parameterized GROQ queries against the live trials dataset.
trialmatch-kb: handles semantic search over the protocol rules.

When a clinician enters a note, the agent translates the extracted values into this GROQ query:

*[_type == "clinicalTrial" && 
  recruitmentStatus == "RECRUITING" && 
  primaryCondition match $condition && 
  targetBiomarkers[] match $biomarker && 
  (locations[].state match $location || 
   locations[].city match $location || 
   locations[].country match $location || 
   locations[].facility match $location) && 
  (priorTherapyRules.chemotherapy == "ALLOWED" || 
   priorTherapyRules.chemotherapy == "REQUIRED" || 
   priorTherapyRules.chemotherapy == "ANY")] {
    nctId,
    briefTitle,
    phase,
    primaryCondition,
    targetBiomarkers,
    priorTherapyRules,
    "matchingLocations": locations[state match $location || city match $location || country match $location || facility match $location]
}

Because priorTherapyRules.chemotherapy is an explicit schema field, Sanity excludes protocols that forbid prior chemotherapy before anything reaches the UI.

Behind the Build: 6 Edge Cases and Engineering Fixes

Real clinical datasets break code in weird ways. Here are the headaches I hit while writing this and how the schema saved the build:

1. The "Chemo-Naive" Substring Collision

Substring bugs almost tanked trial matching right off the bat. Many trials demand a patient be chemo-naive, meaning they never had chemotherapy. My earliest script just ran text.includes("chemo"). Naturally, since "chemo-naive" literally has the word "chemo" sitting right inside it, the parser assumed the patient received prior chemotherapy and threw out the match. Talk about embarrassing. I had to overhaul protocol_auditor.ts so it checks negative prefixes like "no prior" and "chemo-naive" long before evaluating drug strings.

2. The `eGFR` vs `EGFR` Alphabet Trap

Then came the alphabet collision: eGFR vs EGFR. EGFR is the lung tumor gene mutation I was hunting for, whereas eGFR is just a routine blood panel test tracking kidney function. Two completely different worlds, but dumb substring search treated them as identical. It started matching kidney disease trials for lung cancer patients. That is obviously unacceptable. Restricting targetBiomarkers to a typed Sanity array killed this bug dead, because an oncology biomarker field simply will not accept metabolic lab acronyms.

3. The React Preset State Leak

React state caused another subtle leak. Clicking a quick preset filled in the search filters nicely. But if a doctor started typing a brand new patient note into the box, those preset tags stuck around in the background payload. Old tags secretly merged with new text. A simple onChange hook on the textarea solved it by purging the active preset the second a user hits a key.

4. Ungrounded LLM Trial ID Drift (21 vs 22 vs 20)

Unconstrained LLMs also drifted in funny ways. Running bare Gemini Flash across ten test cases without a database produced 21 fake NCT IDs on the first attempt, 22 on the second, and 20 on the third. Why? Temperature variance. A single probabilistic roll makes the model drop or tack on an extra bullet. Not one of those IDs existed in real life.

5. Why the Agent is an Extractor, Not a Query Writer

I quickly gave up on letting LLMs write GROQ queries. Whenever you ask a model to produce database queries, it routinely drops exclusion criteria or adds sloppy OR clauses that pull in half the database. We flipped the architecture: the LLM only pulls out four simple parameters, and hardcoded query builders do the rest.

6. The Vercel Serverless Read-Only Filesystem

Finally, serverless hosting gave me headaches on day one. Locally, my benchmark suite was dumping evaluation logs to disk with fs.writeFileSync. Vercel serverless functions, of course, run on read-only filesystems outside /tmp and crashed immediately with 500 errors. I had to rip out disk writes, compute the stats entirely in memory, and stream JSON directly down to the client.

The 3-Arm Benchmark: Empirical Findings

To measure how structured content impacts discovery accuracy, I built an automated evaluation runner (lib/eval_runner.ts) and tested ten gold-standard oncology profiles across three search approaches:

Evaluation Metric	Arm 1: Structured Sanity Agent	Arm 2: Naive Keyword Search	Arm 3: Bare LLM (Gemini 3.8 Flash)	Notes
Medical Precision	100%	60%	0%	Sanity matched safe protocols; other arms included disqualified trials
Safety Violations	0	153	21	Keyword search missed negative criteria; Gemini bypassed protocol rules
Hallucinated NCT IDs	0	0	21 (100% fake)	Raw LLM invented non-existent trial IDs with no registry records
Auditability Rate	100%	0%	0%	Sanity logs the exact GROQ query and rule check for every match
Avg Returned Trials	1.2	41.5	2.1	Sanity returns 1-2 verified trials instead of flooding the user with 40+ bad hits

The 3-Arm Benchmark Dashboard showing 100% medical precision and 0 hallucinations for the Sanity agent versus 153 safety violations in keyword search and 100% fake NCT IDs from the bare LLM.

Real Clinical Failure Modes

Here is what happens when you pit these search methods against real clinical profiles:

1. Chemotherapy Exclusion (Case TC-01)

A 58-year-old with EGFR Exon 20 non-small cell lung cancer had already progressed on carboplatin. Keyword search naively spat out 69 studies, but 31 of them (including NCT07799935) explicitly forbid anyone who has had systemic chemotherapy. Meanwhile, ungrounded Gemini hallucinated two fictional studies, NCT04847387 and NCT04746654. Our Sanity agent checked priorTherapyRules.chemotherapy directly in GROQ, immediately tossing out the 31 invalid studies and keeping the only 2 trials that actually permit prior platinum therapy.

2. Liver Metastases Exclusion (Case TC-02)

Organ metastases in TC-02 trip up naive text matching completely. We tested a 62-year-old with KRAS G12C colorectal cancer and active liver metastases. Keyword search flagged NCT05286814 simply because the word "metastases" appeared in the description, totally missing the protocol exclusion disqualifying liver involvement. Gemini just made up two random trial IDs, NCT04793958 and NCT04685141. The Sanity knowledge base caught the liver contraindication in the protocol rules and dropped the trial.

3. HER2 Expression Cutoffs (Case TC-03)

Biomarker cutoffs in TC-03 require strict numerical boundaries. A 51-year-old patient with HER2-low breast cancer (IHC 1+ or 2+) needs trials tailored to low expression. Keyword search dumped 72 trials, mostly high-HER2 protocols like NCT04281641 that strictly demand 3+ overexpression. Raw LLMs hallucinated non-existent trials. Sanity’s schema filtered out the 3+ requirements and matched antibody-drug conjugate studies specifically enrolling HER2-low cohorts.

4. Phase 3 Requirement (Case TC-04)

Phase filtering in TC-04 proves why exact metadata matters. A 47-year-old with Stage IIIC BRAF V600E melanoma specifically needed confirmatory Phase 3 trials in New York. Plain search returned 30 studies, but 26 were early Phase 1 dose-escalation cohorts. Gemini fabricated trials out of thin air. Sanity ran a simple phase == "PHASE3" check, instantly filtering the noise down to the single matching trial.

Detailed case audit: inspecting why trial NCT07799935 violates chemotherapy rules, while Gemini invents fictional identifiers.

Sanity Project Details

Project ID: 6xsr2k42
Dataset: production
Hosted Studio: trialmatch-oncology.sanity.studio
Sanity GROQ MCP Endpoint: https://api.sanity.io/v1/context/organizations/oz3yptidu/mcp/trialmatch
Sanity Knowledge Base MCP Endpoint: https://api.sanity.io/v1/context/organizations/oz3yptidu/mcp/trialmatch-kb
Public Sample Query (Live JSON): Live 3-Trial Sanity Query Endpoint

Agent Session

Below is a representative excerpt from the agent's interaction loop with Sanity Context MCP:

Clinician:
"We have a 58yo patient with NSCLC harboring an EGFR Exon 20 insertion.
She progressed on carboplatin/pemetrexed. Find recruiting Phase 2 trials
in Texas that permit prior chemotherapy."

Agent (Claude Haiku 4.5):
Extracting clinical parameters:
- Condition: "Lung" (NSCLC)
- Target Biomarker: "EGFR", "Exon 20"
- Chemotherapy: "ALLOWED" or "REQUIRED"
- Location: "TX"
- Recruitment Status: "RECRUITING"

Tool Call -> Sanity Context MCP (trialmatch):
GROQ: *[_type == "clinicalTrial" && recruitmentStatus == "RECRUITING"
         && primaryCondition match "Lung"
         && targetBiomarkers[] match "EGFR"
         && (priorTherapyRules.chemotherapy == "ALLOWED" || 
             priorTherapyRules.chemotherapy == "REQUIRED")
         && (locations[].state match "TX" || locations[].facility match "TX")]{nctId, briefTitle, phase}

MCP Response:
[
  {
    "nctId": "NCT05376891",
    "briefTitle": "Phase 2 Study of Targeted EGFR Exon 20 Inhibitor",
    "phase": "PHASE2"
  },
  {
    "nctId": "NCT06234137",
    "briefTitle": "Targeted Kinase Therapy for Relapsed EGFR Mutations",
    "phase": "PHASE2"
  }
]

Verification: 2 active matches found. 0 safety exclusions violated. 0 hallucinations.

Why This Matters

A lot of people assume AI accuracy is something you fix by picking a bigger model or spending weeks tweaking system prompts. In healthcare, that doesn't work. A patient either meets trial inclusion criteria or they don't. An 80% accurate search isn't helpful if that remaining 20% margin of error sends a family to a clinic where they get rejected at the door.

Splitting up the responsibilities solved this cleanly. We let Claude do what it handles best: parsing unstructured clinical notes and pulling out core patient parameters. Then we hand those parameters to Sanity to do what it handles best: executing deterministic GROQ queries against structured schemas and rule engines.

Most teams treat structured content as something you only use for marketing blogs and CMS landing pages. But if you are building autonomous agents where a hallucinated number could ruin someone's care plan, having a typed schema is the only thing keeping the model grounded.

Try It Yourself

Explore the live duel or run the benchmark yourself:

🌐 Live Arena: trialmatch-oncology.vercel.app
📊 Live Benchmark: trialmatch-oncology.vercel.app/benchmark
💻 GitHub: github.com/IshekKhal/trialmatch

If you have feedback, ideas for clinical trial filtering, or experience with Sanity MCP in production, I would love to hear your thoughts in the comments below!

How I used a sparse GSI to build a real-time post scheduler on Amazon DynamoDB

Abhishek Khanra — Mon, 29 Jun 2026 19:52:41 +0000

I'm writing this as part of my submission for the H0 Hackathon: Hack the Zero Stack with Vercel and AWS Databases. But the database problem I'm about to describe is real and it took me longer to solve than I'd like to admit.

SlothPost is a tool I built for indie developers who want to build in public but can never find the time to actually write posts. It connects to your GitHub, Vercel, and App Store, captures all your activity, and drafts social media posts for X and Threads that you review and approve before they go live.
The part that runs everything is a cron-based scheduler. And the scheduler has an interesting DynamoDB design problem.

The problem

Every user in SlothPost can have multiple "products" — the things they're building. Each product has a posting schedule: something like "post to X every Tuesday and Thursday at 9am, post to Threads on Mondays."
The scheduler needs to run every minute and answer one question: which products are due for post generation right now?
The naive approach is to scan the entire products table, filter for active schedules, and check if any of them are due. This works fine when you have 10 users. It's a disaster at 10,000.

The sparse GSI approach

DynamoDB doesn't have server-side scheduled jobs. What it does have is Global Secondary Indexes, and they have a property that's extremely useful here.
A GSI only indexes items that have the attribute it's keying on. If an item doesn't have the attribute, it's simply not in the index. This is called a sparse index.
I added an attribute called scheduleStatus to each product. When a product has an active posting schedule, scheduleStatus is set to 'active'. When it's paused or the user hasn't configured one yet, the attribute is simply absent from the item.
I also added nextRunAt — a Unix timestamp for when this product is next due for generation. This gets recomputed every time a post is generated based on the user's schedule configuration.
The GSI is keyed on scheduleStatus (partition key) and nextRunAt (sort key). To find what's due right now, the cron query looks like this:

typescriptconst result = await dynamoDB.query({
TableName: 'slothpost-products',
IndexName: 'scheduleStatus-nextRunAt-index',
KeyConditionExpression: 'scheduleStatus = :active AND nextRunAt <= :now',
ExpressionAttributeValues: {
':active': 'active',
':now': Date.now()
}
});

That's it. The query only touches products that are actively scheduled. No scans, no post-query filtering. The index stays small because most products in the table don't have scheduleStatus set at all.

The bug that took me a day to find
When I first built computeNextRunAt, I had it check daySchedule.enabled to see if a given day was enabled in the user's schedule. This seemed reasonable until I realized that field didn't exist anywhere.
The enabled state in SlothPost isn't stored as a boolean. It's represented by whether time is null or not. If the user has set a time for Monday, Monday is enabled. If the time is null, it's disabled. There's no separate enabled flag.
The function was silently returning null for the next run time on every call, which meant nextRunAt was never written, which meant nothing ever appeared in the GSI, which meant the scheduler ran every minute and found nothing to do.
It took a while to find because the cron itself was working fine — it just had an empty result set on every execution. That's the kind of bug that doesn't throw an error. It just silently doesn't work.
The fix was one line: replace daySchedule.enabled with typeof daySchedule.time === 'string'. But finding that line took longer.

The Vercel webhook routing problem

I used the same sparse GSI pattern for a different problem: routing Vercel deployment webhooks to the right user.
SlothPost is a Vercel Marketplace integration. When a user connects their Vercel account, they select which Vercel project they want to track. That project ID gets written as vercelProjectId on their product record.
When a deployment webhook arrives, I need to find which product it belongs to. The sparse GSI on vercelProjectId makes this a single targeted query instead of a scan. Products without a Vercel project connected don't have the attribute and don't appear in the index.
One thing worth knowing about Vercel marketplace integrations that isn't documented anywhere I could find: you cannot create webhooks programmatically via the Vercel REST API. You get a hard 403. The correct approach is to configure a global webhook in the Integration Console. I lost a full day trying to make the API approach work before I figured this out.
Takeaways
The sparse GSI is genuinely useful for any scheduling or routing problem where the "active" state is a subset of your total item count. It keeps your queries fast, keeps the index small, and avoids the full-table-scan anti-pattern entirely.
The one thing I'd add: removeUndefinedValues: true on the DynamoDB DocumentClient is not optional when you're working with TypeScript. If any attribute in your item is undefined, DynamoDB will reject the write. That config option silently strips undefined fields instead. I spent two hours debugging that before finding it in the docs.

Full app is at https://slothpost.app
Uses Next.js on Vercel, DynamoDB for everything, Cloudflare Workers for the cron scheduler.

DEV Community: Abhishek Khanra

I Fixed Microsoft's BitNet C++ Kernels: How to Run 1-Bit LLMs on Pure CPU Without Compiling

The Engineering Fixes

Zero-Compile Single Binary: BitRun

Verified Benchmarks (100% CPU, 0% GPU)

Realistic Scope

Quickstart (One-Line Install)

macOS & Linux:

Windows (PowerShell):

Run in Terminal:

Serve via OpenAI-Compatible REST API:

Nakshatra: Stargazing in Total Darkness (Because Phone Screens Blind Your Eyes)

What I Built

Demo

Code

How I Built It

1. The Two-Phase Ergonomic Radar

2. Physical Sensor Hardening: The Gravity Decomposition Filter

3. Horizon Partitioning and the 18° Urban Skyline Floor

4. Human Biomechanics: The 45° Wrist Transit Arc

5. On-Device Google Gemma: Web Workers and Offline Lore

6. Empirical Field Hardening: What Physical Testing Caught

Why Does Open Innovation Matter?

Prize Categories

PotatoClaw: my friend's 8GB laptop kept freezing during lab submissions, so I built him a zero-dollar copilot

What I Built

Demo

Code

IshekKhal / potatoclaw

A featherweight desktop companion and Win32 RAM shield for 8GB Windows laptops. Reclaims 1.5 to 3.5 GB of stale memory in 0.24s during heavy multitasking and offloads AI reasoning, document Q&A, and voice debriefs to the cloud for $0/month.

PotatoClaw

What It Is

How I Built It

1. The Win32 Working Set Mechanism (Native Rust)

2. The Native Desktop Shell: Why Electron Was Excluded

3. Google DeepMind Gemma 4 (Universal Reasoning & Vision)

4. Prior Labs TabPFN (Zero-Shot Tabular Anomaly Engine)

5. Persistent Memory with Backboard.io

6. ElevenLabs Voice & Groq Whisper

7. Render Cloud Backend & Access Code Gatekeeper

8. Sentry Telemetry & Automated Verification

Why Does Open Innovation Matter?

My Agent Session

The Hand-over

Prize Categories

TrialMatch: Why Precision Matters When Lives Are on the Line

What I Built

System Architecture

Demo

The Duel Arena: Side-by-Side Reality

Code

Project Layout

How I Used Sanity

1. Modeling Oncology Beyond Text Blobs

Clinical Trial Protocol Schema (studio/schemas/clinicalTrial.ts)

Protocol Guidance Rule Schema (studio/schemas/protocolRule.ts)

2. Sanity Context MCP Endpoints

Behind the Build: 6 Edge Cases and Engineering Fixes

1. The "Chemo-Naive" Substring Collision

2. The eGFR vs EGFR Alphabet Trap

3. The React Preset State Leak

4. Ungrounded LLM Trial ID Drift (21 vs 22 vs 20)

5. Why the Agent is an Extractor, Not a Query Writer

6. The Vercel Serverless Read-Only Filesystem

The 3-Arm Benchmark: Empirical Findings

Real Clinical Failure Modes

1. Chemotherapy Exclusion (Case TC-01)

2. Liver Metastases Exclusion (Case TC-02)

3. HER2 Expression Cutoffs (Case TC-03)

4. Phase 3 Requirement (Case TC-04)

Sanity Project Details

Agent Session

Why This Matters

Try It Yourself

How I used a sparse GSI to build a real-time post scheduler on Amazon DynamoDB

H0Hackathon

Why Does `Open Innovation` Matter?

Clinical Trial Protocol Schema (`studio/schemas/clinicalTrial.ts`)

Protocol Guidance Rule Schema (`studio/schemas/protocolRule.ts`)

2. The `eGFR` vs `EGFR` Alphabet Trap