The $15 AI Coding Agent: Running an Autonomous LLM Workflow on a Microcontroller

An ESP32-S3 board connected over HTTP/SSE to a terminal window running the fx coding agent

Most AI agents today are resource hogs. Running an autonomous coding agent like Claude Engineer, Devin-style loops, or OpenDevin typically demands hundreds of megabytes of RAM just to boot the runtime—trapping them inside chunky Node.js or Python runtimes on laptops, cloud VMs, or dedicated servers.

What if your agent harness didn’t need a PC at all? What if you could run a fully functional, self-contained coding agent on a microcontroller that costs less than lunch?

By pairing native NOMMU Linux on an ESP32-S3, WebAssembly via WAMR, and Vercel Labs’ minimalist fx agent, you can deploy a dedicated, ultra-low-power physical coding appliance for anywhere from $15 (headless) to $80 (with an industrial touch display).

The Architecture: Brains in the Cloud, Hands at the Edge

A common misconception about embedded AI is that the microcontroller needs to perform local neural network inference. On an ESP32, that would yield tokens per hour, not tokens per second.

Instead, this stack decouples the agent harness (the state machine that reads files, executes shell commands, and handles tool calling) from the inference engine (the LLM):

Diagram: an upstream LLM provider connects over HTTP/SSE/JSON-RPC to the ESP32-S3. Core 0 runs ESP-IDF for Wi-Fi/BLE, bridged over shared memory to Core 1, which runs Linux 6.11, which runs WAMR, which runs the fx agent, which reaches the local filesystem, shell, and GPIO.
The agent harness lives on the chip; inference stays upstream.

The ESP32 runs the harness, holds the workspace, reads project files, and triggers commands. Inference runs upstream over low-latency SSE—either via the Vercel AI Gateway or your own local router on your LAN.

Anatomy of the Stack

1. The Silicon: ESP32-S3 (N32R8)

The ESP32-S3 packs a dual-core Xtensa LX7 processor running at 240 MHz, 32MB of external flash, and 8MB of octal PSRAM.

  • Bare Metal ($10–$20): A raw ESP32-S3 dev board works completely headless over UART or SSH.
  • Turnkey Appliance ($80): Seeed Studio’s reTerminal E1001 packages the same N32R8 chip inside an industrial housing complete with a 4-inch display, physical buttons, an RTC, and external I/O headers.

2. The OS: Real Linux 6.11 on NOMMU Xtensa

This isn’t an emulator. Using the work from Max Filippov (jcmvbkbc/linux-xtensa) and Paul Neja (paulneja/Linux-on-esp32-S3), the ESP32 boots a real Linux 6.11 kernel.

  • Core 0 runs Espressif’s ESP-IDF RTOS to handle the closed-source Wi-Fi/Bluetooth stack.
  • Core 1 boots the Linux kernel.
  • Network packets bridge between the two cores via shared RAM exposed as a native espsta0 interface.
  • The Catch: The ESP32 lacks a Memory Management Unit (MMU). That means no virtual memory, no standard fork() (applications rely on vfork() and FDPIC ELF binaries), and a strict 8MB ceiling for RAM.

3. Execution Runtime: WAMR & microWASM

Because NOMMU Linux has strict memory limits, running native dynamic runtimes is risky. Enter WAMR (WebAssembly Micro Runtime):

  • Consumes only single-digit kilobytes of memory.
  • Provides a secure, sandboxed WASI interface.
  • Uses microWASM ahead-of-time optimization to strip and prepare .wasm binaries so they execute reliably within our constrained 8MB PSRAM pool without causing heap fragmentation panics.

4. The Agent: Vercel Labs fx

Written in Zig by the Vercel Labs team, fx is a Unix-style coding agent built from scratch for speed and minimal footprint. While typical agents pull in gigabytes of node_modules, fx compiles down to a compact sub-8MB binary or a portable .wasm module with near-instant boot times. Porting it to the ESP32 via iammrduncan/esp32-fx turns the microcontroller into an autonomous workspace manager.

Cutting the Cord: Routing to a Local Model

While early builds of fx routed exclusively through Vercel’s cloud gateway, modern configurations let you point directly to an OpenAI-compatible endpoint—such as a local Ollama server, vLLM instance, or LAN router.

On the ESP32 root filesystem, create ~/.fx/settings.json:

{
  "connections": {
    "local-router": {
      "base_url": "http://192.168.1.100:11434/v1",
      "auth": {
        "type": "none"
      },
      "tool_choice_mode": "omit",
      "model_metadata": {
        "qwen2.5-coder:7b": {
          "context_window": 32768,
          "max_output_tokens": 4096,
          "supports_tool_use": true,
          "supports_vision": false
        }
      }
    }
  },
  "models": {
    "local-router": "qwen2.5-coder:7b"
  }
}

Why Metadata Matters on Edge Devices

In settings.json, specifying context_window is non-negotiable. Because the ESP32 cannot hold massive conversation trees in RAM, fx automatically triggers session compaction once the context reaches 80% capacity. Without this parameter, memory exhaustion will kill the process mid-stream.

Activate the connection in /etc/profile:

export FX_PROVIDER="local-router"
export FX_MODEL="qwen2.5-coder:7b"

Verify the setup on the device:

# Verify the connection
fx models

# Test the agentic tool-calling loop locally
fx ask "List all files in the current workspace and summarize the project structure"

Real-World Use Cases

Why build an agent on an ESP32 instead of running it on your laptop?

  1. The Physical “Prompt Box” Console: Paired with the reTerminal E1001, you get a dedicated hardware appliance sitting under your monitor. Assign it specific duties—triage GitHub issues, run continuous sanity checks on builds, or review pull requests—without consuming desktop memory or screen real estate.
  2. True Hardware Sandboxing: When an autonomous agent is testing unfamiliar scripts or modifying configurations, running it on your main system carries risk. On an ESP32, the blast radius is physically contained. If an agent loops, corrupts the filesystem, or tries something dangerous, you’re out a $15 board, not your primary workstation.
  3. Physical-World Diagnostics: Connected directly to hardware buses (I2C, SPI, RS-485, CAN bus), an ESP32 running fx can observe physical sensors, interpret fault codes with an LLM, and execute physical remediations like power-cycling relays or flashing warning beacons.

What to Watch Out For

  • Heavy Compiles: The ESP32’s 240 MHz Xtensa core is plenty fast for running fx, handling git trees, and executing scripts, but building large native codebases locally will be slow. Keep the agent focused on editing files, scripting, and triggering remote CI/CD jobs.
  • Memory Headroom: With 8MB of octal PSRAM shared between Linux and WAMR, keep an eye on memory fragmentation. Static heap pools within WAMR are your best defense against out-of-memory lockups.

Summary

The era of agents being tethered to power-hungry rigs is ending. Combining native NOMMU Linux, WebAssembly sandboxing, and lean systems languages like Zig allows an autonomous agent to run on a sub-$20 chip drawing less than a single watt.

← Back to all posts