Guild - A Free Autonomous Coding Agent That Escalates Through Gemma 4 Models

The "Python Dev Loop" preset: requirements→architect feed into verifiers, which gate a tdd_implementer block. Click to expand that block and see the internal pipeline (planner→test_writer→implementer→refactorer). The edit panel on the right shows agent configuration — name, role, Gemma 4 model selection, instructions, and ports.

The planner agent (powered by Gemma 4) decomposed the task and produced assembly instructions. The coder block is now executing those instructions. Each block's output is visible in real-time, with a timeline showing the full execution history.

3. Task Management — Launch and monitor agents:

Code

Repository: )

How I Used Gemma 4

Model Selection: Why Gemma 4?

Gemma 4 is the ideal model family for Guild because:

1. 
   Runs locally via Ollama — zero API cost, complete privacy


2. 
   Multiple size tiers (E2B, E4B, 31B Dense) — enables the escalation architecture


3. 
   128K context window — can hold entire codebases in context


4. 
   Strong code reasoning — particularly the 31B Dense variant

The Escalation Architecture

The core insight: most agent turns don't need the 31B Dense model. Reading a file, running a test, writing a simple function — Gemma 4 E4B handles these fine. But when the agent encounters:

• Repeated failures (same error 3+ times)


• Complex multi-file reasoning


• Architectural decisions requiring broad context

...it automatically escalates to Gemma 4 31B Dense, which has the reasoning depth to break through. And if even that isn't enough — the chain continues to cloud providers (Claude, Codex) as a final tier before asking a human.

This gives you:

• 
  80% of turns at E4B speed (fast, local, free)


• 
  15% of turns at 31B Dense quality (complex local reasoning)


• 
  5% of turns at cloud tier (when local models genuinely can't solve it)


• 
  Near-zero cost — cloud is only used as last resort

The Full Escalation Chain

Teams can also mix providers per-block — e.g., Gemma 4 E4B as the fast coder, Claude as the strict reviewer. Each block in a workflow defines its own provider independently.

# Configure the escalation chain

guild config --set provider.provider_name=ollama

guild config --set provider.model=gemma4-4b-dense-med

guild config --set escalation.escalation_chain=gemma4-31b-dense,claude

Why Not Just Use the Big Model?

Three reasons:

1. 
   Resource contention — 31B Dense uses significant RAM/VRAM. The "good neighbor" philosophy means minimizing resource usage.


2. 
   Speed — E4B responds in 1-2 seconds; 31B Dense takes 10-15 seconds. For simple file reads, that latency is wasted.


3. 
   Autonomy duration — when running overnight on a coding task, token efficiency means more work done per charge cycle.

The escalation chain is configurable. If you have the hardware, run 31B Dense all the time. If you're on a laptop, start at E4B and let Guild decide when to bring in the heavy model. If you need cloud power for the hardest problems, add Claude/Codex to the chain — Guild will only use them when local models are genuinely stuck.