Wintermolt: The Everything-Agent in 3 MB

What is Wintermolt?

Wintermolt is an autonomous AI agent CLI written entirely in Zig 0.15. It compiles to a single 3 MB native binary with only two external dependencies — libcurl for HTTPS and sqlite3 for persistence — both pre-installed on macOS and most Linux distributions. Unlike every other agent in this set, it has zero runtime: no Node.js, no Python, no Electron, no virtual environments.

The project ships ~18,400 lines of Zig across 51 source files, plus two prebuilt Zig static libraries (libforagent.a and libforlearn.a) from sibling projects. The codebase is organized into clean modules: agent core, API clients, tools, MCP, chat/web/menubar bridges, and a canvas renderer.

Architecture overview

The agentic loop

The core loop lives in src/agent/loop.zig (~646 lines). The AgentLoop struct runs a prompt → tools → observe → repeat cycle with up to 25 tool iterations per turn:

1. User message added to history with approximate token counting (approx_tokens += text.len / 3)
2. RAG indexing — fire-and-forget rag.indexMessage() for Pinecone semantic memory
3. Tool relevance filtering — keyword-matches user text against trigger lists to select extended tools (tools.getRelevantDefinitions())
4. API call — streams to the primary backend with live terminal output via callback
5. Response parsing: .end_turn, .max_tokens, .stop_sequence, .tool_use, or .unknown
6. Tool execution — executeTools() iterates over tool_use content blocks
7. Results fed back as user-role messages (required by the API pattern)
8. Context overflowhistory.emergencyCompact() (drops to 40% budget) and retries

The sendToBackend method implements automatic fallback: if the primary backend fails, it tries Ollama first (local, no rate limits), then OpenAI.

6 AI backends — one binary

All backends share a unified protocol.Message / protocol.Response wire type in src/api/protocol.zig (~281 lines). The dispatch happens in loop.zig's switchBackend:

The DeepSeekClient struct is effectively a universal OpenAI-compatible client — it's reused for OpenAI, DeepSeek, Qwen, Gemini, and the custom forAI endpoint by simply overriding the api_url field.

Three hand-written streaming parsers handle the wire formats: sse.zig (~461 lines) for Anthropic SSE, openai_sse.zig (~287 lines) for OpenAI SSE, and ndjson.zig (~250 lines) for Ollama NDJSON. Each is an incremental character-by-character parser with no streaming library dependency.

The 16 built-in tools

Tool dispatch lives in src/agent/tools.zig (~717 lines) with a three-layer architecture:

• Layer 1 — Built-in tools hardcoded in the executeTool dispatch chain
• Layer 2 — Runtime skills loaded from skill.json manifests
• Layer 3 — MCP remote tools from external MCP servers (prefixed like filesystem__read_file)

The bash tool includes automatic API key redaction — it scans for 12 secret patterns (sk-ant-, sk-proj-, xoxb-, ghp_, AIza, etc.) before returning output to the AI context.

Cron scheduler

src/agent/scheduler.zig (~756 lines) implements a SQLite-persisted job scheduler with three schedule types:

• every — repeat interval ("5m", "1h", "30s")
• at — daily at time ("09:00", "14:30")
• cron — standard cron expression ("*/5 * * * *")

The tickScheduler() is called from the REPL loop on every iteration. It queries due jobs, executes each via the bash tool, and updates last_run/next_run. Jobs are auto-disabled after max_retries consecutive failures.

No other agent in this set has a built-in cron scheduler.

MCP: both client and server

Wintermolt is one of only two agents in this set that implements MCP bidirectionally (Crush is the other).

As server (src/mcp/server.zig, ~214 lines): Exposes 20+ Wintermolt tools via JSON-RPC 2.0 over stdio. Supports initialize, tools/list, tools/call, resources/list, prompts/list, ping.

As client (src/mcp/client.zig, ~421 lines): Loads external MCP servers from ~/.wintermolt/mcp.json, spawns each as a child process with stdin/stdout pipes, runs the 3-step MCP handshake, and prefixes all discovered tool names with "servername__" (e.g., filesystem__read_file).

Chat bridges

All bridges follow the same sidecar IPC pattern: Zig spawns a child process (TypeScript/Swift), communicates via JSON lines over stdin/stdout pipes. No sockets, no HTTP servers, no shared memory — clean process boundaries.

The chat bridge uses a 7-tier priority binding system in src/agent/router.zig (~585 lines): peer → parent_peer → guild_role → guild → team → account → channel.

Memory and RAG

Tier 1 — SQLite (src/agent/storage.zig, ~793 lines): ~/.wintermolt/history.db with conversations and messages tables. All public methods are designed for catch-and-ignore — storage failures never break the agentic loop.

Tier 2 — Pinecone RAG (src/agent/rag.zig, ~577 lines): Vector database for semantic search with auto-embedding via Pinecone's integrated inference. Every user and assistant message is indexed fire-and-forget. Namespaced by user session (web mode) or domain (knowledge bases).

Skills system

Two-layer skill system:

• Comptime catalog (src/agent/skills.zig, 158 lines): 14 built-in SkillEntry structs — zero allocation, zero I/O, pure string literals.
• Runtime plugins (src/agent/skill_loader.zig, ~367 lines): Scans ./skills/, ~/.wintermolt/skills/, and ~/.wintermolt/plugins/*/skills/. Each skill gets its own tool_schema, optional backend/model preferences, and a handler type (bash, mcp, script, or prompt).

The project ships 79 skill definitions across 11 domains: Zortran Core, Fortran Kernels, Zig Systems, Physics/Simulation, AI/ML Kernels, Cybersecurity, Synthetic Data, Agent Architecture, Audio/Music, 3D/VFX, and Engineering.

Unique engineering decisions

7 execution modes

Strengths

• Binary footprint — 3 MB vs 200–500 MB for Node.js/Electron agents
• Zero runtime — no npm, pip, venv, node_modules, or Docker required
• Cross-compilation — one command targets ARM, x86_64, macOS, Linux
• Feature breadth — no other single agent has cron + Tailscale + camera + browser + MCP + chat bridges
• Secrets redaction — automatic API key scrubbing from bash output (12 patterns)
• Fallback chain — primary backend failure auto-falls back to Ollama then OpenAI
• Clean process boundaries — all sidecars use JSON-lines over stdio, no sockets

Tradeoffs

Key files to read

Verdict