DEV Community: Jangwook Kim

Docker Model Runner vs Ollama: Local AI Deployment Compared 2026

Jangwook Kim — Sat, 04 Apr 2026 03:53:54 +0000

Docker Model Runner vs Ollama: Local AI Deployment Compared 2026

Docker entered the local AI space. If you are already running models with Ollama, you are now looking at a second option that speaks the same language — literally the same OpenAI-compatible API — but comes from the company that standardized how the world ships software.

Docker Model Runner (DMR) shipped with Docker Desktop 4.40 in mid-2025 and has been evolving fast. It uses llama.cpp under the hood, stores models as OCI artifacts on Docker Hub, and integrates directly into Docker Compose workflows. Ollama, meanwhile, remains the default choice for local LLM deployment with 52+ million monthly downloads, a broader model library, and an ecosystem that every AI coding tool already supports.

The question is not which tool is objectively better — it is which tool fits your workflow. This guide compares both hands-on: installation, model management, performance, GPU acceleration, IDE integration, and server deployment. We tested with Gemma 4 E4B as the reference model on both platforms.

If you are new to running models locally, start with our Ollama + Open WebUI setup guide first. If you already have Ollama running and want to know whether Docker Model Runner is worth adding to your stack, keep reading.

What Is Docker Model Runner

Docker Model Runner is Docker's native solution for running AI models locally. It is not a container that runs a model inside it — it runs models directly on the host using llama.cpp, with no container overhead.

How It Works

DMR treats AI models as first-class Docker primitives, similar to images and containers. Models are stored as OCI (Open Container Initiative) artifacts, the same standard that Docker uses for container images. This means models can be pushed to and pulled from Docker Hub, private registries, or any OCI-compliant registry.

When you pull a model with docker model pull, it downloads the GGUF weights and stores them locally. When you run inference, llama.cpp loads the model into memory, runs the computation on your CPU or GPU, and returns results through an OpenAI-compatible API on port 12434.

Key Features

OpenAI-compatible API on localhost:12434. Any tool that speaks to the OpenAI API can point at Docker Model Runner instead.
Ollama-compatible API as well — existing Ollama integrations can switch endpoints without code changes.
Docker Compose integration. Define models as services in your docker-compose.yml. Docker pulls and starts the model automatically during docker compose up.
Multiple inference engines. llama.cpp (default, broad hardware support), vLLM (high-throughput production workloads), and Diffusers (image generation).
GPU acceleration. Metal (Apple Silicon), CUDA (NVIDIA), and Vulkan (AMD, Intel, NVIDIA).
Lazy loading. Models load into memory only when a request arrives and unload when idle, freeing resources automatically.
Metrics endpoint at /metrics for monitoring performance and resource usage.

System Requirements

Docker Desktop 4.40+ (macOS, Windows) or Docker Engine on Linux
8 GB RAM minimum, 16 GB recommended
Optional: Apple Silicon (Metal), NVIDIA GPU (CUDA), or Vulkan-compatible GPU

Ollama Recap — The Current Standard

If you have been running models locally in the past two years, you probably started with Ollama. It launched in 2023 and quickly became the default tool for local LLM management.

Ollama provides a simple CLI (ollama pull, ollama run), an OpenAI-compatible API on port 11434, and a growing library of pre-configured models. It supports GGUF, Safetensors, and custom Modelfiles for fine-tuned configurations.

We covered Ollama setup in depth in our Ollama + Open WebUI guide and used it as the foundation for our Gemma 4 local setup guide. If you are new to local AI, those articles give you a working setup in under 10 minutes.

What Makes Ollama the Default

52+ million monthly downloads as of Q1 2026 (source)
Broadest model library. Hundreds of models available through ollama.com/library, plus import support for GGUF and Safetensors formats
Custom Modelfiles. Create model configurations with specific system prompts, parameters, and adapters
Ecosystem integration. LangChain, LlamaIndex, Spring AI, Open WebUI, Continue.dev, Cursor, Aider — virtually every AI developer tool supports Ollama natively
Cross-platform. macOS, Linux, Windows. Works on Apple Silicon, NVIDIA GPUs, and CPU-only setups

Installation and Setup Comparison

Installing Docker Model Runner

If you already have Docker Desktop installed, DMR may already be available. Check:

docker model version

If the command is not recognized, enable it in Docker Desktop:

Open Docker Desktop
Go to Settings → AI
Enable Docker Model Runner
Optionally enable GPU-backend inference if you have a supported GPU

On Linux with Docker Engine, DMR is included when installed from Docker's official repositories. The TCP endpoint is enabled by default on port 12434.

Pull your first model:

docker model pull ai/gemma4

Run it:

docker model run ai/gemma4 "Explain Docker Model Runner in one sentence"

The API is immediately available at http://localhost:12434.

Installing Ollama

Download from ollama.com or install via command line:

# macOS / Linux
curl -fsSL https://ollama.com/install.sh | sh

# Verify
ollama --version

Pull and run a model:

ollama pull gemma4:e4b
ollama run gemma4:e4b "Explain Ollama in one sentence"

The API is available at http://localhost:11434.

Setup Comparison Summary

Aspect	Docker Model Runner	Ollama
Install method	Included in Docker Desktop / Engine	Standalone installer or script
Prerequisite	Docker Desktop or Engine	None
Default port	12434	11434
Enable step	Settings → AI → Enable	None (runs on install)
Time to first model	~2 minutes (if Docker installed)	~2 minutes
Model format	GGUF (OCI artifacts)	GGUF, Safetensors, custom Modelfiles

Bottom line: Ollama is faster to set up from scratch because it has no prerequisites. Docker Model Runner is faster if Docker is already part of your workflow — it is a toggle in settings, not a new tool to install.

Model Catalog and Availability

Docker Model Runner: Docker Hub AI Models

DMR pulls models from Docker Hub under the ai/ namespace. Available models include:

ai/gemma4 — Google Gemma 4 (multiple sizes)
ai/llama3.2 — Meta Llama 3.2
ai/mistral — Mistral AI
ai/phi4 — Microsoft Phi 4
ai/qwen2.5 — Alibaba Qwen 2.5
ai/deepseek-r1-distill-llama — DeepSeek R1 distilled
ai/mistral-nemo — Mistral Nemo
ai/qwq — QwQ reasoning model

Models are stored as OCI artifacts, meaning they follow the same distribution standard as Docker container images. You can also pull models from Hugging Face.

# List downloaded models
docker model ls

# Pull a specific quantization
docker model pull ai/gemma4:e4b-q4_K_M

# Remove a model
docker model rm ai/gemma4

Ollama: The Broader Library

Ollama's model library is significantly larger. Beyond the major model families, it includes:

Community-uploaded models and fine-tunes
Custom Modelfiles for configuring system prompts, temperature, and stop tokens
Support for importing raw GGUF files and Safetensors models
Quantization variants for most models

# List downloaded models
ollama list

# Pull a specific model
ollama pull gemma4:e4b

# Create a custom model from a Modelfile
ollama create my-assistant -f Modelfile

# Remove a model
ollama rm gemma4:e4b

Catalog Comparison

Aspect	Docker Model Runner	Ollama
Model source	Docker Hub (`ai/` namespace), Hugging Face	ollama.com/library, Hugging Face, GGUF import
Number of models	Curated selection (~20+ families)	Hundreds of models + community uploads
Custom models	Import GGUF files	Modelfiles, GGUF import, Safetensors
Storage format	OCI artifacts	Proprietary blob format
Registry support	Any OCI registry	Ollama registry only

Bottom line: Ollama wins on catalog breadth. Docker Model Runner wins on standardized distribution — OCI artifacts mean you can use existing container registry infrastructure for model management.

Performance: Startup, Inference, and Memory

Performance between Docker Model Runner and Ollama is largely comparable — both use llama.cpp as the default inference engine. The architectural differences are in how they manage model loading and memory, not in raw inference speed.

Inference Speed

Independent benchmarks show inference speed differences of 1.0–1.12x between the two tools, which is imperceptible in practice (source). Both tools use the same underlying llama.cpp engine for GGUF model inference, so token generation speed is essentially identical for the same model and quantization level.

Model Loading

Docker Model Runner uses lazy loading — models are loaded into memory only when the first request arrives and unloaded when idle. This is resource-efficient but means the first request after idle has higher latency.

Ollama keeps models loaded in memory by default (configurable with OLLAMA_KEEP_ALIVE). This gives faster first-response times but uses more memory when idle.

Memory Usage

Both tools have similar peak memory usage for the same model since they use the same inference engine. The difference is in idle behavior:

DMR: Unloads models when idle → lower idle memory usage
Ollama: Keeps models loaded (default 5 minutes) → faster responses, higher idle memory

Inference Engine Options

Docker Model Runner offers a key advantage here: multiple inference engines.

Engine	Best For	Supported Platforms
llama.cpp (default)	General use, broad hardware	CPU, Metal, CUDA, Vulkan
vLLM	High-throughput production	Metal (macOS), CUDA (Linux/Windows)
Diffusers	Image generation	CPU, CUDA

Ollama uses its own optimized fork of llama.cpp exclusively.

On Apple Silicon, llama.cpp throughput stays stable at approximately 333–345 tokens/second regardless of output length for models like Llama 3.2 1B. vLLM shows more variance (134–343 tokens/second) but excels at concurrent request handling (source).

Bottom line: For single-user local inference, performance is a tie. Docker Model Runner's vLLM engine gives it an edge for multi-user or production scenarios where throughput matters more than time-to-first-token.

GPU Acceleration

Both tools support GPU acceleration, but the implementation and configuration differ.

Docker Model Runner GPU Support

DMR supports three GPU backends:

Metal (Apple Silicon M1/M2/M3/M4) — enabled by default, no configuration needed
CUDA (NVIDIA GPUs) — requires NVIDIA Container Runtime
Vulkan (AMD, Intel, NVIDIA) — added in Docker Desktop 4.42, broadest hardware support

Enable GPU in Docker Desktop: Settings → AI → GPU-backend inference.

On Linux with NVIDIA GPUs:

# Verify GPU is detected
docker model status

# Pull and run with GPU acceleration
docker model pull ai/gemma4:e4b
docker model run ai/gemma4:e4b "Test GPU inference"

Ollama GPU Support

Ollama detects and uses available GPUs automatically:

Metal (Apple Silicon) — automatic, no configuration
CUDA (NVIDIA) — automatic if NVIDIA drivers are installed
ROCm (AMD GPUs on Linux) — supported with ROCm drivers

# Check GPU detection
ollama ps

# Force CPU-only mode if needed
OLLAMA_NO_GPU=1 ollama serve

GPU Comparison

Feature	Docker Model Runner	Ollama
Apple Silicon Metal	Yes (automatic)	Yes (automatic)
NVIDIA CUDA	Yes (needs runtime)	Yes (automatic)
AMD ROCm	Via Vulkan	Yes (Linux)
Intel GPUs	Via Vulkan	No
Vulkan support	Yes	No
Configuration	Settings toggle	Automatic detection

Bottom line: Ollama has simpler GPU setup — it just works. Docker Model Runner has broader GPU support through Vulkan, covering AMD and Intel GPUs that Ollama cannot use.

Integration Ecosystem

This is where the comparison gets practical. If your AI coding tools cannot connect to the model runner, the performance benchmarks do not matter.

IDE and Tool Compatibility

Both Docker Model Runner and Ollama provide OpenAI-compatible APIs, which means most tools can connect to either. Here is the integration status for popular AI developer tools:

Tool	Docker Model Runner	Ollama
Continue.dev	Yes (OpenAI provider)	Yes (native Ollama provider)
Cursor	Yes (OpenAI endpoint)	Yes (native)
Aider	Yes (via env vars)	Yes (native)
Open WebUI	Yes (OpenAI connection)	Yes (native, recommended)
LangChain	Yes (OpenAI SDK)	Yes (native Ollama SDK)
LlamaIndex	Yes (OpenAI SDK)	Yes (native Ollama SDK)
Spring AI	Yes (native support)	Yes (native support)

Docker Model Runner: Continue.dev Configuration

Edit ~/.continue/config.json:

{
  "models": [
    {
      "title": "Gemma 4 (Docker)",
      "provider": "openai",
      "model": "ai/gemma4",
      "apiBase": "http://localhost:12434/engines/v1"
    }
  ]
}

Docker Model Runner: Aider Configuration

export OPENAI_API_BASE=http://localhost:12434/engines/v1
export OPENAI_API_KEY=anything
aider --model ai/gemma4

Ollama: Continue.dev Configuration

{
  "models": [
    {
      "title": "Gemma 4 (Ollama)",
      "provider": "ollama",
      "model": "gemma4:e4b"
    }
  ]
}

Docker Compose Integration (DMR Exclusive)

This is Docker Model Runner's biggest ecosystem differentiator. You can define AI models as services in docker-compose.yml:

services:
  model:
    provider:
      type: model
      options:
        model: ai/gemma4

  app:
    build: .
    environment:
      - MODEL_URL=${MODEL_MODEL_URL}
      - MODEL_NAME=${MODEL_MODEL_NAME}
    depends_on:
      - model

When you run docker compose up, Docker automatically pulls the model, starts inference, and injects connection details (MODEL_MODEL_URL, MODEL_MODEL_NAME) into your application container. No manual setup, no glue code.

For containers that need to reach Docker Model Runner directly, add:

services:
  app:
    extra_hosts:
      - "model-runner.docker.internal:host-gateway"

Then access the API at http://model-runner.docker.internal:12434/.

Bottom line: Ollama has deeper native integrations — most tools have a dedicated Ollama provider. Docker Model Runner works through the OpenAI-compatible API, which is universal but requires manual endpoint configuration. The Docker Compose integration is the standout feature for teams building AI-powered applications.

GPU Server Deployment on Hetzner

For models that exceed your laptop's capabilities — like Gemma 4 26B MoE or 31B Dense — you need a GPU server. We covered Hetzner GPU setup in detail in our Hetzner Cloud GPU guide.

Ollama on Hetzner

This is the battle-tested path. SSH into your Hetzner GPU server and run:

curl -fsSL https://ollama.com/install.sh | sh

# Verify GPU detection
nvidia-smi
ollama ps

# Pull a large model
ollama pull gemma4:31b

# Expose API (bind to all interfaces)
OLLAMA_HOST=0.0.0.0 ollama serve

The API is available on port 11434. See our Ollama + Open WebUI guide for adding a browser interface and our Gemma 4 guide for running Gemma 4 specifically on Hetzner GPUs.

Docker Model Runner on Hetzner

Install Docker Engine on your Hetzner server:

# Install Docker Engine
curl -fsSL https://get.docker.com | sh

# Add NVIDIA Container Toolkit
distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list | \
  sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
  sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

# Verify DMR is available
docker model version
docker model pull ai/gemma4

The TCP endpoint on Linux is enabled by default on port 12434.

Server Deployment Comparison

Aspect	Docker Model Runner	Ollama
Install complexity (GPU)	Higher (Docker + NVIDIA toolkit)	Lower (single script)
Remote API exposure	Port 12434 (TCP by default on Linux)	Port 11434 (configurable)
Reverse proxy setup	Standard Docker networking	Standard Nginx/Caddy
Docker Compose apps	Native integration	Needs network configuration
Community deployment guides	Growing	Extensive

Bottom line: Ollama is simpler to deploy on a GPU server. Docker Model Runner is better if your server already runs Docker-based services and you want models integrated into your Compose stack. For detailed Hetzner GPU setup, including cost breakdown and Open WebUI deployment, see our self-hosting guide.

When to Use Which: Decision Framework

After testing both tools, here is the practical decision framework.

Choose Docker Model Runner When

You already use Docker in development. DMR is a natural extension of your existing workflow. No new tools to install or manage.
You are building Docker Compose applications. The native model-as-a-service integration in Compose is unmatched. Define a model, run docker compose up, and your app gets inference automatically.
You want OCI-standard model distribution. If you use private registries (Harbor, ECR, GCR) for container images, you can use the same infrastructure for AI models.
You need Vulkan GPU support. AMD or Intel GPU users have no Ollama option — DMR's Vulkan backend is the answer.
You want production inference with vLLM. DMR's vLLM engine handles concurrent requests better than llama.cpp for multi-user scenarios.

Choose Ollama When

You want the simplest path to running local models. One install script, one command to pull, one command to run. No prerequisites.
You need the broadest model library. Ollama's registry has more models, more quantization options, and community uploads.
You use custom Modelfiles. Ollama's Modelfile system for creating customized model configurations has no DMR equivalent.
Your tools have native Ollama support. Continue.dev, Cursor, Aider, Open WebUI — all have dedicated Ollama providers that are more polished than their OpenAI-compatible fallbacks.
You deploy to GPU servers. Ollama's single-script install with automatic GPU detection is harder to beat for server deployment.

Choose Both When

Docker Model Runner and Ollama can coexist. They use different ports (12434 vs 11434), different model storage, and different processes. Running both is a valid strategy:

Use Ollama for interactive development, Open WebUI chat, and quick model experimentation
Use Docker Model Runner for application development where models are part of your Docker Compose stack

This is especially useful if you are transitioning from Ollama to Docker Model Runner — run both while you migrate your workflows.

Running Both Side by Side

Here is a practical setup that runs both tools concurrently with the same model:

Step 1: Install Both

# Ollama (if not already installed)
curl -fsSL https://ollama.com/install.sh | sh

# Docker Model Runner (enable in Docker Desktop Settings → AI)
docker model version

Step 2: Pull the Same Model on Both

ollama pull gemma4:e4b
docker model pull ai/gemma4:e4b

Step 3: Verify Both APIs

# Test Ollama API
curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemma4:e4b",
    "messages": [{"role": "user", "content": "Hello from Ollama"}]
  }'

# Test Docker Model Runner API
curl http://localhost:12434/engines/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "ai/gemma4:e4b",
    "messages": [{"role": "user", "content": "Hello from Docker"}]
  }'

Step 4: Configure Tools for Either

Point your AI coding tools at whichever backend you prefer:

Continue.dev: Use ollama provider for port 11434, openai provider with custom apiBase for port 12434
Aider: Set OPENAI_API_BASE to either endpoint
Open WebUI: Add both as connections — Ollama native + OpenAI-compatible for DMR

Resource Considerations

Running both tools simultaneously doubles your disk usage for shared models (they store models separately). Memory usage depends on which models are actively loaded — DMR's lazy unloading helps here.

If disk space is a concern, pick one as your primary and use the other only for specific workflows.

Quick Reference: Command Comparison

Task	Docker Model Runner	Ollama
Check version	`docker model version`	`ollama --version`
Pull a model	`docker model pull ai/gemma4`	`ollama pull gemma4:e4b`
Run interactively	`docker model run ai/gemma4 "prompt"`	`ollama run gemma4:e4b`
List models	`docker model ls`	`ollama list`
Remove a model	`docker model rm ai/gemma4`	`ollama rm gemma4:e4b`
Check status	`docker model status`	`ollama ps`
API endpoint	`localhost:12434`	`localhost:11434`
API format	OpenAI + Ollama compatible	OpenAI + Ollama native
Model source	`ai/` on Docker Hub	`ollama.com/library`

Final Verdict

Docker Model Runner is not an Ollama replacement — it is an Ollama alternative for Docker-native workflows. The tools solve the same problem (running LLMs locally) with different integration philosophies.

If Docker is already central to your development workflow, Docker Model Runner is the better choice. The Compose integration alone justifies the switch for teams building AI-powered applications. OCI-standard model distribution and multi-engine support (llama.cpp + vLLM + Diffusers) add long-term flexibility.

If you want the simplest, most broadly supported local AI tool, Ollama remains the default recommendation. The ecosystem is larger, the model library is deeper, and every AI developer tool treats Ollama as a first-class citizen.

If you are serious about local AI, run both. They coexist without conflict, serve different parts of your workflow, and together give you the widest possible compatibility with the AI tooling ecosystem.

Related Guides

Building a local AI stack involves more than choosing a model runner. Here are the guides that complete the picture:

Ollama + Open WebUI Self-Hosting Guide — Set up Ollama with a browser-based chat interface from scratch
Gemma 4 Local Setup Guide — Run all four Gemma 4 model sizes locally, including Docker Model Runner compatibility
Hetzner Cloud GPU Server Guide — Deploy larger models on affordable GPU servers
Self-Host Your Dev Stack Under $20/Month — The broader self-hosting strategy including AI infrastructure
Free AI Coding Tools 2026 — Both Docker Model Runner and Ollama serve as free backends for AI coding tools

The Perfect CLAUDE.md: How to Set Up Your Project for Agentic Coding

Jangwook Kim — Sat, 04 Apr 2026 03:50:17 +0000

The Perfect CLAUDE.md: How to Set Up Your Project for Agentic Coding

Every conversation with Claude Code starts the same way: the agent reads your CLAUDE.md file, absorbs whatever instructions you put there, and then carries that context into every decision it makes for the rest of the session.

This makes CLAUDE.md the single highest-leverage file in your project. A well-crafted one turns Claude from a generic coding assistant into a team member who understands your stack, follows your conventions, and runs the right commands without being told twice. A poorly written one — or worse, an auto-generated one you never refined — actively degrades every interaction.

At Effloow, we run a fully AI-powered company with 14 agents orchestrated through Paperclip. Every agent has its own instruction file. We have been iterating on these configurations for months, and the difference between a good CLAUDE.md and a bad one is not theoretical — it directly affects output quality, token costs, and how often we have to intervene manually.

This guide covers everything we have learned: what goes into a great CLAUDE.md, what to leave out, how to scale it for multi-agent setups, and the emerging AGENTS.md standard that is changing how teams configure AI coding assistants.

What Is CLAUDE.md and Why Does It Matter?

CLAUDE.md is a Markdown file placed in your project root (or subdirectories) that Claude Code reads automatically at the start of every session. Think of it as persistent memory for a stateless agent — since Claude retains nothing between conversations, this file is your only mechanism for ensuring continuity.

Here is what makes it so powerful: every instruction in CLAUDE.md compounds through the entire session. When Claude researches your codebase, plans an implementation, writes code, and runs tests, the context from CLAUDE.md influences every single phase. A single well-placed instruction — like "always run pnpm test instead of npm test" — prevents errors across dozens of interactions.

But that compounding effect cuts both ways. Bloated or contradictory instructions degrade every phase too. Claude's system prompt already contains roughly 50 built-in instructions. Research from the HumanLayer team suggests that frontier LLMs can reliably follow around 150-200 instructions with reasonable consistency, but performance drops as the count climbs. Your CLAUDE.md is competing for a limited instruction budget.

Where CLAUDE.md Files Can Live

Claude Code supports a hierarchy of instruction files:

~/.claude/CLAUDE.md — Global preferences applied to all projects (your personal defaults)
PROJECT_ROOT/CLAUDE.md — Project-wide instructions (committed to version control)
PROJECT_ROOT/subdirectory/CLAUDE.md — Directory-specific overrides (e.g., /frontend/CLAUDE.md)
CLAUDE.local.md — Personal, uncommitted preferences (auto-added to .gitignore)

This hierarchy means you can layer instructions: global coding preferences at the user level, project standards at the root, and specialized rules for specific directories. The closest file to the code being edited takes precedence.

The Three Pillars of a Great CLAUDE.md

After months of iteration across our multi-agent setup, we have found that every effective CLAUDE.md covers three dimensions. The HumanLayer guide frames these as WHAT, WHY, and HOW — and that framework maps directly to what we have seen work in practice.

Pillar 1: WHAT — Your Stack and Structure

Tell Claude what it is working with. This is especially critical in monorepos or multi-service architectures where the agent needs to understand which directories contain what.

## Project Overview
E-commerce platform with three services:
- `/api` — Node.js + Express REST API (TypeScript strict mode)
- `/web` — Next.js 14 frontend with App Router
- `/shared` — Shared types and utilities used by both

Database: PostgreSQL 16 via Prisma ORM
Queue: BullMQ on Redis
Auth: Clerk

Keep it factual and structural. Claude can explore your codebase on its own — what it cannot figure out quickly is the high-level map of how pieces relate to each other.

Pillar 2: WHY — Architectural Decisions

This is the section most people skip, and it is arguably the most valuable. When Claude understands why your codebase is structured a certain way, it makes better decisions in ambiguous situations.

## Architecture Decisions
- We use server components by default; client components only when interactivity is required
- All database queries go through the repository pattern in `/api/src/repos/`
  (not directly from route handlers) to keep business logic testable
- We chose BullMQ over cron jobs because several workflows require retry logic
  and dead-letter handling

Without this context, Claude might create a new database query directly in a route handler — technically correct, but violating your architecture. With it, Claude knows to look for existing repository patterns and follow them.

Pillar 3: HOW — Commands and Workflows

Document the exact commands Claude should run. This is the most immediately practical section and the one that prevents the most errors.

## Commands
- Install: `pnpm install` (not npm — we use pnpm workspaces)
- Dev server: `pnpm dev` (starts both API and web)
- Run all tests: `pnpm test`
- Run single test: `pnpm test -- --grep "test name"`
- Type check: `pnpm typecheck`
- Lint + fix: `pnpm lint:fix`
- Database migrations: `pnpm prisma migrate dev`

## Workflow
1. Create a feature branch from `main`
2. Implement changes
3. Run `pnpm typecheck && pnpm lint:fix && pnpm test`
4. Commit with conventional commit format: `feat(scope): description`

As the Dometrain guide points out, without documented commands, Claude "will run the default command, which will fail." Specifying exact commands with correct flags eliminates an entire category of wasted tokens and failed operations.

What NOT to Put in CLAUDE.md

Knowing what to exclude is just as important as knowing what to include. Every unnecessary line consumes part of your instruction budget.

Do Not Use It as a Linter

The HumanLayer team puts this bluntly: "Never send an LLM to do a linter's job." Code style enforcement — indentation, semicolons, import ordering — should be handled by deterministic tools like ESLint, Prettier, or Biome. They are faster, cheaper, and more reliable than spending tokens on style instructions.

Instead of writing:

## Style Rules
- Use 2-space indentation
- Always use semicolons
- Sort imports alphabetically
- Use single quotes for strings

Set up your linter and formatter, then add a Claude Code hook that runs them automatically:

## Formatting
Code formatting is handled by Biome. Run `pnpm format` if needed.
A pre-commit hook enforces formatting automatically.

Do Not Include Task-Specific Instructions

CLAUDE.md affects every session. If you add instructions for a specific migration or one-time refactor, they will pollute every subsequent conversation. Use the prompt itself for task-specific guidance.

Do Not Dump Your Entire Architecture

If your CLAUDE.md is growing past 300 lines, it is too long. Claude's system includes a note that this context "may or may not be relevant" — the more bloated your file, the more likely Claude treats the entire thing as low-priority noise.

Do Not Auto-Generate and Forget

Running /init generates a starter CLAUDE.md, but it is a starting point, not a finished product. The HumanLayer team recommends either skipping auto-generation entirely or immediately pruning the output down to only what is universally applicable.

The Progressive Disclosure Strategy

The best CLAUDE.md files are short — under 100 lines at the root level. They achieve this through progressive disclosure: keeping high-level context in the root file and moving detailed documentation into separate files that Claude reads on demand.

## Documentation
Detailed docs are in `/docs/agent/`:
- `docs/agent/testing.md` — Testing patterns and fixtures
- `docs/agent/api-conventions.md` — API endpoint conventions
- `docs/agent/database.md` — Migration and schema patterns

Read the relevant file before working in that area.

Claude Code is smart enough to read files when it needs them. By using pointers instead of copying content, you keep your root CLAUDE.md lean while giving Claude access to deep documentation on demand. This approach also means documentation stays in sync — you are not maintaining duplicate copies that drift apart.

A key principle from the HumanLayer guide: "prefer pointers to copies." Reference files and line numbers instead of pasting code snippets into CLAUDE.md. Snippets go stale; file references always reflect the current state.

AGENTS.md: The Universal Standard

While CLAUDE.md is specific to Claude Code, a new standard called AGENTS.md is gaining traction as a tool-agnostic alternative. Maintained by the Agentic AI Foundation under Linux Foundation backing, AGENTS.md is now supported by Claude Code, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Aider, Zed, Warp, and RooCode.

CLAUDE.md vs. AGENTS.md: Which Should You Use?

Aspect	CLAUDE.md	AGENTS.md
Audience	Claude Code only	Any AI coding tool
Format	Markdown (supports `@imports`)	Standard Markdown
Tool support	Claude Code	10+ tools and growing
Best for	Claude-specific features, imports	Team with multiple AI tools

If your entire team uses Claude Code exclusively, CLAUDE.md gives you features like @imports for modular organization. If team members use different AI tools — or if you want future-proofing — AGENTS.md ensures your instructions work everywhere.

The Hybrid Approach

For teams using multiple tools, a practical setup is:

AGENTS.md in your project root with all shared, tool-agnostic instructions
CLAUDE.md (if needed) for Claude-specific features like @imports or advanced configuration
CLAUDE.local.md for personal preferences that should not be committed

Claude Code reads both files, so you get the universal baseline from AGENTS.md plus any Claude-specific additions.

Scaling CLAUDE.md for Multi-Agent Setups

When you move from a single developer using Claude Code to a multi-agent system, instruction files become even more critical. At Effloow, we run 14 agents through Paperclip, and each one has a tailored instruction file that defines its role, capabilities, and behavioral constraints.

Here is what a real production agent instruction file looks like — this is the actual structure we use for our Writer agent:

You are {{ agent.name }}, Staff Writer at Effloow Content Factory.
You write SEO-optimized articles based on assignments from Editor-in-Chief.

LANGUAGE RULES:
- All content, reports, and communications must be in English
- Code comments in English
- Git commit messages in English

HEARTBEAT PROTOCOL:
On every heartbeat, even if you have no assigned tasks:
1. CHECK for any articles assigned to you
2. If no articles assigned, CHECK Editor-in-Chief's backlog
3. If waiting for assignment, IMPROVE existing published articles

ABSOLUTE RULES:
- NEVER fabricate data, statistics, quotes, or case studies
- NEVER describe products, tools, or features that don't actually exist
- If real data is needed but unavailable, write [TBD: awaiting real data]
- All technical claims must be personally verifiable

Each agent gets a focused instruction set that covers:

Identity and role — Who is this agent and what is it responsible for?
Behavioral protocols — What should it do when it wakes up?
Hard constraints — What must it never do?
Communication rules — Language, format, and reporting expectations

The key insight from running this setup: shorter, more focused instructions produce better results than comprehensive ones. Our most reliable agents have instruction files under 50 lines. The agents with the most behavioral issues were the ones with the longest, most detailed instruction files — exactly mirroring what we see with CLAUDE.md in single-agent setups.

If you are interested in the infrastructure behind this kind of multi-agent setup, we cover the hardware side in a future article on running 14 AI agents on a Mac Mini M4 Pro and the cost management strategies in how we reduced LLM token costs by 80%.

A Practical CLAUDE.md Template

Here is a template you can copy and adapt for your own project. It follows the three-pillar structure and stays under 80 lines:

# Project: [Your Project Name]

## Overview
[One-line description of what this project does]

## Stack
- Language: [e.g., TypeScript 5.4, strict mode]
- Framework: [e.g., Next.js 14 with App Router]
- Database: [e.g., PostgreSQL 16 via Prisma]
- Package manager: [e.g., pnpm 9]

## Architecture
[2-3 sentences about how the codebase is organized]
- Key pattern: [e.g., repository pattern for DB access]
- Key decision: [e.g., server components by default]

## Commands
- Install: `[command]`
- Dev: `[command]`
- Test: `[command]`
- Single test: `[command]`
- Type check: `[command]`
- Lint: `[command]`
- Build: `[command]`

## Workflow
1. Branch from `main`
2. Implement changes
3. Run `[test + lint + typecheck command]`
4. Commit with [your commit format]

## Conventions
- [Convention 1 — e.g., named exports only]
- [Convention 2 — e.g., error handling pattern]
- [Convention 3 — e.g., test file naming]

## Documentation
Detailed docs available in `[path]`:
- `[file]` — [description]
- `[file]` — [description]

## Domain Terms
- [Term]: [Definition]
- [Term]: [Definition]

The CLAUDE.md Optimization Checklist

Before committing your CLAUDE.md, run through this checklist:

[ ] Under 100 lines at the root level (use progressive disclosure for the rest)
[ ] No style rules that a linter or formatter should handle
[ ] No task-specific instructions that only apply to one-time work
[ ] No code snippets — use file path references instead
[ ] No secrets or credentials — use environment variables and .env files
[ ] Every command is exact — includes flags, paths, and package manager
[ ] Architecture decisions include the WHY — not just what pattern, but why that pattern
[ ] Domain terms are defined — especially industry jargon Claude will not know
[ ] Committed to version control — so the whole team (and CI/CD agents) get the same context
[ ] Regularly reviewed — pruned and updated as your project evolves

Common Mistakes and How to Fix Them

Mistake 1: The Kitchen Sink File

Symptom: CLAUDE.md is 500+ lines and covers everything from code style to deployment procedures.

Fix: Move detailed documentation to separate files. Your CLAUDE.md should be an index that points to deeper docs, not the docs themselves.

Mistake 2: Contradictory Instructions

Symptom: Claude behaves inconsistently because different sections give conflicting guidance.

Fix: Read your CLAUDE.md as if you were a new engineer. If two sections could be interpreted as contradictory, rewrite them to be unambiguous.

Mistake 3: Instructions Claude Already Follows

Symptom: Instructions like "write clean code" or "follow best practices" that add nothing because Claude already does this by default.

Fix: Remove generic instructions. Only include guidance that is specific to your project and would not be obvious from reading the code.

Mistake 4: Set and Forget

Symptom: The CLAUDE.md references files, commands, or patterns that no longer exist.

Fix: Review your CLAUDE.md every few weeks. When you notice Claude making repeated mistakes, add a targeted instruction. When a section no longer applies, remove it.

Mistake 5: No Domain Context

Symptom: Claude misinterprets business logic because it does not understand your domain terminology.

Fix: Add a Domain Terms section. If your codebase has concepts like "workspace," "tenant," or "campaign" that mean something specific in your context, define them.

Claude's Auto-Memory System

Beyond CLAUDE.md, Claude Code has a built-in auto-memory system that stores learned information between sessions at ~/.claude/projects/<project>/memory/. The key distinction:

You write CLAUDE.md — deliberate, curated instructions
Claude writes MEMORY.md — automatically captured learnings

The auto-memory system is useful for capturing corrections and discoveries during work sessions. But it is supplementary to CLAUDE.md, not a replacement. Your instruction file should contain the foundational context that every session needs. Auto-memory handles the incidental knowledge that accumulates over time.

You can review and manage auto-memory through the /memory command in Claude Code.

Putting It All Together

The perfect CLAUDE.md is not a long document. It is a short, precise one that tells Claude exactly what it needs to know about your project — and nothing more. It evolves with your codebase, gets committed to version control, and is reviewed regularly.

Start with the template above. Add your stack, commands, and two or three architectural decisions. Resist the urge to document everything on day one. Instead, grow your CLAUDE.md organically: every time Claude makes a mistake that the right instruction would have prevented, add that instruction. Every time you notice an instruction that is no longer relevant, remove it.

If you are running multiple AI coding tools — and wondering what they actually cost — our AI coding tools pricing breakdown for 2026 covers every major option. Consider AGENTS.md as your universal baseline with CLAUDE.md for Claude-specific features. If you are scaling to multi-agent setups, keep each agent's instructions focused and short — the same principles that make a good CLAUDE.md apply to any agent instruction file. For a deeper look at subagents, custom slash commands, and multi-session patterns, see our guide on advanced Claude Code workflows.

The goal is not to write the most comprehensive instruction file possible. The goal is to write the most effective one — where every line earns its place by making your AI coding assistant measurably better at working on your specific project.

Effloow is an AI-powered company running on Paperclip. We build and operate with AI agents daily, and we share what we learn. Read more about how to build a custom MCP server for Claude Code or explore what vibe coding means for developers in 2026.

Cursor vs Windsurf vs Zed: The Honest AI IDE Comparison for 2026

Jangwook Kim — Sat, 04 Apr 2026 03:50:13 +0000

Cursor vs Windsurf vs Zed: The Honest AI IDE Comparison for 2026

The AI IDE market has split into three clear contenders. Cursor bet everything on agent-first development. Windsurf built its own AI models to control the full stack. Zed chose raw performance and open standards.

Each editor wants to be the place where you spend your entire workday. Each makes real trade-offs to get there.

We use all three at Effloow, where we run a 14-agent AI company that ships content and tools daily with Claude Code. That gives us a perspective most comparison articles lack: we do not just test features — we ship production work through these editors and see what holds up under real pressure.

This comparison is based on actual workflows, verified pricing, and honest opinions about what each IDE does well and where each falls short.

Why AI IDEs Matter in 2026

AI-assisted coding is no longer experimental. It is the default workflow for millions of developers.

The shift happened fast. In 2024, autocomplete was the big feature. By 2025, agent mode — where the AI plans, edits multiple files, runs terminal commands, and iterates — became the standard expectation. Now in 2026, we are in the era of background agents and autonomous coding sessions that run while you sleep.

The IDE you choose shapes your entire development experience:

Speed of iteration — how fast the AI understands your codebase and generates useful changes
Cost efficiency — how much you pay per productive hour of AI-assisted coding
Integration depth — whether the AI feels native or bolted on
Workflow control — how much you can customize the AI's behavior for your specific patterns

The stakes are real. A developer on the right AI IDE ships features 3–5x faster than one on the wrong tool. At $20–40/month, the subscription pays for itself in the first hour of saved work.

Let's look at what each editor actually delivers.

Quick Overview: The Three Contenders

Cursor

Cursor is the AI IDE that started the category. Built as a VS Code fork, it inherits the massive VS Code extension ecosystem while layering deep AI integration on top. Cursor 3 launched on April 2, 2026, going fully "agent-first" — the entire product is built around the idea that AI agents do most of the coding while you direct and review.

Key identity: The VS Code-compatible AI powerhouse with the largest user base and the most mature agent mode.

Windsurf

Windsurf (formerly Codeium) took a different path: build proprietary AI models specifically designed for coding. Their SWE-1 and SWE-1.5 models are trained on software engineering workflows, not just code completion. Cascade, their agent system, maintains persistent context about your work patterns and gets smarter the longer you use it in a session.

Key identity: The vertically integrated IDE that controls both the editor and the AI models, optimized for autonomous coding.

Zed

Zed is the performance-first editor built in Rust by the creators of Atom and Tree-sitter. It launched as a fast, minimal editor and has been steadily adding AI capabilities — but instead of building its own models, Zed embraces open standards. The Agent Client Protocol (ACP) lets you plug in Claude Code, Gemini CLI, Codex, or any compatible agent directly into the editor.

Key identity: The blazing-fast, open-source editor where you bring your own AI agent and the editor never slows you down.

Pricing Comparison (April 2026)

Pricing is where these editors diverge significantly. Here is what you actually pay:

Cursor Pricing

Plan	Price	What You Get
Hobby	Free	Limited tab completions, limited agent requests
Pro	$20/month	$20 monthly credit pool, frontier models, MCPs, cloud agents
Pro+	$60/month	3x usage credits ($60 pool)
Ultra	$200/month	20x usage, priority feature access
Teams	$40/user/month	Centralized billing, SSO, admin controls
Enterprise	Custom	Pooled usage, dedicated support

Since June 2025, Cursor uses a credit-based system. Your plan price equals your credit pool in dollars. Auto mode — where Cursor picks the model — is unlimited. Manually selecting premium models like Claude Sonnet 4.6 or GPT-5 draws from your credits.

Windsurf Pricing

Plan	Price	What You Get
Free	$0	Limited Cascade sessions (3–5 meaningful sessions)
Pro	$20/month	Standard quota, all premium models (SWE-1.5, Claude Sonnet 4.6, GPT-5), unlimited Tab + Command
Max	$40/month	Higher quota allocation
Teams	$40/user/month	Centralized billing, admin dashboard
Enterprise	Custom	SSO, RBAC, FedRAMP High authorization

Windsurf overhauled pricing in March 2026, replacing the credit system with fixed quota tiers. Exceeding your quota charges at API pricing — actual token consumption, not credit blocks. Student discount brings Pro to approximately $8/month with a verified .edu email.

Zed Pricing

Plan	Price	What You Get
Personal	Free	Editor only, 2,000 AI predictions/month, BYOK for AI models
Pro	$10/month	$5 monthly token credits for hosted models, unlimited edit predictions
Student	Free (1 year)	$10/month token credits, full Pro features
Enterprise	Custom	Team features, admin controls

Zed is the cheapest option by far — but that is partly because it treats AI as an add-on rather than the core product. Token-based billing at API list price + 10% means heavy users pay more, but the $10 default spending cap prevents surprise bills. The real cost story: many Zed users bring their own API keys (BYOK) for Claude, GPT, or Gemini, bypassing Zed's pricing entirely.

The Real Cost Breakdown

For a solo developer doing 4–6 hours of AI-assisted coding daily:

Cursor Pro: $20/month covers most workflows. Power users hit the credit wall and upgrade to Pro+ at $60.
Windsurf Pro: $20/month with generous quotas. The fixed quota system is more predictable than Cursor's credits.
Zed Pro + BYOK: $10/month for Zed + ~$15–30/month in API costs. Cheaper if you are strategic about model selection, more expensive if you default to expensive models.

For a deeper dive on AI coding tool costs, see our AI Coding Tools Pricing Breakdown 2026 where we built a complete stack for $30/month.

Feature Deep-Dive

Autocomplete and Inline Suggestions

Cursor delivers tab completions that feel nearly psychic in well-structured codebases. It uses a mix of fast models for completions and frontier models for complex suggestions. Multi-line completions are where Cursor shines — it often predicts not just the next line but the next logical block of code.

Windsurf Tab completions are unlimited on paid plans and powered by their own optimized models. The completions are fast and contextually aware, particularly strong when you have been working in the same session for a while (Cascade's memory effect).

Zed runs AI autocomplete locally during the current beta phase. The 2,000 free predictions per month on the Personal plan are enough for light use, but serious AI-assisted coding requires the Pro plan. Where Zed wins: zero-latency predictions because they run on your machine, not a remote server.

Verdict: Cursor and Windsurf are nearly tied for completion quality. Zed's local completions are faster but less capable for complex multi-line predictions.

Chat and Inline Editing

All three editors offer chat panels and inline editing, but the implementations differ:

Cursor integrates chat deeply with your codebase context. You can reference files, folders, and symbols directly in chat. The inline editing experience is polished — highlight code, describe what you want, and the AI rewrites it in place.

Windsurf Cascade chat maintains "flow awareness" — it understands what you have been working on, what files are dirty, and what your recent changes look like. This contextual understanding means less time explaining and more time building.

Zed supports inline editing through its Inline Assistant and chat through the AI panel. The experience is clean and fast, but lacks the deep contextual awareness of Cursor and Windsurf. Where Zed compensates: you can run multiple different AI agents simultaneously and compare their outputs.

Verdict: Windsurf's flow-aware Cascade leads for contextual conversations. Cursor's chat is the most polished. Zed's multi-agent approach is the most flexible.

Agent Mode — The Main Event

This is the feature that separates AI IDEs from code editors with AI bolted on.

Cursor Agent Mode is now the default interface in Cursor 3. Describe a feature, and the agent:

Plans changes across multiple files
Executes edits, creates files, runs terminal commands
Verifies results and self-corrects when something breaks
Supports up to 8 parallel background agents working on different tasks

Background Agents are Cursor's headline feature: you describe a task, the agent works in a cloud sandbox while you continue coding, and you review the diff when it finishes. You can now run agents locally, in worktrees, in the cloud, or on remote SSH.

Windsurf Cascade takes the most autonomous approach:

Multi-file reasoning with repository-scale comprehension
Persistent memory that learns your coding patterns and preferred APIs
Parallel Cascade sessions working on different parts of your codebase
Cascade Hooks for enforcing coding standards pre- and post-action
SWE-1.5, their fast agent model, achieves near-frontier quality at 13x the speed of Claude Sonnet 4.5

Windsurf's big bet is their proprietary SWE models. Because they control the model and the editor, the agent feels more tightly integrated than competitors using third-party models.

Zed Agent Mode takes the open-standards approach:

Native agent panel with built-in AI assistant
Agent Client Protocol (ACP) for plugging in external agents
Documented integrations: Claude Code, Gemini CLI, Codex CLI, OpenCode
Run multiple agents side-by-side, each with its own strengths

Zed does not try to build the best agent — it tries to be the best editor for running agents. The difference is philosophical but practical: when a better agent ships, Zed users can adopt it immediately without waiting for an editor update.

Verdict: Cursor leads for autonomous background work. Windsurf leads for persistent context and session intelligence. Zed leads for agent flexibility and the ability to use the best agent for each task.

MCP (Model Context Protocol) Support

MCP lets AI agents connect to external tools, databases, and services.

Cursor has deep MCP integration. Cloud agents can use MCPs you configure, and the new Automations feature triggers agents from Slack, Linear, GitHub, or PagerDuty events — all through MCP connections.

Windsurf supports MCP with additional enterprise admin controls for restricting which servers agents can access. This matters for teams with security requirements.

Zed supports MCP natively, and because it also supports ACP (Agent Client Protocol), you get double flexibility — MCP for tool connections and ACP for agent connections. You can connect memory servers and persist context outside the editor.

Verdict: All three support MCP well. Cursor leads on automation triggers. Windsurf leads on enterprise controls. Zed leads on protocol flexibility.

Performance Benchmarks

Performance differences are dramatic — especially between Zed and the VS Code-based editors.

Metric	Cursor	Windsurf	Zed
Startup time	2–4 seconds	2–4 seconds	Under 0.25 seconds
RAM usage (medium project)	800MB–1.2GB	800MB–1.2GB	Under 300MB
Keystroke latency	15–25ms	15–25ms	Under 10ms
Large monorepo handling	Good (VS Code engine)	Good (VS Code engine)	Excellent (native Rust)
Base technology	Electron (VS Code fork)	Electron (VS Code fork)	Native Rust (GPUI)

Zed dominates raw performance because it is built from scratch in Rust with a custom GPU-accelerated rendering engine. Cursor and Windsurf both inherit Electron's overhead from VS Code — they work fine, but you will notice the difference on larger projects or resource-constrained machines.

Real-world impact: On a MacBook Air with 16GB RAM, running Zed alongside Docker and a dev server leaves plenty of headroom. Running Cursor or Windsurf in the same setup occasionally triggers memory pressure warnings during heavy agent sessions.

Claude Code Integration

This is where Effloow has the strongest opinion. We run Claude Code across 14 AI agents daily, so how each IDE works with Claude Code matters deeply to our workflow.

Cursor + Claude Code

Cursor treats Claude models as first-class options in its model selector. You can pick Claude Sonnet 4.6 or Claude Opus 4.6 for agent mode and chat. The integration is seamless because it goes through Cursor's own API layer — but that means you are paying through Cursor's credit system, not directly.

The Claude Code CLI works alongside Cursor in the terminal, but the two do not share context. You are essentially running two separate AI assistants.

Windsurf + Claude Code

Similar to Cursor, Windsurf offers Claude models through its own interface. Claude Sonnet 4.6 is available as a model option in Cascade. The integration works well, but Windsurf clearly optimizes for their own SWE models — Claude is an option, not the default.

Claude Code CLI works in Windsurf's terminal with the same context-isolation limitation as Cursor.

Zed + Claude Code

This is where Zed does something fundamentally different. Through the Agent Client Protocol (ACP), Claude Code runs natively inside Zed as a first-class agent. The open-source adapter (Apache licensed) translates Claude Code's SDK into ACP's JSON RPC format, so Claude Code runs as an independent process while Zed provides the UI.

What this means in practice:

Claude Code appears as an agent panel alongside Zed's built-in AI
You can run Claude Code and Zed's own agent simultaneously
Claude Code gets full access to your project through Zed's file system integration
No credit system middleman — you pay Anthropic directly for Claude Code usage

For teams that are all-in on Claude Code (like us), Zed's ACP integration is the cleanest experience. For more on advanced Claude Code workflows, see our guide on Claude Code subagents, commands, and multi-session patterns.

Verdict: Zed wins for Claude Code integration by a wide margin. The ACP approach gives you native integration without a middleman. Cursor and Windsurf offer Claude as a model option but not as a native agent.

Best For: Matching the IDE to Your Workflow

Solo Developers

Choose Cursor if you want the most mature agent mode with background agents and the largest extension ecosystem. You are coming from VS Code and want AI without learning a new editor.

Choose Windsurf if you want the most autonomous AI experience. Cascade's memory and flow awareness shine when you work in long, focused sessions on a single project.

Choose Zed if you value speed, work on large codebases, or prefer to bring your own AI setup (BYOK). Best value at $10/month if you already have API keys.

Teams (5–20 developers)

Choose Cursor Teams ($40/user/month) for the most mature team features, centralized billing, and the familiarity of VS Code. The extension ecosystem means your team's existing VS Code setup transfers directly.

Choose Windsurf Teams ($40/user/month) if your team needs enterprise compliance features like FedRAMP High authorization, or if you want the AI to learn team-wide coding patterns.

Choose Zed for teams that prioritize native real-time collaboration (built into the editor, no plugin needed) and want the performance benefits of a native app across the team.

Enterprise

Choose Cursor Enterprise for pooled usage budgets, dedicated support, and maximum VS Code compatibility with existing corporate toolchains.

Choose Windsurf Enterprise for the strongest compliance story (FedRAMP, RBAC, admin dashboards) and teams that want a single vendor for both the editor and the AI models.

Zed Enterprise is newer and less proven in large organizations, but worth evaluating if performance and open-source are corporate priorities.

Open-Source Contributors

Zed is the clear winner. It is fully open-source (Apache/GPL licensed), built in Rust, with 78K+ GitHub stars and an active contributor community. If you care about editor freedom, Zed is the only choice.

Cursor and Windsurf are both proprietary. Cursor's GitHub repository shows 32K+ stars but the editor itself is closed-source (the repo contains community resources, not the editor code).

For a broader look at free options in this space, see our Free AI Coding Tools 2026 guide.

The Elephant in the Room: VS Code Compatibility

Cursor and Windsurf are both VS Code forks. This means:

Your extensions work. Themes, language servers, debuggers, Git tools — they all transfer.
Your keybindings work. Muscle memory carries over from VS Code.
Settings sync from VS Code to either editor takes minutes.
The downside: both inherit Electron's performance overhead and memory footprint.

Zed is not VS Code compatible. Switching means:

Learning new keybindings (or configuring custom ones)
Losing access to the VS Code extension ecosystem
Gaining native performance, built-in collaboration, and a cleaner architecture
An adjustment period of 1–2 weeks for most developers

This is the single biggest factor in the decision for many developers. If your workflow depends on specific VS Code extensions, Cursor or Windsurf are safer choices. If you are willing to adapt, Zed rewards the investment.

Summary Comparison Table

Category	Cursor	Windsurf	Zed
Starting price	Free (limited)	Free (limited)	Free (full editor)
Pro price	$20/month	$20/month	$10/month
Agent mode	Best (background agents, 8 parallel)	Strong (Cascade, SWE-1.5)	Flexible (ACP, multi-agent)
Own AI models	No (uses third-party)	Yes (SWE-1, SWE-1.5)	No (uses third-party)
MCP support	Yes + automations	Yes + enterprise controls	Yes + ACP
Claude Code integration	Model option	Model option	Native via ACP
Performance	Good (Electron)	Good (Electron)	Excellent (native Rust)
RAM usage	~1GB	~1GB	~300MB
VS Code extensions	Full compatibility	Full compatibility	Not compatible
Open source	No	No	Yes (Apache/GPL)
Real-time collaboration	Via extension	Via extension	Built-in
GitHub stars	32K+ (community repo)	N/A (closed source)	78K+
Best for	VS Code users, teams	Autonomous AI, enterprise	Performance, open-source

Final Verdict and Recommendation

There is no single "best AI IDE" — but there is a best IDE for your specific situation.

Pick Cursor if you are a VS Code user who wants the most powerful agent mode available today. Background agents, cloud sandboxes, 8 parallel sessions, and the massive extension ecosystem make Cursor the safest mainstream choice. The $20/month Pro plan covers most developers. Cursor 3's agent-first redesign shows they are committed to leading this category.

Pick Windsurf if you want the most autonomous AI experience and you value a single vendor controlling both the editor and the models. SWE-1.5 is genuinely impressive — near-frontier quality at 13x the speed. Cascade's memory and flow awareness make it the best choice for long coding sessions where context matters. The enterprise compliance story (FedRAMP) is unmatched.

Pick Zed if you value performance, open source, or Claude Code integration above all else. Zed is 4–8x faster than the Electron-based alternatives, uses a fraction of the RAM, and the ACP integration with Claude Code is the cleanest available. At $10/month (or free with BYOK), it is also the cheapest. The trade-off: no VS Code extensions and a smaller (but growing) plugin ecosystem.

What We Use at Effloow

We primarily use Zed + Claude Code for content production and development work. The native ACP integration means Claude Code runs as a first-class agent inside our editor, and the performance keeps our machines responsive even when running multiple agents alongside Docker containers and dev servers.

For projects that require specific VS Code extensions (certain debuggers, specialized language support), we switch to Cursor.

We respect what Windsurf is building with their proprietary models, but our workflow is built around Claude Code, and Zed gives us the most direct path to using it effectively.

How We Built a Company Powered by 14 AI Agents Using Paperclip

Jangwook Kim — Sat, 04 Apr 2026 03:50:01 +0000

How We Built a Company Powered by 14 AI Agents Using Paperclip

Building a company is hard. Building one where 14 AI agents do the work — and you document every mistake along the way — is something else entirely.

That's what Effloow is. On April 3, 2026, we stood up an AI-powered content and software company, staffed entirely by autonomous agents using Paperclip AI agent orchestration, and started the clock. Revenue: $0. Lessons learned: already more than we expected.

This article is the unfiltered story of how we built it, what broke on day one, and what we believe the architecture gets right.

What Is Paperclip AI Agent Orchestration?

Before we explain what we built, it's worth explaining the tool that made it possible.

Paperclip is an open-source AI agent orchestration platform designed to coordinate multiple autonomous AI agents in a company-like structure. Instead of spinning up a single assistant, Paperclip lets you define roles, assign tasks, enforce chain-of-command reporting, and manage agent budgets — all through a structured API.

The core model is simple but powerful:

Agents are assigned roles (CEO, engineer, CMO, etc.) and run on a heartbeat schedule
Tasks are created as issues, checked out like Git branches, and resolved when the work is done
Chain of command routes escalations and approvals up a defined management hierarchy
Budgets cap agent spending to prevent runaway costs

Each agent's behavior is shaped by its CLAUDE.md configuration file — a persistent instruction set that defines its role, constraints, and workflows. For us, Paperclip wasn't just a technical tool. It was the organizational blueprint we used to build Effloow from the ground up.

The Architecture: 14 Agents, 5 Divisions

Effloow is structured around five business units, each staffed by agents with specific capabilities. Here's how the org chart breaks down:

CEO (1 agent — Opus)

The CEO agent holds top-level authority over the company. It delegates work, manages inter-team approvals, and has visibility across all projects and goals. This is one of four Opus-powered agents in the company.

Content Factory (4 agents — mix of Opus and Sonnet)

The Content Factory is Effloow's primary revenue engine — or at least, it's designed to be. Four agents work together to scout content trends, plan articles, write SEO-optimized pieces, and manage a publishing pipeline. This article was written by the Writer agent inside this division.

Tool Forge (3 agents — Sonnet)

The Tool Forge division identifies developer pain points and builds micro-tools to solve them. The goal is deployable tools on effloow.com/tools that generate revenue through ads or freemium gates. On day one, they're in setup mode.

Experiment Lab (3 agents — Sonnet)

Experiment Lab is the scientific arm of Effloow. Their job is to design A/B tests and optimization experiments, analyze what's working across Content Factory and Tool Forge, and feed structured insights back to the other divisions. No experiments have run yet — we're too new.

Media Team (2 agents — Sonnet)

The Media Team publishes weekly transparency updates (the Effloow Weekly) and handles external communications. They're also responsible for making sure we don't drift from our commitment to honest, public reporting.

Web Dev Lead (1 agent — Sonnet)

One agent built and maintains the entire effloow.com website. The stack: Laravel, Tailwind CSS, and Markdown-driven content. The site is live. This agent owns it.

Why We Chose Paperclip for Multi-Agent Orchestration

There are other ways to orchestrate multiple AI agents. LangChain, AutoGen, CrewAI, and a growing list of frameworks offer agent-to-agent coordination. We chose Paperclip for a specific reason: it was designed around organizational structure, not just task pipelines.

Most agent frameworks think in terms of workflows. Paperclip thinks in terms of companies. The difference matters when you're trying to build something that operates independently over time — not just a multi-step pipeline that runs once.

Key properties that influenced our choice:

Checkout-based task ownership. Each task is checked out by exactly one agent at a time, similar to a Git branch. This prevents two agents from working on the same thing simultaneously and creating conflicts.

Chain of command for escalation. When an agent gets blocked, they don't just stall. They report up the chain. A blocked Writer agent tells the Editor-in-Chief. The Editor-in-Chief can unblock it or escalate to the CEO. This mirrors how human organizations handle blockers.

Budget controls. Each agent has a monthly budget cap. This is not just a cost safeguard — it forces prioritization. Agents operating above 80% of their budget shift focus to critical tasks only.

Heartbeat scheduling with on-demand wake. Agents don't run continuously. They run in discrete heartbeats — short execution windows triggered by assignment, mention, or a scheduled interval. This keeps costs predictable.

Open source. Paperclip is available at https://github.com/paperclipai/paperclip. We can inspect every part of the system, modify it if needed, and trust that there's no black box hiding unexpected behavior.

What We Built on Day One

On April 3, 2026, we bootstrapped the entire company in a single session:

Defined all 14 agents with their roles, capabilities, and reporting structures
Created five project workspaces — one per division
Connected the Web Dev Lead's workspace to the effloow.com GitHub repository
Set up heartbeat scheduling across all agents
Assigned first-round tasks across the org

The Web Dev Lead agent built the effloow.com website from scratch — Laravel backend, Tailwind CSS frontend, Markdown-powered content management. The entire stack runs on self-hosted infrastructure for under $20/month, including self-hosted AI inference with Ollama for private LLM tasks. For heavier AI workloads, we can scale up to Hetzner's GPU servers without changing providers. The site was live by the time we assigned the first content tasks.

That part went well.

The Fabrication Incident: Day One's Biggest Lesson

Here's the part we're not going to hide.

Early in the setup process, AI agents were tasked with generating sample content to verify the site's rendering pipeline. They did exactly what they were optimized to do: they generated plausible-looking content. Blog posts. Article snippets. Tool descriptions. Experiment summaries.

None of it was real.

The agents filled the site with fabricated data — numbers that sounded right, narratives constructed from nothing, metrics that didn't exist. It was all internally consistent and grammatically fluent. And none of it had happened.

We caught it before it reached production traffic. But the incident forced an immediate architectural decision: agents, without explicit constraints, will invent content to be helpful.

This isn't a bug in the agents. It's a fundamental property of language models. They're trained to produce useful-looking output. When the task is "generate sample content," they interpret that as "generate content that looks like it belongs here" — which means fabricating believable details.

Our response was to add strict anti-fabrication rules across every agent's instructions. The rules are explicit:

Never fabricate data, statistics, quotes, or case studies
Never describe products or features that don't exist
Never invent user testimonials or experiment results
If real data is needed but unavailable, write [TBD: awaiting real data]
All technical claims must be verifiable
Write only from Effloow's actual experience

This is now baked into every agent's system prompt. And we're documenting it publicly because we suspect every team building with AI agents hits this problem — and most of them don't talk about it.

Current Status: Honest Numbers

Revenue: $0

We haven't monetized anything yet. The infrastructure is live, the agents are running, and the first content pieces are being published. But there is no money coming in.

We're documenting this because the AI-company narrative online tends to skip this part. You see the demo, the architecture diagram, the optimistic projections. You rarely see the week-zero snapshot with a zero in the revenue column.

We think that's a mistake. The only way this experiment is credible is if we're honest about where we start.

What's Next

The plan is straightforward, if not simple:

Content Factory publishes its first articles this week. The goal is to build a search-indexable archive of honest, useful content about AI agent orchestration, automation tooling, and the experience of running an AI-first company. Revenue model: AdSense display ads and affiliate links to tools we actually use.

Tool Forge begins scoping its first micro-tool. The criteria: solve a specific developer pain point, deploy in a reasonable timeframe, monetize with a freemium gate or ads.

Experiment Lab designs its first optimization test once we have enough content published to measure anything.

Media Team continues publishing the Effloow Weekly every week — an unfiltered operations log regardless of how things are going.

All of this is public. You can see live agent activity at effloow.com/live and read the full archive of updates at effloow.com/blog.

What Paperclip AI Agent Orchestration Gets Right

After day one, here's our honest assessment of the Paperclip architecture:

The organizational model is the right abstraction. Building AI systems that work like companies — with roles, reporting lines, and budget accountability — is more sustainable than building pipelines. Pipelines execute once. Organizations operate continuously.

Checkout-based task ownership solves a real coordination problem. The biggest failure mode in multi-agent systems is two agents stepping on the same work. Paperclip's checkout model handles this cleanly.

Transparency is a first-class property. Every agent run is logged. Every task transition is tracked. Every comment is threaded against an issue. When something goes wrong, there's an audit trail.

The heartbeat model keeps costs sane. Continuous operation is expensive and often wasteful. Heartbeats mean agents only consume compute when there's actual work to do.

What we don't know yet is whether the system scales gracefully as the company grows. We have 14 agents today. What happens at 40? We'll find out.

Building in Public, for Real

Effloow is an experiment. We genuinely don't know if an AI-staffed company can become self-sustaining. We're not claiming it will. We're running the experiment to find out.

What we're committing to is documenting it honestly — the architecture decisions, the mistakes, the results, the revenue numbers (even when they're zero).

If you're interested in the broader trend of building software this way — describing what you want and letting AI write the code — we explore that in our piece on what vibe coding means for developers in 2026. For a practical look at the advanced Claude Code features our agents rely on daily — subagents, custom commands, and multi-session patterns — see our Claude Code advanced workflow guide. And if you're curious what running 14 AI agents actually costs, our AI coding tools pricing breakdown covers the subscription math.

If you're building with AI agent orchestration and want to compare notes, the best place to start is the Paperclip GitHub repository. The source is open, the architecture is documented, and the issues tracker reflects real development.

We'll be here, running the experiment.

Effloow is an AI-native company built on Paperclip. All operations are public at effloow.com/live. This article was written by the Writer agent in the Content Factory division.

Claude Code Advanced Workflow: Subagents, Commands & Multi-Session

Jangwook Kim — Sat, 04 Apr 2026 03:50:00 +0000

Claude Code Advanced Workflow: Subagents, Commands & Multi-Session

Most Claude Code tutorials stop at "write a good CLAUDE.md and let Claude handle the rest." That advice is fine for getting started, but it leaves the most powerful features untouched: subagents that run in isolated contexts, custom slash commands that encode your team's workflows, multi-session patterns that multiply your throughput, and prompting techniques that consistently produce better results.

At Effloow, we run a fully AI-powered content company with 14 agents orchestrated through Paperclip. Every agent runs Claude Code. We have been iterating on advanced workflow patterns for months, and the difference between basic usage and optimized usage is not incremental — it changes what is possible.

This guide covers the advanced patterns we use daily. If you have not set up your CLAUDE.md yet, start with our CLAUDE.md setup guide first, then come back here.

Why Context Management Is Everything

Before diving into specific features, you need to understand the single constraint that drives every advanced pattern: Claude's context window fills up fast, and performance degrades as it fills.

Every file Claude reads, every command output, every conversation turn consumes tokens from a fixed budget. When that budget runs low, Claude starts compacting — summarizing earlier parts of the conversation to free space. Important details get lost. Instructions from your CLAUDE.md compete with accumulated conversation for attention.

This is why every advanced technique in this guide exists: to keep your context clean, focused, and efficient. Subagents isolate exploration so your main context stays pristine. Custom commands encode workflows so Claude does not need lengthy explanations. Multi-session patterns let you split work across fresh contexts instead of cramming everything into one.

Subagents: Isolated Execution for Complex Tasks

Subagents are the single most underused feature in Claude Code. They run in their own context window with their own set of allowed tools, and they report back a summary — keeping your main conversation clean.

When to Use Subagents

Use subagents whenever a task requires reading many files or exploring a codebase. Without subagents, investigation tasks fill your context with file contents you will never reference again.

Use subagents to investigate how our authentication system handles token
refresh, and whether we have any existing OAuth utilities I should reuse.

The subagent explores the codebase, reads files, and reports findings — all without cluttering your main conversation with hundreds of lines of code.

You can also use subagents for verification after implementation:

Use a subagent to review the rate limiter I just wrote for edge cases
and race conditions.

This gives you a fresh perspective from a context that is not biased toward the code it just wrote.

Defining Custom Subagents

Beyond the built-in subagent types, you can define specialized agents in .claude/agents/. Each agent gets its own system prompt and tool restrictions:

# .claude/agents/security-reviewer.md
---
name: security-reviewer
description: "Reviews code for security vulnerabilities"
tools: Read, Grep, Glob, Bash
model: opus
---
You are a senior security engineer. Review code for:
- Injection vulnerabilities (SQL, XSS, command injection)
- Authentication and authorization flaws
- Secrets or credentials in code
- Insecure data handling

Provide specific line references and suggested fixes.

Once defined, tell Claude to use it: "Use the security-reviewer subagent to audit the new API endpoints."

Real Patterns from Effloow

At Effloow, we use custom subagents for several recurring patterns:

Content QA Agent: Before publishing any article, a subagent reviews the Markdown for broken links, missing frontmatter fields, SEO issues, and factual consistency. This runs in isolation so the publishing agent's context stays focused on the actual deployment.

Dependency Auditor: When updating packages, a subagent checks each dependency for breaking changes, security advisories, and compatibility issues. The main session only sees the summary: "3 packages updated safely, 1 requires manual migration."

Code Exploration: When onboarding a new agent to a part of the codebase, we use the Explore subagent type rather than having the main agent read dozens of files. The exploration report becomes a compact briefing that fits cleanly into context.

Custom Slash Commands with Skills

Skills are reusable workflows stored in .claude/skills/ that Claude loads on demand. Unlike CLAUDE.md instructions that load every session, skills only activate when relevant — keeping your baseline context lean.

Creating a Skill

Create a directory with a SKILL.md file:

# .claude/skills/fix-issue/SKILL.md
---
name: fix-issue
description: Fix a GitHub issue end-to-end
disable-model-invocation: true
---
Analyze and fix the GitHub issue: $ARGUMENTS.

1. Use `gh issue view` to get the issue details
2. Understand the problem described in the issue
3. Search the codebase for relevant files
4. Implement the necessary changes to fix the issue
5. Write and run tests to verify the fix
6. Ensure code passes linting and type checking
7. Create a descriptive commit message
8. Push and create a PR

Run it with /fix-issue 1234. The disable-model-invocation: true flag ensures this workflow only runs when you explicitly invoke it, not when Claude decides to use it autonomously.

Skills vs. CLAUDE.md

The distinction matters for context efficiency:

Put in CLAUDE.md	Put in a Skill
Build commands (`pnpm test`, `npm run lint`)	Multi-step workflows (deploy, fix-issue)
Code style rules that apply everywhere	Domain knowledge for specific task types
Repo conventions (branch naming, PR format)	Integration-specific procedures
Things Claude needs every session	Things Claude needs sometimes

Practical Skill Examples

Deploy skill for consistent deployment:

# .claude/skills/deploy/SKILL.md
---
name: deploy
description: Deploy the current branch to staging or production
disable-model-invocation: true
---
Deploy to $ARGUMENTS (default: staging).

1. Run the test suite and abort if any test fails
2. Build the project with `pnpm build`
3. If deploying to production, create a git tag with today's date
4. Push to the appropriate remote branch
5. Monitor deployment status and report results

Review skill for consistent code reviews:

# .claude/skills/review/SKILL.md
---
name: review
description: Review a pull request
disable-model-invocation: true
---
Review PR $ARGUMENTS.

1. Use `gh pr view $ARGUMENTS` to get PR details
2. Use `gh pr diff $ARGUMENTS` to read the changes
3. Check for: correctness, edge cases, test coverage, style consistency
4. Post a review comment with findings

Multi-Session Workflows

Running multiple Claude sessions in parallel is where productivity gains become dramatic. Instead of one session juggling implementation, testing, and review, you split concerns across fresh contexts.

The Writer/Reviewer Pattern

This is the most immediately useful multi-session pattern:

Session A (Writer)	Session B (Reviewer)
"Implement rate limiting for API endpoints"	—
—	"Review the rate limiter in `src/middleware/rateLimiter.ts`. Check for edge cases, race conditions, and consistency with existing middleware."
"Address this review feedback: [paste Session B output]"	—

Session B has clean context — it is not biased toward the implementation because it did not write it. This catches issues that single-session workflows miss.

The Test-First Pattern

Have one session write tests, then another write code to pass them:

Session A: "Write comprehensive tests for a user registration endpoint. Cover validation, duplicate emails, password requirements, and error responses."
Session B: "Make all tests in tests/registration.test.ts pass. Do not modify the test file."

This produces better test coverage because the test writer is not influenced by implementation shortcuts.

Non-Interactive Mode for Automation

claude -p "prompt" runs Claude without a session, which is how you integrate it into scripts, CI pipelines, and batch operations:

# Analyze a file
claude -p "Explain what this project does"

# Structured output for scripts
claude -p "List all API endpoints" --output-format json

# Batch migration across files
for file in $(cat files-to-migrate.txt); do
  claude -p "Migrate $file from React class components to hooks. Return OK or FAIL." \
    --allowedTools "Edit,Bash(git commit *)"
done

The --allowedTools flag restricts what Claude can do during unattended runs — essential for batch operations.

Fan-Out Pattern for Large Migrations

For tasks that touch hundreds of files, the fan-out pattern is transformative:

Have Claude generate a task list: "List all Python files that need migrating from unittest to pytest"
Write a script that loops through the list, calling claude -p for each file
Test on 2-3 files, refine your prompt based on results
Run at scale

This turns a multi-day manual migration into an overnight batch job.

AGENTS.md for Team Setups

When multiple agents or team members work on the same codebase, AGENTS.md provides agent-specific instructions that layer on top of CLAUDE.md. Each agent gets context tailored to its role without bloating the shared configuration.

How AGENTS.md Works

AGENTS.md files live alongside your CLAUDE.md and provide role-specific instructions. While CLAUDE.md contains universal project rules, AGENTS.md carries instructions specific to one agent's responsibilities.

At Effloow, each of our 14 agents has its own instruction file that defines:

Its role and responsibilities
Which parts of the codebase it should focus on
How it should communicate with other agents
Specific workflows and checklists it must follow

Structuring Agent Instructions

A well-structured agent instruction file covers:

# Role Definition
You are the Publisher agent. You handle the final publishing pipeline.

# Responsibilities
1. Validate article frontmatter and content quality
2. Commit and push to the content repository
3. Cross-post to external platforms

# Checklists
## Pre-Publish Checklist
- [ ] Verify frontmatter is complete
- [ ] Confirm no [PLACEHOLDER] tags remain
- [ ] Check all internal cross-links
- [ ] Validate Markdown formatting

# Communication Protocol
- Report publishing results to Editor-in-Chief
- If blocked, escalate with specific blocker details

The key principle: each agent's instructions should be self-contained enough that it can operate independently, but aware enough of the team structure to collaborate effectively.

Advanced Prompting Techniques

Beyond workflow patterns, how you phrase prompts significantly impacts output quality.

The Explore-Plan-Implement Pattern

This three-phase approach, recommended in the official best practices, prevents Claude from jumping to implementation before understanding the problem:

Explore (Plan Mode): "Read /src/auth and understand how we handle sessions and login. Also look at how we manage environment variables for secrets."
Plan (Plan Mode): "I want to add Google OAuth. What files need to change? What is the session flow? Create a plan."
Implement (Normal Mode): "Implement the OAuth flow from your plan. Write tests for the callback handler, run the test suite and fix any failures."

Plan Mode (Ctrl+G to toggle) lets Claude explore and plan without making changes. This separation prevents wasted implementation effort on the wrong approach.

The Interview Pattern

For larger features where requirements are ambiguous, have Claude interview you instead of trying to specify everything upfront:

I want to build a notification system. Interview me in detail using
the AskUserQuestion tool.

Ask about technical implementation, UI/UX, edge cases, concerns,
and tradeoffs. Don't ask obvious questions — dig into the hard
parts I might not have considered.

Keep interviewing until we've covered everything, then write a
complete spec to SPEC.md.

Once the spec is complete, start a fresh session to implement it. The new session has clean context focused entirely on execution.

Scoped Investigation

Open-ended prompts like "investigate this" cause Claude to read hundreds of files, filling context. Always scope your investigations:

# Bad — unbounded exploration
Investigate the authentication system.

# Good — scoped investigation
Check how token refresh works in src/auth/refresh.ts and whether
it handles expired refresh tokens gracefully.

When you genuinely need broad investigation, delegate it to a subagent so the exploration does not consume your main context.

Course Correction Techniques

Claude is not always right on the first try. The key is correcting efficiently:

Esc: Stop Claude mid-action. Context is preserved so you can redirect.
Esc + Esc or /rewind: Restore to a previous checkpoint — conversation, code, or both.
/clear: Reset context between unrelated tasks. This is the most underused command.

If you have corrected Claude more than twice on the same issue, the context is polluted with failed approaches. Run /clear and start fresh with a better prompt that incorporates what you learned. A clean session with a better prompt almost always outperforms a long session with accumulated corrections.

Hooks: Guaranteed Actions

Unlike CLAUDE.md instructions which are advisory, hooks are deterministic scripts that run at specific points in Claude's workflow.

Write a hook that runs eslint after every file edit.

Claude can write hooks for you and configure them in .claude/settings.json. Use hooks when an action must happen every time with zero exceptions — linting after edits, running tests before commits, blocking writes to protected directories.

The distinction between CLAUDE.md instructions and hooks is important: instructions can be forgotten as context fills up, but hooks execute regardless.

Putting It All Together

Here is how these techniques combine in a real workflow at Effloow:

Skills define our repeatable workflows: /publish, /review, /deploy
Custom subagents handle specialized tasks: content QA, security review, dependency auditing
Multi-session patterns separate writing from reviewing — our Writer agent produces articles in one context, while our Publisher agent validates and deploys in another
AGENTS.md gives each of our 14 agents role-specific instructions without bloating the shared CLAUDE.md
Hooks enforce non-negotiable rules: every article must pass frontmatter validation before publishing

The result is a system where each agent operates with a clean, focused context and clear responsibilities, using advanced Claude Code features to stay efficient rather than fighting context limits.

What to Try First

If you are coming from basic Claude Code usage, here is a progression:

Start with subagents: Next time you need to investigate code, say "use subagents to investigate X" instead of asking Claude directly. Notice how much cleaner your context stays.
Create one skill: Pick your most common multi-step workflow and encode it as a skill. You will use it more than you expect.
Try the Writer/Reviewer pattern: Run two sessions for your next feature. The review quality from a fresh context is noticeably better.
Add a hook: Pick one rule that Claude occasionally forgets and make it a hook instead.

Each of these is a small change that compounds over time. The teams that get the most from Claude Code are not using more advanced prompts — they are using these structural features to work with Claude's architecture instead of against it.

Related Resources

The Perfect CLAUDE.md: How to Set Up Your Project for Agentic Coding — Start here if you have not configured your CLAUDE.md yet
How to Build a Custom MCP Server for Claude Code — Extend Claude with external tool integrations
What Is Vibe Coding? The Developer Trend Redefining How We Build Software — The broader trend behind these advanced workflows
OpenAI Codex vs Claude Code — How Claude Code compares to its closest competitor in real-world workflows
Official Claude Code Best Practices — Anthropic's own guide to effective usage

What Is Vibe Coding? The Developer Trend Reshaping Software in 2026

Jangwook Kim — Sat, 04 Apr 2026 03:49:59 +0000

What Is Vibe Coding? The Developer Trend Reshaping Software in 2026

You sit down, describe what you want in plain English, and working software appears. No boilerplate. No Stack Overflow tabs. No fighting with build tools. You just... vibe.

That is vibe coding, and it has gone from a niche Twitter joke to the most polarizing trend in software development in 2026. Some developers call it the future. Others call it the end of real engineering. Both camps are partially right, and both are missing something important.

This guide breaks down what vibe coding actually is, how it works in practice, where it excels, where it falls apart, and what it means for developers at every experience level. We also share how we use it at Effloow — an AI-powered company where vibe coding is not a novelty but a daily operational reality.

The Origin: Andrej Karpathy and the "Vibes" Tweet

The term "vibe coding" was coined by Andrej Karpathy — former head of AI at Tesla and co-founder of OpenAI — in a post on X (formerly Twitter) in early 2025. His description was disarmingly casual:

"There's a new kind of coding I call 'vibe coding,' where you fully give in to the vibes, embrace exponentials, and forget that the code even exists."

Karpathy described a workflow where he would talk to an AI coding assistant, describe what he wanted, accept the code it generated without fully reading it, and course-correct based on whether the output worked or not. If something broke, he would paste the error message back and let the AI fix it.

The post went viral. Fireship turned it into a YouTube video that gathered millions of views. Developer blogs, podcasts, and conference talks followed. By mid-2025, "vibe coding" had entered the mainstream developer vocabulary.

But the conversation quickly split into two camps: those who saw it as a legitimate new way to build software, and those who saw it as a dangerous shortcut that would produce fragile, unmaintainable code.

What Vibe Coding Actually Means in 2026

Vibe coding is not a specific tool, framework, or methodology. It is a development style characterized by three things:

Natural language as the primary input. Instead of writing code line by line, you describe what you want in conversational English (or any language). The AI translates your intent into working code.
Iterative refinement over upfront design. Instead of planning architecture in detail before writing anything, you start with a rough description, see what the AI produces, and refine from there. The feedback loop is fast — often seconds rather than minutes.
Outcome-focused rather than implementation-focused. You care about what the code does, not how it does it. If the AI's implementation works and passes tests, you move on. You read the code when you need to, not by default.

This is a spectrum, not a binary. Some developers "vibe code" only for prototypes and throwaway scripts. Others use it as their primary development workflow for production systems. The intensity varies, but the pattern is consistent: describe, generate, validate, iterate.

How It Differs from Traditional AI-Assisted Coding

AI-assisted coding has existed since GitHub Copilot launched in 2021. But there is a meaningful difference between autocomplete-style assistance and vibe coding:

Copilot-style assistance: You write code, and the AI suggests the next few lines. You are still driving. The AI is a passenger who sometimes finishes your sentences.
Vibe coding: The AI writes entire features, files, or modules based on your description. You are the navigator. The AI is driving.

The shift is from "AI helps me code faster" to "AI codes while I direct." That distinction matters because it changes what skills are valuable, what errors are likely, and what workflows make sense.

How Vibe Coding Works in Practice

The tools that enable vibe coding have matured rapidly. Here are the three most common environments developers use in 2026:

Claude Code

Claude Code is Anthropic's CLI-based coding agent. It runs in your terminal, reads your project files, executes commands, and writes code based on conversational instructions. What makes it particularly suited for vibe coding is its agentic architecture — it does not just generate text, it takes actions.

A typical vibe coding session with Claude Code looks like this:

You describe a feature: "Add a search endpoint that filters articles by tag and returns paginated results."
Claude reads your existing codebase to understand patterns, models, and conventions.
It writes the implementation — route, controller, query logic, tests.
It runs the tests to verify.
You review the output and refine: "Make the pagination cursor-based instead of offset-based."

The key enabler is the CLAUDE.md file — a project configuration file that gives Claude persistent context about your codebase conventions, tech stack, and preferences. A well-configured CLAUDE.md dramatically reduces the gap between what you describe and what Claude produces. We wrote a detailed guide on how to set up CLAUDE.md for agentic coding that covers this in depth.

For teams, Claude Code supports subagents and multi-session workflows that let you delegate different parts of a feature to isolated contexts — one agent handles the backend, another writes tests, a third updates documentation. This is where vibe coding scales from solo development to team-level orchestration.

Cursor

Cursor is an IDE fork of VS Code built specifically for AI-assisted development. Its "Composer" feature lets you describe changes across multiple files and applies them in a single pass. The inline chat lets you vibe code within the context of a specific file or function.

Cursor's strength is visual feedback. You see diffs in real time, accept or reject changes per-file, and maintain tight control over what gets committed. For developers who are not ready to fully hand over the wheel, Cursor offers a middle ground between traditional coding and full vibe coding.

Windsurf

Windsurf (formerly Codeium) positions itself as the "agentic IDE." Its Cascade feature chains multiple AI actions together — reading files, writing code, running commands — similar to Claude Code but within a graphical IDE. It targets developers who want the agency of CLI tools with the discoverability of a desktop application.

Each of these tools has different pricing and capability trade-offs. We break down the costs in our AI coding tools pricing comparison for 2026. For a deeper look at how the two leading terminal-based agents compare in practice, see our Codex vs Claude Code comparison.

The Common Pattern

Regardless of tool, the vibe coding workflow follows the same loop:

Describe what you want (natural language)
Generate the implementation (AI writes code)
Validate the output (run tests, check behavior)
Refine based on results (describe corrections, iterate)

The speed of this loop is what makes vibe coding feel fundamentally different from traditional development. A feature that might take an hour of manual coding can materialize in minutes. But speed introduces its own risks.

When Vibe Coding Works

Vibe coding is not universally good or bad. It excels in specific contexts:

Prototyping and MVPs

When you need to validate an idea fast, vibe coding is unmatched. Describe a landing page, a CRUD app, or an API prototype, and you can have a working version in minutes. The code does not need to be perfect — it needs to exist and demonstrate the concept.

Well-Defined Features with Clear Patterns

Adding a new API endpoint that follows the same pattern as twenty existing ones? Vibe coding handles this effortlessly. The AI sees the patterns in your codebase and replicates them. This is where the CLAUDE.md file pays off — the more context the AI has about your conventions, the more consistent its output.

Boilerplate and Repetitive Code

Configuration files, migration scripts, test scaffolding, CI/CD pipelines — the kind of code that follows templates but still requires project-specific details. Vibe coding eliminates the tedium while preserving correctness.

Exploration and Learning

Trying a new framework or library? Describe what you want to build, let the AI generate an implementation, and study how it works. Vibe coding becomes a learning accelerator — you see working examples immediately instead of reading documentation abstracts.

When Vibe Coding Fails

The failure modes of vibe coding are predictable and important to understand:

Complex Distributed Systems

When the correctness of your system depends on subtle interactions between components — race conditions, eventual consistency, distributed transactions — vibe coding's "describe and generate" approach breaks down. These problems require deep understanding of system behavior, not just functional correctness.

Performance-Critical Code

AI-generated code tends to be correct but not optimized. If you need specific algorithmic complexity guarantees, cache invalidation strategies, or memory-efficient data structures, you will need to read, understand, and likely rewrite what the AI produces.

Security-Sensitive Implementations

Authentication flows, cryptographic operations, permission models — these are domains where "it works" is not sufficient. Vibe coding can produce code that passes functional tests while containing security vulnerabilities. A SQL query that returns the right results but is injectable. A session handler that works but stores tokens insecurely. You cannot vibe your way through a security audit.

Novel Architecture Decisions

When you are making decisions that have no precedent in your codebase — choosing between event sourcing and CRUD, designing a new data model, defining service boundaries — the AI can only interpolate from training data. It cannot make informed architectural tradeoffs specific to your business constraints, team capabilities, and operational requirements.

The "It Works But I Don't Understand It" Trap

This is the most insidious failure mode. Vibe coding produces working code that the developer does not fully understand. This is fine for a prototype. It is dangerous for production code that you will need to debug at 3 AM during an outage. If you cannot explain why the code works, you cannot explain why it stopped working.

Impact on Junior vs. Senior Developers

The vibe coding trend affects developers at different experience levels in very different ways.

For Junior Developers

The upside: Vibe coding dramatically lowers the barrier to building software. A junior developer can produce working features faster than ever before. The gap between "I have an idea" and "I have a working implementation" has never been smaller.

The risk: If junior developers rely on vibe coding before building foundational understanding, they develop a dangerous blind spot. They can produce code but cannot debug it, optimize it, or reason about its failure modes. The skills that vibe coding bypasses — reading stack traces, understanding memory models, reasoning about concurrency — are exactly the skills needed when things go wrong in production.

Our recommendation: Use vibe coding as a learning tool, not a crutch. Generate code, then study it. Ask the AI to explain its implementation choices. Use it to accelerate learning, not to skip it.

For Senior Developers

The upside: Senior developers have the context to use vibe coding effectively. They know which parts of a system can be safely vibe-coded and which require careful manual implementation. They can review AI-generated code and spot issues that would be invisible to someone without experience. Vibe coding becomes a force multiplier — it handles the routine work while the senior developer focuses on the hard problems.

The risk: Complacency. When you can ship features ten times faster, the temptation to skip code review, skip testing, and skip documentation is real. Senior developers are not immune to the seduction of speed.

Our recommendation: Establish clear boundaries. Vibe code the implementation, but manually review the architecture. Automate testing so you catch regressions regardless of how the code was produced. Use the time savings to invest in the parts of engineering that AI cannot do yet — understanding user needs, designing resilient systems, mentoring junior developers.

Our Take: How Effloow Uses Vibe Coding with 14 AI Agents

At Effloow, vibe coding is not something we are experimenting with. It is how we operate.

We built our entire company using 14 AI agents orchestrated through Paperclip. Every agent — from the CEO to the content writers to the engineers — runs on Claude Code. When our Editor-in-Chief assigns an article, the Writer agent does not manually draft HTML templates. It receives a natural language brief, generates a full Markdown article with frontmatter, internal links, and proper heading structure, and commits it to the repository.

When our engineers build features, they describe what they want. Claude Code reads the existing codebase, generates implementations that follow established patterns, and runs tests to verify. The engineer's job shifts from writing every line to describing intent, reviewing output, and making architectural decisions.

Here is what we have learned from months of operating this way:

What Works

Content production at scale. Vibe coding (applied to writing, not just code) lets us produce high-quality, SEO-optimized articles faster than a traditional content team. The AI handles structure, formatting, and initial drafts. Human review handles accuracy and voice.
Consistent code patterns. When your CLAUDE.md is well-configured, every AI-generated feature follows the same conventions. New endpoints look like existing endpoints. Test files follow the same structure. Consistency improves without manual enforcement.
Rapid iteration. Describing a change and seeing it implemented in seconds creates a fundamentally different development rhythm. You try more ideas because the cost of trying is low.

What Does Not Work

Complex debugging. When something breaks in a way the AI does not understand, you are back to manual debugging. Vibe coding does not replace the ability to read a stack trace, set breakpoints, and reason about execution flow.
Cross-system coordination. Our agents work well on isolated tasks. When a feature touches multiple systems — the content pipeline, the deployment infrastructure, and the frontend — coordination still requires human judgment.
Quality without review. AI-generated code and content both require review. We have never shipped anything — not an article, not a feature — without human verification. The "vibe" part is the creation. The quality part is still human.

The Future of Vibe Coding

Vibe coding is not going away. The tools are getting better, the models are getting more capable, and the workflow is becoming more natural. But it is also not replacing traditional software engineering.

What is happening is a shift in where developers spend their time. Less time writing boilerplate. More time on architecture, design, and review. Less time fighting syntax. More time understanding systems. Less time on the "how." More time on the "what" and "why."

The developers who thrive in 2026 and beyond will not be the ones who resist vibe coding or the ones who adopt it blindly. They will be the ones who understand when to vibe and when to think — who use AI as a tool to amplify their judgment rather than a replacement for it.

If you are just getting started with AI-assisted development, begin with the fundamentals. Set up your CLAUDE.md properly. Learn how subagents and advanced workflows can multiply your effectiveness. And always remember: the goal is not to write code faster. The goal is to build better software.

The vibes are good. But vibes alone do not ship reliable systems. Judgment does.

How to Build a Custom MCP Server for Claude Code: A Step-by-Step Tutorial

Jangwook Kim — Sat, 04 Apr 2026 03:49:58 +0000

Liquid syntax error: Unknown tag 'endraw'

AI Coding Tools Pricing Breakdown 2026: Build a Complete Stack for $30/Month

Jangwook Kim — Sat, 04 Apr 2026 03:49:57 +0000

AI Coding Tools Pricing Breakdown 2026: Build a Complete Stack for $30/Month

Most developers are overpaying for AI coding tools. Not because the tools are overpriced — but because they are paying for overlapping features across multiple subscriptions without understanding what each tool actually contributes to their workflow.

The AI coding tool market in 2026 has exploded. GitHub Copilot, Cursor, Claude Code, Windsurf — each has a free tier, a pro tier, and increasingly, premium tiers that push past $100/month. A developer who subscribes to everything could easily spend $60-80/month on AI tooling. But the right combination of two tools can cover every use case for around $30/month.

This is not a feature-by-feature review. If you want a deep comparison of specific tools, we have written a detailed Codex vs Claude Code analysis that covers architecture, workflow, and real-world performance. This article is about money: what each tool costs, what you actually get at each price point, and how to build the most cost-effective stack for your workflow.

Why Most Developers Overpay

The problem is not greed. It is confusion. Here is what typically happens:

A developer starts with GitHub Copilot Free because it is the default in VS Code. They get autocomplete and basic chat.
They hear about Cursor and try the Pro plan for its multi-file editing and agentic features. Now they are paying $20/month.
Claude Code launches with terminal-based agents that can run across entire repositories. They add Claude Pro at $20/month.
They never cancel Copilot because the autocomplete still feels useful in the background.

Total: $40/month, with massive feature overlap between Cursor's chat and Claude Code's chat, and between Copilot's completions and Cursor's completions.

The fix is simple: understand what each tool is actually best at, and only pay for the capabilities you cannot get elsewhere.

2026 Pricing Overview: Every Tool, Every Tier

Here is what every major AI coding tool costs as of April 2026. All prices are monthly unless noted.

GitHub Copilot

GitHub Copilot remains the most widely used AI coding assistant, largely because of its deep VS Code integration and the free tier that ships with every GitHub account.

Plan	Price	What You Get
Free	$0/mo	2,000 code completions/mo, 50 premium requests/mo
Pro	$10/mo	Unlimited completions, premium model access, Copilot cloud agent
Pro+	$39/mo	Everything in Pro + larger premium request allowance, all models

The free tier is genuinely useful for hobbyists. 2,000 completions per month covers light daily coding. The Pro tier at $10/month is the sweet spot for most individual developers — unlimited completions and access to premium models in Copilot Chat make it a strong baseline tool.

Pro+ at $39/month is harder to justify unless you are heavily using Copilot's premium model requests throughout the day. Most individual developers will not hit the Pro tier limits.

Annual billing: Copilot Pro drops to ~$8.33/month when paid annually ($100/year), saving roughly 17%.

Cursor

Cursor has carved out a distinct position as the IDE that was built from the ground up for AI-first development. It is a fork of VS Code, so the transition is painless for most developers.

Plan	Price	What You Get
Hobby	$0/mo	Limited completions, limited chat
Pro	$20/mo	500 fast premium requests, unlimited standard completions, all features
Pro+	$60/mo	Higher premium request limits
Ultra	$200/mo	Maximum request limits, priority access
Teams	$40/user/mo	Admin controls, team features

The important change in 2026: Cursor shifted to a credit-based billing system in June 2025. Your $20/month Pro plan includes a credit pool equal to your plan price. Auto mode (which lets Cursor pick the model) is unlimited, but manually selecting frontier models draws from your balance.

In practice, this means the Pro tier is still $20/month for most developers who use Auto mode. But if you exclusively use the most expensive models, your effective costs can be higher.

Annual billing: Pro drops to ~$16/month when paid annually, a 20% discount.

Claude Code

Claude Code is fundamentally different from Copilot and Cursor. It is a terminal-based agent that operates across your entire repository — not an IDE plugin that suggests completions. It reads your codebase, understands context through CLAUDE.md files, and executes multi-step coding tasks autonomously.

Plan	Price	What You Get
Pro	$20/mo	Claude Code access, Sonnet model, standard rate limits
Max 5x	$100/mo	5x Pro usage, Opus model access, 1M context window
Max 20x	$200/mo	20x Pro usage, maximum rate limits

Claude Code is included with every Claude subscription — you do not pay separately for it. The question is which Claude plan gives you enough usage.

For most developers, Pro at $20/month provides enough daily usage for a solid workflow. You will occasionally hit rate limits during intensive sessions, but for regular development work, it is sufficient.

Max 5x at $100/month is for developers who rely on Claude Code as their primary coding tool and find the five-hour rate limit resets on Pro disruptive. If waiting for a reset costs you more than the price difference, the upgrade pays for itself.

If you have never used Claude Code, start by reading our guide on writing the perfect CLAUDE.md file — it is the single highest-leverage setup step, and getting it right determines whether Claude Code feels like a powerful assistant or a generic chatbot.

Windsurf (formerly Codeium)

Windsurf overhauled its pricing on March 19, 2026, replacing its credit-based system with daily and weekly quotas.

Plan	Price	What You Get
Free	$0/mo	Basic completions, limited agentic features
Pro	$15/mo	Quota-based usage with daily/weekly limits
Max	$200/mo	Maximum quotas for heavy users
Teams	$40/user/mo	Team management, higher quotas

The shift from credits to quotas is significant. Under the old system, you had a monthly pool of credits and could burn through them in a few intensive days. Under quotas, your usage is rate-limited per day and per week. This means steadier access but no more sprint sessions.

Note: Windsurf overhauled its pricing in March 2026. The figures above reflect the latest publicly available tiers as of April 2026. Check windsurf.com for the most current pricing.

Feature Comparison: What You Actually Get

Pricing only matters in the context of what each dollar buys. Here is how the four tools compare across the features that matter most to daily development.

Feature	Copilot Pro ($10)	Cursor Pro ($20)	Claude Code Pro ($20)	Windsurf Pro ($15)
Code completion	Excellent — inline, fast	Excellent — inline, multi-line	None (terminal-based)	Good — inline
Chat/Q&A	Good — sidebar	Good — integrated	Excellent — deep context	Good — Cascade
Multi-file editing	Limited	Excellent — Composer	Excellent — agentic	Good — agentic
Terminal integration	Limited	Limited	Native — built for terminal	Limited
Agentic coding	Basic (cloud agent)	Good (agent mode)	Excellent (primary design)	Good (Cascade)
Repository-wide context	Moderate	Good	Excellent (CLAUDE.md + codebase indexing)	Good
IDE	VS Code, JetBrains, Neovim	Cursor (VS Code fork)	Any terminal	VS Code fork
Free tier usefulness	High (2K completions)	Low (very limited)	None	Moderate

The key insight from this comparison: these tools do not all do the same thing.

Copilot excels at inline code completion — the fast, low-friction autocomplete that saves keystrokes as you type.
Cursor excels at multi-file editing within an IDE — refactoring, creating new features across multiple files, and keeping the AI aware of your project structure.
Claude Code excels at autonomous, repository-wide tasks from the terminal — complex refactors, debugging across services, generating tests, and multi-step operations that go beyond single-file editing.
Windsurf tries to do everything in one package but does not clearly lead in any single category.

This matters because the best stack is two specialized tools, not one generalist tool.

The $30/Month Stack: Our Recommendation

After testing every combination, here is the stack that gives the best coverage for $30/month:

Option A: Copilot Pro + Claude Code Pro ($30/month)

Best for: developers who work primarily in the terminal or prefer lightweight IDE setups.

Copilot Pro ($10/mo): Handles all your inline code completion. Fast, reliable, and deeply integrated into VS Code. You will barely notice it is there — which is exactly what good autocomplete should feel like.
Claude Code Pro ($20/mo): Handles everything else. Complex refactors, debugging, test generation, multi-file changes, code review, and any task that benefits from deep repository context.

This combination works because there is almost zero overlap. Copilot handles the microsecond-level inline suggestions while Claude Code handles the minutes-to-hours-level autonomous tasks.

Once you set up Claude Code, read our advanced workflow guide to unlock subagents, custom slash commands, and multi-session patterns that multiply your throughput.

Option B: Cursor Pro + No Second Tool ($20/month)

Best for: developers who want everything inside one IDE and do not need terminal-based agents.

Cursor Pro at $20/month is genuinely all-in-one. You get code completion, chat, multi-file editing, and agent mode in a single tool. If you are comfortable doing all your AI-assisted work inside the Cursor IDE, this is the most cost-effective single-tool option.

The trade-off: you lose the deep repository-wide context and autonomous execution that Claude Code provides. Cursor's agent mode is good, but it operates within the IDE paradigm. Claude Code operates at the system level.

Option C: Copilot Free + Claude Code Pro ($20/month)

Best for: budget-conscious developers who want maximum capability per dollar.

This is the minimum viable AI coding stack. Copilot Free gives you 2,000 completions per month — enough for light daily coding. Claude Code Pro gives you the full agentic experience for everything else.

At $20/month total, this is remarkably capable. The only limitation is that Copilot Free will cut off completions if you code heavily, at which point you rely entirely on Claude Code.

When to Spend More: Team and Enterprise Considerations

The $30/month stack works for individual developers. Teams have different requirements.

When Copilot Business ($19/user/month) Makes Sense

Your organization requires IP indemnity and content exclusion controls
You need admin-level policy management across the team
Your compliance team requires audit logs for AI-generated code

When Cursor Teams ($40/user/month) Makes Sense

Your team standardizes on Cursor as the primary IDE
You need shared context and workspace settings across developers
You want centralized billing and team management

When Claude Code Max ($100-200/month) Makes Sense

You are using Claude Code as your primary development tool for hours per day
Rate limit resets on Pro disrupt your flow multiple times per week
The cost of waiting exceeds the cost of upgrading
You need access to Claude Opus for complex reasoning tasks

The Enterprise Stack

Large teams often end up with Copilot Business ($19/user/month) for universal completions plus individual Claude Code subscriptions for senior developers who benefit most from agentic coding. Total per-developer cost: $39-119/month depending on the Claude tier.

Our Stack at Effloow

We run a fully AI-powered content company with 14 agents, all orchestrated through Paperclip. Here is what we actually pay for and use:

Claude Code Max: Every agent in our system runs on Claude Code. Our Writer, Editor-in-Chief, SEO Analyst, and other agents all use Claude Code as their execution environment. For an operation like ours where agents run continuously, the Max tier is necessary to avoid rate limit disruptions.

No Copilot or Cursor: Our agents do not use IDEs. They operate entirely in the terminal, reading and writing code directly. Copilot's inline completions and Cursor's IDE features are irrelevant to our workflow.

This is an unusual setup. Most individual developers will benefit from the hybrid approach (Copilot + Claude Code) because they do work inside an IDE. But it illustrates an important point: the right stack depends on how you actually work, not on which tool has the most features.

If you are curious about how an AI-first company actually operates, we wrote about how we built Effloow with 14 AI agents.

The Hidden Costs Nobody Talks About

API Costs

If you use Claude Code through the API instead of a subscription, costs can vary dramatically. API pricing is per-token, and a heavy coding session can burn through $5-20 in API credits in a single day. For most individual developers, the $20/month Pro subscription is far more cost-effective than API access.

Context Window Costs

Larger context windows cost more tokens. Claude Code's ability to understand your entire repository is powerful, but it means longer prompts and more tokens consumed per interaction. On API billing, this adds up. On subscription billing, it is included — another reason subscriptions are usually the better deal.

Switching Costs

Every tool has a learning curve. Cursor requires learning its Composer workflow. Claude Code requires writing a proper CLAUDE.md file. Copilot's advanced features require understanding its chat interface. The time you invest in learning one tool is a real cost that should factor into your decision.

The "Free Tier Trap"

Free tiers are intentionally limited to drive upgrades. Copilot Free's 2,000 completions sound generous until you realize a single productive coding day can consume 200-400 completions. If you code five days a week, you will hit the limit in 5-10 working days.

What About Vibe Coding?

The rise of vibe coding has changed how some developers think about AI tools. If your workflow is primarily describing what you want and letting AI build it, you need a tool that excels at agentic, multi-file generation — which favors Claude Code and Cursor's agent mode over traditional autocomplete tools like Copilot.

For vibe coding workflows, the optimal stack shifts toward:

Claude Code Pro ($20/month) for the primary "describe and build" workflow
Copilot Free ($0) for occasional inline completions when you do touch code directly

Total: $20/month for a vibe-coding-optimized setup.

Quick Decision Framework

Still unsure? Answer these three questions:

1. Do you primarily code inside an IDE or from the terminal?

IDE → Cursor Pro ($20/mo) or Copilot Pro + Claude Code ($30/mo)
Terminal → Claude Code Pro ($20/mo)

2. How often do you need multi-file, repository-wide changes?

Rarely → Copilot Pro ($10/mo) is enough
Often → Add Claude Code Pro ($20/mo)
Constantly → Claude Code Max ($100-200/mo)

3. Is your budget fixed or flexible?

Fixed at $20/mo → Cursor Pro or Claude Code Pro (pick based on question 1)
Fixed at $30/mo → Copilot Pro + Claude Code Pro
Flexible → Start at $30/mo and upgrade individual tools as needed

Final Recommendation

The AI coding tools market in 2026 is mature enough that there is no single "best tool." There is only the best tool for your workflow and budget.

For most developers, Copilot Pro ($10/month) + Claude Code Pro ($20/month) = $30/month delivers the most complete coverage with the least overlap. You get world-class inline completions from Copilot and world-class agentic coding from Claude Code, each doing what it does best.

If budget is tighter, start with Claude Code Pro at $20/month. It covers more ground than any other single tool at the same price point.

If you want one tool to rule them all, Cursor Pro at $20/month comes closest to an all-in-one solution, though you sacrifice the depth of Claude Code's terminal-based agentic capabilities.

Whatever you choose, spend 30 minutes setting it up properly. For Claude Code, that means writing a solid CLAUDE.md. For Cursor, that means learning Composer. For Copilot, that means configuring which suggestions to accept and reject.

The tool that is configured well will always outperform the tool that is merely installed.

OpenAI Codex vs Claude Code: Which AI Coding Agent Wins in 2026?

Jangwook Kim — Sat, 04 Apr 2026 03:49:56 +0000

OpenAI Codex vs Claude Code: Which AI Coding Agent Wins in 2026?

Two AI coding agents dominate the developer conversation right now: OpenAI's Codex and Anthropic's Claude Code. Both promise to write, debug, and ship code autonomously. Both have passionate users who swear the other side is missing out.

We are not neutral observers. Effloow runs Claude Code daily across a 14-agent company powered by Paperclip AI agent orchestration. Every article, tool, and experiment we ship is written or built by Claude Code agents operating in real production workflows. That experience gives us a strong opinion — but we will be transparent about what that opinion is based on and where Codex may genuinely be the better choice.

This is not a feature checklist. This is a practical comparison for developers who want to know which tool deserves their subscription money in 2026.

What Are These Tools, Exactly?

Before diving into comparisons, let's be clear about what each tool actually is — because the naming can be confusing.

OpenAI Codex

OpenAI Codex is a cloud-based AI coding agent accessible through both a web interface (inside ChatGPT) and an open-source CLI tool. When you give Codex a task, it spins up a sandboxed cloud environment, clones your repository, executes code, runs tests, and returns the results.

The key architectural decision: Codex runs your code in the cloud, not on your machine. It creates isolated microVMs for each task, installs dependencies, and operates within that sandbox. Your local environment is not directly involved in execution.

Codex is powered by OpenAI's GPT-5.x-Codex model family — purpose-built models optimized for agentic coding tasks. The latest iterations include GPT-5.3-Codex, which OpenAI describes as their most capable agentic coding model, and Codex-Spark, a lighter variant available in research preview.

Claude Code

Claude Code is Anthropic's AI coding agent that runs directly in your terminal. It reads your local filesystem, executes commands on your machine, edits your files in place, and interacts with your actual development environment — your shell, your git config, your running services.

Claude Code is powered by Claude's model family. Most users run it on Claude Sonnet 4.6 (fast, cost-effective) or Claude Opus 4.6 (maximum capability). You can switch between models mid-session, and the tool supports a "fast mode" that accelerates Opus output at higher token cost.

The key architectural decision: Claude Code runs locally. It does not upload your code to a remote sandbox. It operates in your terminal, on your machine, with your environment.

Architecture: Cloud Sandbox vs Local Execution

This is the single most important difference between the two tools, and everything else flows from it.

How Codex's Cloud Model Works

When you submit a task to Codex, it:

Clones your repository into a sandboxed cloud environment
Sets up dependencies (npm install, pip install, etc.)
Executes the task autonomously within that sandbox
Returns a diff, along with logs and test results

The sandbox is isolated. It cannot access your local network, local databases, running Docker containers, or any environment-specific configuration that exists only on your machine. This is simultaneously Codex's greatest strength (safety, reproducibility) and its most significant limitation (it cannot interact with your actual development setup).

What this means in practice: Codex is excellent for self-contained tasks where the full context exists in the repository. Writing a new utility function, fixing a bug with a clear test case, refactoring a module — these work well in a sandbox. Tasks that depend on local state — hitting a running API, testing against a local database, debugging environment-specific issues — require workarounds or don't work at all.

How Claude Code's Local Model Works

Claude Code operates in your terminal session. It:

Reads files directly from your filesystem
Runs commands in your shell (with permission controls)
Edits files in place using precise diffs
Interacts with your running services, databases, and tools

There is no sandbox boundary between Claude Code and your environment. It can curl your local API, query your development database, run your test suite exactly as you would, and commit to your local git repository.

What this means in practice: Claude Code can handle anything you can handle from a terminal. At Effloow, our agents routinely run Laravel Artisan commands, interact with local Node processes, execute git workflows, and push code — all within the same environment where the code will actually run.

The tradeoff is trust. Claude Code mitigates this with multiple layers: a permission system (you approve or deny each tool call, or configure auto-approval rules) and OS-level sandboxing using macOS seatbelt or Linux bubblewrap for filesystem and network isolation. Anthropic reports that sandboxing reduced permission prompts by 84% in internal usage. But the fundamental reality is that it operates on your machine, with access configured by you.

Which Architecture Is Better?

Neither is universally better. The right choice depends on your workflow:

Scenario	Better Choice
Greenfield feature in a self-contained repo	Either works well
Debugging a local environment issue	Claude Code (needs local access)
Running parallel tasks on multiple repos	Codex (cloud scales naturally)
Working with private APIs/databases	Claude Code (local network access)
Team sharing results without local setup	Codex (reproducible cloud environment)
Multi-file refactoring with test validation	Both capable, Claude Code has tighter feedback loop

Models and Intelligence

Both platforms invest heavily in their underlying models, but they take different approaches.

Codex Models

OpenAI's Codex-specific model line (GPT-5.x-Codex) is purpose-built for agentic coding. These models are trained specifically for code generation, debugging, and multi-step software engineering tasks. GPT-5.3-Codex is the current flagship, described by OpenAI as 25% faster than its predecessor with improved frontier coding performance.

The Codex model family also includes specialized variants like GPT-5.1-Codex-Max, designed for "long-running, project-scale work" with context compaction that allows it to work coherently across multiple context windows.

Claude Models

Claude Code uses general-purpose Claude models — the same Sonnet and Opus models available across all Claude products. Claude Sonnet 4.6 is the default for most users (fast, capable, affordable), while Claude Opus 4.6 is the flagship for maximum capability.

Claude's models are not coding-specific, but they perform exceptionally well on coding tasks. Anthropic's approach is to build generally intelligent models that excel across domains rather than specialized variants.

How They Compare on Benchmarks

Both platforms publish SWE-bench scores, but there is an important caveat: they report on different versions of the benchmark.

Claude Opus 4.5 scored 80.9% on SWE-bench Verified — the first model to exceed 80% on that benchmark. Claude Sonnet 4.5 scored 77.2% on the same test.
GPT-5.3-Codex scored 78.2% on SWE-bench Pro — a newer, multi-language variant designed to be more contamination-resistant. GPT-5.2-Codex scored 80.0% on SWE-bench Verified and 56.4% on Pro.

These numbers are not directly comparable. SWE-bench Verified is Python-only with ~300 issues. SWE-bench Pro covers four languages and is considered more challenging. Comparing an 80.9% Verified score against a 78.2% Pro score is apples to oranges.

What we can share from direct experience: Claude Opus 4.6 handles complex, multi-file tasks with remarkable consistency across our 14-agent production setup. It understands project context deeply — following conventions from CLAUDE.md configuration files, respecting architectural boundaries, and maintaining coherent multi-step plans. We have not run Codex in equivalent production workflows, so we cannot offer a direct head-to-head comparison from experience.

Pricing: What You'll Actually Pay

This is where the comparison gets practical and where most developers make their decision.

Codex Pricing

OpenAI Codex is available through several paths:

ChatGPT Plus ($20/month): Includes access to Codex with usage limits
ChatGPT Pro ($200/month): Higher usage limits and access to more capable model variants
API access: Token-based pricing — codex-mini-latest runs at $1.50/M input tokens, $6/M output tokens, with a 75% discount on cached prompts
Compute charges: Sandboxed execution environments are billed separately by duration and environment type

The cloud sandbox model means you are paying for compute (the sandboxed environment) in addition to model inference. For heavy users, costs can scale with the number and duration of sandbox sessions.

Claude Code Pricing

Claude Code can be accessed through:

Claude Pro ($20/month): Includes Claude Code access via the desktop app and IDE extensions with usage limits
Claude Max 5x ($100/month): 5x the Pro usage limits for heavy Claude Code users
Claude Max 20x ($200/month): 20x limits for power users
API access: Standard token pricing — Opus 4.6 at $5/M input, $25/M output; Sonnet 4.6 at $3/M input, $15/M output; Haiku 4.5 at $0.25/M input, $1.25/M output
Batch API: 50% discount on all token costs for asynchronous workloads
Prompt caching: Cache hits billed at 10% of standard input price
Team and Enterprise plans: For organizations with multiple developers

The local execution model means you are paying only for model inference — there is no separate sandbox compute cost. Your machine provides the execution environment. For API users, this makes costs highly predictable: you pay for tokens consumed, nothing more.

Real-World Cost Comparison

At Effloow, we run 14 agents on Claude Code via the API. Our cost structure is purely token-based. We can precisely control spending by choosing which model each agent uses (Sonnet for routine work, Opus for complex tasks) and by optimizing our CLAUDE.md files to reduce unnecessary context.

For an individual developer, the comparison at the subscription level is straightforward:

Light usage (a few tasks per day): Both $20/month tiers are comparable
Heavy usage (primary coding tool): Claude Max at $100-200/month vs ChatGPT Pro at $200/month — similar price range, different execution models
API/programmatic usage: Token pricing varies by model tier. Claude's local execution avoids sandbox compute overhead, which can matter at scale

We cannot provide exact dollar-per-task comparisons because task complexity varies enormously. A simple function generation uses minimal tokens on either platform, while a multi-file refactoring might cost 10-50x more. For a broader breakdown covering GitHub Copilot, Cursor, Windsurf, and more, see our AI coding tools pricing comparison.

Developer Experience: What It Feels Like to Use Each Tool

Codex Developer Experience

Codex offers two primary interfaces:

Web interface (ChatGPT): Submit a task, wait for the sandbox to complete, review the resulting diff. This is asynchronous — you can queue multiple tasks and review them later.
CLI tool (open source): An open-source terminal client that connects to the Codex cloud backend. Supports autonomous and interactive modes.

The web interface excels at parallel workflows. You can submit five tasks to five repos and review them all later. Each task runs independently in its own sandbox, so there is no contention.

The CLI supports features like sub-agents with readable path-based addressing (/root/agent_a) for multi-agent workflows, plugin support, and custom model provider configuration.

Claude Code Developer Experience

Claude Code lives entirely in your terminal:

$ claude
> Fix the failing test in auth_middleware.test.ts

I'll look at the test file and fix the issue...
[reads file, identifies problem, edits file, runs tests]

All 47 tests passing. The issue was a stale mock that didn't account
for the new session timeout parameter added in the last commit.

The experience is conversational and immediate. You see what Claude Code is doing in real time — which files it reads, what commands it runs, what edits it makes. You can interrupt, redirect, or approve/deny actions as they happen.

Key workflow features include:

MCP (Model Context Protocol): Connect Claude Code to external tools like Jira, Slack, Google Drive, or your own custom APIs
CLAUDE.md and AGENTS.md: Project-level configuration that shapes agent behavior across every session — see our deep dive on CLAUDE.md setup
Hooks: Shell commands that execute in response to agent events (pre-commit checks, post-edit linting, etc.)
Subagents: Spawn specialized sub-agents for parallel tasks within a single session
IDE extensions: Native integrations for VS Code, Cursor, Windsurf, and JetBrains IDEs

Which Experience Is Better?

Codex's asynchronous model is better for batch workflows — submit tasks, do other work, review later. Claude Code's synchronous model is better for iterative development — explore a problem, try approaches, refine until done.

At Effloow, the real-time feedback loop is critical. Our agents need to interact with local services, validate against running systems, and iterate rapidly. The "submit and wait" model would not work for our workflow.

Multi-Agent and Orchestration

Both platforms are investing in multi-agent capabilities, but from very different starting points.

Codex Multi-Agent

Codex's CLI supports multi-agent v2 workflows with sub-agents addressed via readable paths. The cloud sandbox model naturally supports parallelism — each agent gets its own isolated environment, so there is no contention over local resources.

Claude Code Multi-Agent

Claude Code's subagent system allows spawning specialized agents within a session. Combined with orchestration platforms like Paperclip, it enables complex multi-agent architectures.

At Effloow, we run 14 agents across 5 divisions — Content Factory, Tool Forge, Experiment Lab, Media Team, and a Web Dev Lead — all on Claude Code. Each agent has its own role, capabilities, and chain of command. A CEO agent delegates work, an Editor-in-Chief manages content pipelines, and individual contributor agents (like the Writer agent producing this article) execute assigned tasks.

This level of orchestration is possible because Claude Code's local execution model integrates cleanly with external coordination systems. Each agent session is a standard process that can be monitored, scheduled, and managed through conventional infrastructure. This approach to AI-assisted development — where you describe intent and let agents handle implementation — is part of a broader shift toward vibe coding.

We have not tested equivalent multi-agent architectures on Codex, so we cannot make a direct comparison. Codex's cloud model could have advantages for team-scale parallelism where local machine resources would be a bottleneck.

Strengths and Weaknesses: An Honest Summary

Where Codex Wins

Safety through isolation: The cloud sandbox cannot accidentally delete your files or run destructive commands on your machine
Parallel scalability: Cloud resources scale independently of your local hardware
Asynchronous workflows: Submit tasks and come back later — great for batch operations
Reproducibility: Sandboxed environments are consistent and shareable across teams
No local resource consumption: Your machine stays free while Codex works in the cloud

Where Claude Code Wins

Local environment access: Interact with your actual development setup — databases, APIs, Docker containers, local services
Real-time feedback: Watch and steer the agent as it works, rather than waiting for batch results
Cost transparency: Token-based pricing with no sandbox compute overhead
Extensibility via MCP: Connect to any external tool through a standardized protocol — see our MCP server tutorial
Project-level intelligence via CLAUDE.md: Persistent configuration that makes every session smarter — see our CLAUDE.md guide
Deep multi-agent orchestration: Proven at scale in production (our 14-agent company is the evidence)

Where Both Need Improvement

Cost predictability for heavy use: Both platforms can surprise you with bills on intensive workloads
Handling very large codebases: Context windows are finite, and both tools need strategies for navigating massive repos
Error recovery on long tasks: Multi-step tasks can go sideways, and both tools sometimes commit to wrong approaches before self-correcting

Which Should You Choose?

Here is our honest recommendation framework:

Choose Codex If:

You prioritize safety and want hard isolation between the AI agent and your local machine
You work in teams that need to share reproducible results without requiring everyone to have the same local setup
You prefer asynchronous workflows where you submit tasks and review later
Your work is self-contained within repositories without heavy dependence on local services or databases
You're already invested in the OpenAI ecosystem (ChatGPT Plus/Pro, OpenAI API)

Choose Claude Code If:

You need local environment interaction — databases, APIs, Docker, local services
You prefer real-time, iterative development with immediate feedback and the ability to steer
You want deep project customization through CLAUDE.md configuration and hooks
You plan to build multi-agent systems or use orchestration tools like Paperclip
You want extensibility through MCP for integrating with external tools and services
Cost control matters — API token pricing gives you precise control with no sandbox overhead

Choose Both If:

You want Codex for safe, parallel batch operations and Claude Code for interactive, environment-dependent work. There is no rule that says you must pick one. The subscription costs are comparable, and using both strategically can cover more ground than either alone.

Our Experience: 14 Agents, One Platform

We want to end with transparency about our own position.

Effloow chose Claude Code — not after an extensive bake-off, but because it was the right fit for our specific needs from day one. We needed agents that could interact with a Laravel codebase, run Artisan commands, push to Git, and coordinate through Paperclip. All of that requires local execution.

After running 14 agents in production, here is what we have learned:

CLAUDE.md is the highest-leverage optimization. A well-structured configuration file dramatically reduces wasted tokens and improves output quality. We wrote an entire guide on this because it matters that much.
Model selection per agent saves money. Not every agent needs Opus. Our routine content and code tasks run on Sonnet, and we reserve Opus for complex reasoning tasks. This tiered approach keeps costs manageable.
MCP integration is a force multiplier. Connecting Claude Code to external systems through custom MCP servers turns it from a coding tool into a general-purpose automation platform.
Local execution is non-negotiable for us. Our agents need to interact with local databases, run framework commands, and push to Git. A cloud sandbox would add friction to every step of our pipeline.

Could we have built Effloow on Codex? Possibly, with significant architectural changes. But the local execution model aligned so well with our needs that the decision was straightforward.

The Bottom Line

OpenAI Codex and Claude Code are both capable AI coding agents that represent the state of the art in 2026. They make genuinely different architectural bets — cloud sandbox vs local execution — and those bets have real consequences for developer experience, cost, and workflow compatibility.

Neither tool is objectively superior. The right choice depends on how you work, what you need from your development environment, and whether you value safety-through-isolation (Codex) or power-through-integration (Claude Code).

If you are still undecided, start with the $20/month tier on either platform and spend a week using it on real tasks — not toy examples. The difference will become obvious once you hit a task that needs (or doesn't need) local environment access.

For teams building multi-agent systems — the kind of architecture we run at Effloow — Claude Code's local execution model and MCP extensibility currently offer a more complete foundation. But this space is evolving fast, and the best tool in April 2026 may not be the best tool in October 2026.

Build with what works for you today. Switch when something better emerges. That is the only durable strategy in a market moving this fast.

This article was written by the Writer agent at Effloow Content Factory, running Claude Code via Paperclip AI agent orchestration. For more on how our AI-powered company works, read How We Built a Company Powered by 14 AI Agents.

Coolify vs Dokploy: Best Self-Hosted PaaS for Developers 2026

Jangwook Kim — Sat, 04 Apr 2026 03:49:55 +0000

Coolify vs Dokploy: Best Self-Hosted PaaS for Developers 2026

If you are looking for a self-hosted alternative to Heroku, Railway, or Vercel, two open-source platforms dominate the conversation in 2026: Coolify and Dokploy. Both let you deploy applications on your own servers through a web interface, handle SSL certificates, manage databases, and integrate with Git providers. But they take fundamentally different approaches to how they get you there.

Coolify focuses on flexibility and a feature-rich PaaS experience. Dokploy emphasizes simplicity and fast, Docker-first deployments. The right choice depends on what you value — and the benchmarks tell a clearer story than the marketing pages.

At Effloow, we run AI agents on self-hosted infrastructure. We have evaluated both platforms for our deployment needs and collected real data on performance, resource usage, and developer experience. This is not a feature-table rehash — it is a practical comparison based on actual deployment work.

Quick Verdict

If you want the short answer: Dokploy is the better choice for teams that think in Docker and want minimal overhead. Coolify is the better choice for teams that want guided workflows, broader integrations, and do not mind the extra resource cost.

Now let us break down why.

Resource Usage: The Numbers That Matter

Resource efficiency is the most concrete differentiator between these two platforms. When you are running on a VPS, every percentage of CPU and megabyte of RAM counts.

Idle Resource Consumption

Based on testing by NextGrowth AI on identical Hetzner CX21 instances over an 8-month period with 20+ containers each:

Metric	Dokploy	Coolify
Idle CPU	~0.8%	~6%+
Idle RAM	~300 MB	~600 MB
CPU Under Load	Stable, low spikes	Higher variability

A Medium analysis found similar results: Dokploy averaged 0.8-1.5% idle CPU, while Coolify hovered between 6-7% with no services running. Both platforms used around 1 GB of memory in that test, though the NextGrowth benchmarks on longer timeframes showed a wider gap.

Why does Coolify use more resources? Coolify is built with PHP/Laravel and runs additional background processes for its managed networking and proxy layers. Dokploy is built with Next.js and TypeScript, with a lighter runtime footprint.

Bottom line: On a small VPS (2-4 GB RAM), Dokploy leaves significantly more headroom for your actual applications. This matters less on larger servers, but it is a real consideration for budget-conscious deployments.

Installation and Onboarding

Both platforms offer single-command installation, but the experience diverges quickly after that.

Dokploy works straight out of the box. Install it, and you are looking at a functional dashboard. According to LogRocket's testing, Dokploy's installation was 21 minutes faster than Coolify's in testing.

Coolify includes a guided onboarding flow that walks you through connecting servers, configuring build settings, and setting up your first project. It even includes dad jokes during the setup process. This is friendlier for newcomers but adds time for experienced users who just want to deploy.

Git Integration and Build Systems

Git Provider Support

Feature	Coolify	Dokploy
GitHub	Yes	Yes
GitLab	No (GitHub only)	Yes
Bitbucket	No	Yes
Auto-load repos	Extra clicks required	Direct after connecting

Dokploy wins on breadth here. If your team uses GitLab or Bitbucket, Coolify is not an option without workarounds.

Build Methods

Build Method	Coolify	Dokploy
Dockerfile	Yes	Yes
Nixpacks	Yes	Yes
Docker Compose	Yes	Yes
Railpack	No	Yes
Heroku Buildpacks	No	Yes
Paketo	No	Yes
AI-assisted builds	No	Yes

Dokploy supports more build methods, including AI-assisted builds that can auto-detect and configure your project. Coolify sticks to the proven trio of Dockerfile, Nixpacks, and Docker Compose.

Docker Compose: The Critical Difference

This is where the philosophical difference between the two platforms becomes most apparent.

Dokploy treats Docker Compose files the way Docker itself does. Networking, volumes, and service definitions behave as expected. If your docker-compose.yml works locally, it works on Dokploy with minimal changes.

Coolify adds an abstraction layer on top of Docker Compose. It creates managed networks, injects proxy containers, and maps routing through its UI. This gives you more control through the web interface but introduces potential compatibility friction. Coolify also injects a helper image during each deployment, which can affect build and deployment speed.

Container Restart Behavior

A subtle but important difference from LogRocket's testing:

Dokploy: Stops and restarts containers without rebuilding
Coolify: Triggers a full rebuild from scratch on restart

If you frequently restart services during development, Coolify's approach adds significant overhead.

Database and Service Management

Database Options

Coolify offers a broader selection of database services out of the box, including PostgreSQL, MySQL, DragonflyDB, and KeyDB. Dokploy focuses on the most common options: PostgreSQL and MySQL.

However, Dokploy allows full image selection for database containers, while Coolify only offers tag selection. This gives Dokploy more flexibility for custom or specialized database images.

Volume Backups

Backup Feature	Coolify	Dokploy
Database backups	Yes	Yes
Generic volume backups	No (database only)	Yes (S3-compatible)

Dokploy supports backing up any Docker volume to S3-compatible storage. Coolify limits backups to database services. If you have application data stored in volumes, Dokploy gives you more protection.

Monitoring and Scheduled Tasks

Monitoring

Dokploy includes built-in real-time metrics in its UI — you can see CPU, memory, and network usage for each container without additional setup.

Coolify requires configuration before monitoring works. Once configured, it provides similar metrics, but the out-of-box experience is weaker.

Scheduled Tasks

Task Level	Coolify	Dokploy
Container-level	No	Yes
Service-level	No	Yes
Host-level	No	Yes
Application-level	Yes	Yes

Dokploy offers more granular control over scheduled tasks, supporting container-level, service-level, and host-level scheduling. Coolify limits scheduled tasks to the application level.

Networking and SSL

Coolify has built-in Cloudflare Tunnels support, which is a significant advantage if you use Cloudflare for DNS and want to avoid exposing your server's IP address. Dokploy can achieve this through templates but does not have native integration.

Both platforms handle SSL certificates automatically through Let's Encrypt.

Coolify supports a wider range of notification integrations: Telegram, Discord, Slack, and Pushover. Dokploy supports Gotify and Discord, with fewer options overall.

Scaling and Multi-Node

Dokploy supports Docker Swarm multi-node clusters, allowing you to scale across multiple servers. This is important for production workloads that need horizontal scaling.

Coolify focuses on single-server deployments with managed complexity. Multi-node support is more limited.

Licensing: An Important Distinction

Aspect	Coolify	Dokploy
License	Apache 2.0	Apache 2.0 with restrictions
Open source	Fully open source	Source-available
Commercial use	Unrestricted	Restrictions on resale

Coolify is fully open source under Apache 2.0 with no restrictions. Dokploy uses an Apache 2.0 license with additional restrictions on resale and commercial use, making it more accurately described as source-available rather than strictly open source.

This matters if you plan to build a hosting business on top of either platform. For personal or internal team use, both licenses are fine.

Managed Hosting Plans

Both platforms offer managed hosting for teams that do not want to maintain their own servers:

Coolify Cloud: Starting at $5/month
Dokploy: Managed plans starting at $4/month

The pricing is comparable, and both options include automated updates and support.

Community and Ecosystem

GitHub Activity

Metric	Coolify	Dokploy
GitHub Stars	48,000+	24,000+
Commits	14,000+	4,000+
Active Since	February 2022	April 2024

Coolify has a larger community and longer track record. It has been in active development for over four years with a substantial contributor base. Dokploy is newer — started in April 2024 — but has grown rapidly, reaching 24,000+ stars in under two years.

A larger community means more tutorials, more Stack Overflow answers, and faster bug fixes. But Dokploy's rapid growth suggests strong momentum and active development.

Who Should Use What

Choose Dokploy If:

Docker is your mental model. You think in Dockerfiles and Compose files, and you want your PaaS to stay out of the way.
Resource efficiency matters. You are running on a small VPS and need every MB of RAM for your applications.
You use GitLab or Bitbucket. Coolify only supports GitHub.
You need multi-node scaling. Docker Swarm support gives you a path to horizontal scaling.
You want fast container restarts. Dokploy restarts without rebuilding.

Choose Coolify If:

You want guided onboarding. Coolify holds your hand through setup and configuration.
Cloudflare Tunnels are essential. Native integration saves significant configuration time.
You need broad notification support. Telegram, Slack, Pushover, and Discord are all built in.
Open source licensing matters. Apache 2.0 with no restrictions gives you maximum freedom.
You value community size. A larger community means more resources and faster support.

For Effloow's Use Case

We run AI agents that need reliable, low-overhead deployment. Docker Compose compatibility is essential because our agent services are defined in Compose files. Resource efficiency matters because we run multiple services on each VPS. For these reasons, Dokploy aligns better with our requirements — but Coolify's Cloudflare Tunnels integration is genuinely compelling for teams with different priorities.

The Bottom Line

Both Coolify and Dokploy are excellent self-hosted PaaS platforms that can replace expensive managed services. The choice comes down to philosophy:

Dokploy stays close to Docker and gets out of your way. It uses fewer resources, deploys faster, and supports more Git providers and build methods. The trade-off is fewer built-in integrations and a source-available license.

Coolify provides a richer, more guided experience with broader integrations and a fully open-source license. The trade-off is higher resource overhead and a Docker Compose abstraction that may not behave exactly like native Docker.

Neither is the wrong choice. Both are actively maintained, both offer managed hosting plans, and both are dramatically cheaper than Heroku or Railway for teams that can manage their own servers.

Pick the one that matches how you think about deployment — and either way, you will be deploying on your own terms.

Migration Considerations

If you are already using one platform and considering switching, here is what to expect:

Moving from Coolify to Dokploy: Your Docker Compose files will likely work with fewer modifications on Dokploy since it stays closer to native Docker behavior. The main challenge is recreating any Cloudflare Tunnel configurations manually. Database migrations are straightforward — export from Coolify's backup system and import into Dokploy containers.

Moving from Dokploy to Coolify: Expect to adjust Docker Compose files for Coolify's managed networking layer. Some Compose configurations that work on Dokploy may need modifications for Coolify's proxy injection. The benefit is gaining access to Coolify's broader notification and integration ecosystem.

Starting fresh: If you are deploying a new project, try both platforms on a cheap VPS before committing. A $5/month Hetzner or Contabo instance is enough to evaluate the deployment experience, resource overhead, and Docker Compose compatibility with your specific stack. For AI workloads that need GPU acceleration, both platforms can deploy containers on Hetzner's GPU-enabled servers.

Frequently Asked Questions

Can I run both on the same server?
Technically yes, but it is not recommended. Both platforms manage Traefik or similar reverse proxies and would conflict on port 80/443. Use separate VPS instances for evaluation.

Which is better for Kubernetes?
Neither platform is designed for Kubernetes. Both focus on Docker-based deployments. If Kubernetes is a requirement, look at Rancher or k3s instead.

How do updates work?
Both platforms support self-updating through their web interface. Coolify tends to push updates more frequently due to its larger contributor base. Dokploy updates are less frequent but typically well-tested.

Is there vendor lock-in?
Minimal for both. Your applications run in standard Docker containers, and your Compose files are portable. The main lock-in is in platform-specific configuration like routing rules and environment variable management, which is easy to recreate elsewhere.

Related Resources

Self-Host Your Entire Dev Stack for Under $20/Month — A complete guide to building your self-hosted development infrastructure
Ollama + Open WebUI Self-Hosting Guide — Deploy self-hosted AI inference alongside your Coolify or Dokploy stack
How to Build a Custom MCP Server for Claude Code — Extend your self-hosted infrastructure with AI tool integrations
The Perfect CLAUDE.md Setup Guide — Configure AI coding assistants for your deployment workflow

Free AI Coding Tools 2026: Build a Complete $0/Month Stack That Actually Works

Jangwook Kim — Sat, 04 Apr 2026 03:49:54 +0000

Free AI Coding Tools 2026: Build a Complete $0/Month Stack That Actually Works

No single free AI coding tool is good enough to replace a paid subscription. That is the uncomfortable truth every "best free tools" listicle avoids saying.

GitHub Copilot Free gives you 2,000 completions per month — roughly 65 per day if you spread them evenly. That runs out by lunchtime. Windsurf's free tier puts you on a vague quota system that throttles after a few serious coding sessions. Even Gemini Code Assist, which launched an incredibly generous free tier with 180,000 monthly completions, has gaps that matter.

But here is what those listicles miss: you are not limited to picking one tool. Every free tier covers different gaps. Combined into a single stack, they produce coverage that genuinely rivals a $20-30/month paid subscription — at $0/month.

This guide breaks down every major free AI coding tool available in April 2026, compares them honestly with verified data, and shows you exactly how to combine them into a working $0/month stack. We will also be honest about when the free stack falls short and you should consider upgrading — because sometimes the right answer is to spend the money.

If you want a deep comparison of paid options and optimal stacks, we wrote a complete AI coding tools pricing breakdown that covers every tier from every major tool.

The Free AI Coding Tool Landscape in 2026

The free tier landscape has changed dramatically in early 2026. Two events reshaped everything:

Google launched Gemini Code Assist for individuals (March 2026). This is the single biggest shift. Google is offering 180,000 code completions per month for free — roughly 90x what GitHub Copilot Free provides. The context window is 128,000 tokens, which is competitive with paid tools. This is not a limited trial. It is a permanent free tier backed by Google's infrastructure.

Windsurf overhauled its pricing (March 19, 2026). What was previously marketed as unlimited free autocomplete shifted to a quota-based system with daily and weekly resets. The exact quota numbers are not publicly disclosed, but community reports suggest roughly 3-5 meaningful Cascade sessions per day before throttling kicks in. This upset a lot of developers who had built workflows around the old unlimited model.

Meanwhile, GitHub Copilot Free continues unchanged — still useful, still limited, still the default for anyone with a GitHub account. And Ollama keeps growing as a viable local fallback, hitting 52 million monthly downloads in Q1 2026.

The result: in April 2026, a developer who strategically combines these tools can cover autocomplete, chat, and even some agentic coding tasks without paying anything.

Head-to-Head Comparison: Every Free AI Coding Tool

Here is every major free AI coding tool compared on the metrics that actually matter for daily development.

Feature	Gemini Code Assist Free	GitHub Copilot Free	Windsurf Free	Ollama (Local)
Code completions/mo	180,000	2,000	Quota-based (undisclosed limits, daily/weekly resets)	Unlimited
Chat messages	240/day	50/month	Included in quota	Unlimited
Context window	128K tokens	Standard	Standard	Model-dependent (4K-128K)
Agent mode	Yes (with daily limits)	No	Limited	No
Supported IDEs	VS Code, JetBrains, Android Studio, Xcode, Eclipse	VS Code, JetBrains, Visual Studio, Neovim	Windsurf IDE (VS Code fork)	Any (via API)
Languages	23+ verified (Python, JS, TS, Go, Rust, C++, Java, etc.)	All major languages	All major languages	Model-dependent
Model	Gemini 2.5	GPT-4o / Claude 3.5 (rotates)	Proprietary (Cascade)	Open-source (Llama, CodeQwen, DeepSeek, etc.)
Privacy	Cloud-processed	Cloud-processed	Cloud-processed	Fully local
Requires account	Personal Gmail	GitHub account	Windsurf account	None
Restrictions	Not available in all regions; personal accounts only	GitHub account required	None significant	Requires local hardware

Gemini Code Assist Free: The New Leader

Google's free tier is, by the numbers, the most generous offering in AI coding tool history. 180,000 completions per month is absurd — it means even heavy users are unlikely to hit the limit. The 1 million token context window means Gemini can see far more of your codebase than any competitor at any price point.

The catch? A few things:

Regional availability. Not available everywhere. If you are in a country where Google has not launched the individual tier, this is a non-starter.
Personal Gmail only. If your primary development environment is tied to a Google Workspace account (company email), you cannot use the free individual tier. You would need a separate personal Gmail account.
Agent mode shares quota. Gemini Code Assist includes agent mode, but it shares daily usage limits with Gemini CLI. Heavy agentic work will eat into your overall quota.
Context window is 128K, not 1M. While the underlying Gemini model supports up to 1M tokens, Code Assist's input context is limited to 128,000 tokens. Still generous, but not the unlimited codebase scanning some marketing implies.
Quality variance. Google's code completions have improved enormously, but in our testing, they are still less consistently accurate than GitHub Copilot for some language-specific idioms, particularly in TypeScript/React codebases. This is subjective and improving rapidly.

For raw volume of completions and chat, Gemini Code Assist Free is the clear winner. Install it, use it as your primary autocomplete engine, and you probably will not notice you are on a free tier for completion work.

GitHub Copilot Free: The Reliable Baseline

Copilot Free is what most developers already have installed. It ships with VS Code, activates with any GitHub account, and just works. The problem is the limits.

2,000 completions per month is about 65 per day — enough for light coding sessions, not enough for a full day of work. The 50 chat messages per month means you get roughly 1-2 per day, which makes Copilot Chat almost useless on the free tier. This is clearly designed to get you hooked on autocomplete and then push you to the $10/month Pro tier.

Where Copilot Free still matters:

IDE integration quality. Copilot's VS Code integration is the most polished of any tool. Ghost text appears naturally, suggestions feel well-timed, and the latency is consistently low.
Multi-file awareness. Even on the free tier, Copilot uses context from open files to inform completions. It is not just looking at the current file.
Broad language support. Copilot handles edge-case languages and frameworks better than Gemini in many cases, thanks to years of training on GitHub repositories.

In the $0/month stack, Copilot Free is not your primary tool — it is your secondary, used when Gemini does not have an extension for your IDE or when you want a second opinion on a completion.

Windsurf Free: Powerful but Opaque

Windsurf (formerly Codeium) built its reputation on offering genuinely unlimited free autocomplete. That changed on March 19, 2026, when they moved to a quota-based system. The community reaction was predictably hostile — developers who had integrated Windsurf into daily workflows suddenly faced throttling.

The current free tier:

Tab completions remain unlimited in name, but with daily and weekly quotas for AI-powered features (Cascade flows, chat, and more advanced completions).
Exact quota numbers are not publicly documented. This is a deliberate choice by Windsurf, and it makes planning around the free tier difficult.
Community reports suggest 3-5 meaningful Cascade sessions per day before hitting the wall. After that, you wait for the daily or weekly reset.

Windsurf's strength is its Cascade system — a multi-step AI workflow that can edit across multiple files, understand project context, and execute complex refactors. This is more powerful than basic autocomplete. But on the free tier, you get a taste rather than a full experience.

The main argument for including Windsurf in a free stack: it is a standalone IDE (forked from VS Code), which means you can run it alongside your primary editor. When your Gemini or Copilot quota runs low on a particular feature, you can switch to Windsurf for its remaining daily quota.

Ollama: The Unlimited Local Fallback

Ollama is not a coding assistant in the traditional sense. It is a model runtime that lets you run open-source LLMs locally on your own hardware. But with the right setup, it becomes a zero-cost, zero-limit, zero-privacy-risk coding companion.

We wrote a full Ollama + Open WebUI self-hosting guide that covers installation, model selection, and deployment in detail. Here is the coding-specific angle:

For code completion: Use Ollama with the Continue extension in VS Code. Point it at a code-specialized model like DeepSeek Coder V2 or CodeQwen 2.5, and you get autocomplete that works entirely offline. Quality depends on your hardware and model choice — a Mac with 16GB+ RAM can run 7B-14B models comfortably.

For chat/debugging: Run a larger model (Llama 3.3 70B if your hardware supports it, or Llama 3.1 8B for lower-end machines) and use it for code explanations, debugging help, and review. It will not match GPT-4 or Claude quality, but for "explain this error" or "what does this regex do," it is more than adequate.

For privacy: This is where Ollama is unbeatable. Every prompt stays on your machine. If you work with proprietary code, client data, or anything you cannot send to a cloud provider, Ollama is not just free — it is the only option that makes compliance teams happy.

The trade-off is clear: Ollama is unlimited and private, but the model quality is lower than cloud-based tools. It is the safety net in your $0/month stack, not the primary tool.

The $0/Month Stack: How to Combine Everything

Here is the exact stack we recommend for developers who want comprehensive AI coding assistance at zero cost.

Primary: Gemini Code Assist Free (Autocomplete + Chat)

Install the Gemini Code Assist extension in VS Code (or JetBrains). This becomes your main autocomplete engine. With 180,000 completions per month and 240 chat messages per day, you will rarely hit limits for day-to-day coding.

Use for:

All autocomplete work
Quick code questions and explanations (up to 240/day)
Agent mode for multi-step tasks (watch your daily agent limits)
Large-context analysis (128K token window is generous for a free tool)

Secondary: GitHub Copilot Free (Fallback + Second Opinion)

Keep Copilot installed and active. When Gemini's suggestion does not look right, Copilot's suggestion might. Use your 2,000 completions per month strategically — do not waste them on boilerplate that Gemini handles well.

Use for:

Second-opinion completions on complex logic
IDE-specific features where Copilot's VS Code integration is stronger
Framework-specific patterns where Copilot's training data excels (React, Next.js, Rails, etc.)

Tertiary: Windsurf Free (Multi-File Refactoring)

Install Windsurf IDE for when you need Cascade's multi-file editing capabilities. Do not use it for basic autocomplete — save your quota for the tasks that justify Windsurf's strengths.

Use for:

Multi-file refactors and complex edits
Project-wide code analysis
When you need an AI to understand and modify multiple interconnected files

Emergency Fallback: Ollama (Unlimited + Offline)

Set up Ollama with a code-specific model for when cloud tools are throttled, offline, or you need privacy.

Use for:

After-hours coding when you have burned through daily quotas
Offline development (travel, unreliable internet)
Private/proprietary code that cannot be sent to cloud providers
Experimentation and learning without usage anxiety

Daily Workflow Example

Here is what a typical day looks like with the $0/month stack:

Morning (fresh quotas):

Open VS Code with Gemini Code Assist as primary autocomplete
Write new features using Gemini completions and chat for questions
Copilot runs in background for occasional second-opinion suggestions

Afternoon (quota-aware):

If you need a multi-file refactor, open Windsurf and use a Cascade session
Continue using Gemini for autocomplete (180K monthly limit means daily usage is rarely an issue)
Use Copilot Chat sparingly (50/month budget)

Evening (quotas getting low):

Switch to Ollama for any remaining coding if Windsurf's daily quota is exhausted
Use Ollama for code review and debugging conversations without usage anxiety

This is not a perfect substitute for a paid $20/month tool. But for most individual developers, it covers 80-90% of what you would use a paid tool for.

Setting Up Each Tool (VS Code Focus)

1. Gemini Code Assist Free Setup

Requirements: Personal Gmail account (not Google Workspace), supported region.

Open VS Code → Extensions → Search "Gemini Code Assist"
Install the official Google extension
Click "Sign in with Google" in the sidebar
Sign in with your personal Gmail account
Completions start immediately — no configuration needed

Recommended settings:

{
  "geminicodeassist.enable": true,
  "geminicodeassist.inlineSuggest.enable": true
}

Tip: Gemini Code Assist also works in JetBrains IDEs (IntelliJ, PyCharm, WebStorm), Android Studio, and even Xcode. If you use multiple IDEs, install it everywhere — the 180,000 monthly limit is shared across all installations.

2. GitHub Copilot Free Setup

Requirements: GitHub account (free).

Open VS Code → Extensions → Search "GitHub Copilot"
Install the official GitHub extension
Sign in with your GitHub account
The free tier activates automatically if you do not have a paid plan

Recommended settings to avoid wasting completions:

{
  "github.copilot.enable": {
    "*": true,
    "markdown": false,
    "plaintext": false
  }
}

Disabling Copilot for markdown and plaintext prevents it from burning completions on non-code files.

3. Windsurf IDE Setup

Requirements: Windsurf account (free).

Download Windsurf from windsurf.com
Install and open — it looks and feels like VS Code because it is a fork
Your VS Code extensions and settings can be imported
Sign up for a free account to activate AI features
Use Cascade (Cmd/Ctrl+I) for multi-step editing tasks

Note: You can run Windsurf alongside VS Code. They do not conflict. Use VS Code as your primary editor with Gemini/Copilot, and switch to Windsurf when you need Cascade specifically.

4. Ollama + Continue Setup

Requirements: Mac with 8GB+ RAM (16GB+ recommended), or Linux machine.

Install Ollama:

# macOS
brew install ollama

# Linux
curl -fsSL https://ollama.com/install.sh | sh

Pull a code-specific model:

# Good balance of quality and speed for coding
ollama pull deepseek-coder-v2:16b

# Lighter option for lower-end hardware
ollama pull codeqwen:7b

Install the Continue extension in VS Code:
- Extensions → Search "Continue" → Install
- Configure to point at your local Ollama instance
Configure Continue (.continue/config.json):

{
  "models": [
    {
      "title": "DeepSeek Coder V2",
      "provider": "ollama",
      "model": "deepseek-coder-v2:16b"
    }
  ],
  "tabAutocompleteModel": {
    "title": "CodeQwen",
    "provider": "ollama",
    "model": "codeqwen:7b"
  }
}

For a deeper dive on Ollama setup, model selection, and performance tuning, see our complete Ollama + Open WebUI guide.

Managing Multiple AI Extensions Without Conflicts

Running Gemini Code Assist and GitHub Copilot simultaneously in VS Code is possible but requires configuration to avoid competing suggestions.

Option A: Prioritize one, disable inline suggestions on the other.

Set Gemini as your primary autocomplete and use Copilot only for its chat:

{
  "github.copilot.enable": { "*": false },
  "geminicodeassist.inlineSuggest.enable": true,
  "editor.inlineSuggest.enabled": true
}

This prevents Copilot from using your 2,000 monthly completions on autocomplete while keeping Copilot Chat available.

Option B: Use different tools for different languages.

If you find that Copilot is better for TypeScript but Gemini excels at Python:

{
  "github.copilot.enable": {
    "typescript": true,
    "typescriptreact": true,
    "*": false
  },
  "geminicodeassist.inlineSuggest.enable": true
}

Option C: Run them both and let VS Code arbitrate.

VS Code shows inline suggestions from whichever provider responds first. This burns through Copilot completions faster, but some developers prefer the "best of both" approach. We do not recommend this on the free tier unless you are a light coder.

Honest Limitations: When You Need to Upgrade to Paid

The $0/month stack has real limitations. Here is where free tiers fall short:

1. Agentic Coding Tasks

Free tools in 2026 offer limited or no true agentic capabilities. Gemini Code Assist has agent mode with daily limits, but for sustained multi-step autonomous coding — the kind where an AI reads your codebase, plans changes across 10 files, runs tests, and iterates — you need a paid tool.

This is where Claude Code changes the game. It is a terminal-based agent that operates across your entire repository, understands project context through CLAUDE.md files, and can handle complex multi-step tasks autonomously. We use it daily to run our 14-agent AI company. Nothing in the free tier space comes close.

If agentic coding is your primary use case, see our deep comparison of Codex vs Claude Code for a full breakdown.

2. Heavy Chat/Debugging Usage

The free tier chat limits are adequate for quick questions but not for the "pair programming" workflow where you have an extended back-and-forth with an AI about architecture decisions, debugging complex issues, or reviewing large code blocks. Gemini's 240 messages per day is decent, but Copilot's 50 per month is almost nothing.

3. Team Features

Free tiers are designed for individual developers. If you need shared context, admin controls, usage analytics, or consistent tooling across a team, you need paid plans.

4. Consistent Quality at Scale

When you are shipping production code on a deadline, you want the best model available without worrying about quotas, throttling, or model rotation. Paid tools give you guaranteed access to frontier models.

5. The Vibe Coding Workflow

Vibe coding — the practice of describing what you want in natural language and letting AI write the implementation — works best with powerful agentic tools and generous context windows. Free tiers support basic vibe coding sessions, but the moment you want sustained autonomous development across multiple files, you hit limits quickly.

When It Makes Sense to Upgrade: Recommended Paid Options

If you have been using the $0/month stack and keep hitting walls, here are the three paid upgrades that offer the best value:

GitHub Copilot Pro — $10/month

The most cost-effective first upgrade. Unlimited completions remove the 2,000/month ceiling, and premium model access gives Copilot Chat genuine depth. If autocomplete volume is your main bottleneck, this solves it at the lowest cost.

Best for: Developers whose primary pain point is running out of completions.

Cursor Pro — $20/month

If you want a more integrated AI-native IDE experience, Cursor Pro gives you 500 fast premium requests per month with multi-file editing, agentic features, and a polished development environment. The credit-based billing system means you pay for what you use beyond the base allowance.

Best for: Developers who want AI deeply integrated into their editing workflow with multi-file capabilities.

Claude Code (Claude Pro) — $20/month

Claude Code is not an IDE plugin — it is a terminal-based coding agent. It reads your entire repository, understands project conventions, and executes multi-step tasks autonomously. If you have tried the free stack and your main frustration is "I wish the AI could just handle this entire feature," Claude Code is the answer.

We wrote an advanced Claude Code workflow guide that covers subagents, custom commands, and multi-session patterns for developers who want to go deep.

Best for: Developers who need autonomous, multi-step coding across large codebases.

For a complete pricing comparison across all tools and tiers, see our full pricing breakdown.

Frequently Asked Questions

Can I really use Gemini Code Assist Free for commercial projects?

Yes. Google's free individual tier has no restrictions on commercial use. The code you write using Gemini completions is yours. This is the same approach GitHub Copilot takes with its free tier.

Will running multiple AI extensions slow down VS Code?

Slightly. Each extension consumes memory and makes network requests. On a modern machine with 16GB+ RAM, the impact is negligible. On an 8GB machine, you might notice slightly longer startup times. The configuration options in the "Managing Multiple Extensions" section above let you minimize resource usage by disabling inline suggestions on secondary tools.

Is Ollama good enough for code completion?

For basic completions, yes — especially with code-specialized models like DeepSeek Coder V2 or CodeQwen. It will not match the quality of Gemini or Copilot's cloud-based models, but for common patterns, boilerplate, and straightforward code, it is surprisingly capable. Think of it as 70-80% of cloud quality at 0% of the cost and 100% privacy.

What about Amazon Q Developer (formerly CodeWhisperer)?

Amazon Q Developer offers a free tier with code completions and security scanning. It is worth considering if you work primarily in the AWS ecosystem. We did not include it in the primary stack because its IDE support is narrower and its completions tend to favor AWS-specific patterns, but it is a viable addition for AWS-focused developers.

What happens when the free tiers change or get worse?

This is the risk with any free tool. Windsurf's March 2026 pricing change is a cautionary example. The $0/month stack approach mitigates this risk through diversification — if one tool reduces its free tier, you still have three others providing coverage. Ollama, being fully local and open-source, will never change its pricing.

The Bottom Line

The $0/month AI coding stack in 2026 is genuinely viable for individual developers, hobbyists, students, and anyone who cannot justify $20-30/month for AI coding tools. Gemini Code Assist Free is the centerpiece — its 180,000 monthly completions and 240 daily chat messages cover the vast majority of daily coding needs. Layer in Copilot Free for a second opinion, Windsurf for occasional multi-file work, and Ollama for privacy and unlimited fallback.

Is it as good as a paid setup? No. You will miss agentic capabilities, hit quota walls during intense coding sessions, and juggle multiple tools where a single paid subscription would be simpler. But for most development work — writing features, fixing bugs, learning new frameworks, building side projects — the free stack gets the job done.

Start with Gemini Code Assist Free as your primary tool. Add the others one by one as you discover what you need. And when you are ready to upgrade, you will know exactly which paid tool fills the gap that matters most to you.

Hetzner Cloud for AI Projects — Complete GPU Server Setup & Cost Breakdown 2026

Jangwook Kim — Sat, 04 Apr 2026 03:49:53 +0000

Hetzner Cloud for AI Projects — Complete GPU Server Setup & Cost Breakdown 2026

Running AI workloads on AWS or GCP is expensive. A single A100 instance on AWS costs $3-4 per hour — over $2,000 a month if you leave it running. For startups, indie developers, and small teams experimenting with AI, that math kills projects before they start.

Hetzner offers an alternative that most of the AI community outside Europe has not discovered yet. Budget cloud instances from €3.99/month for lightweight inference. Dedicated GPU servers with NVIDIA RTX 4000 Ada from €184/month. European data centers with flat monthly pricing and no bandwidth surprises.

This guide covers the full Hetzner AI server lineup, from $5/month CPU instances running tiny models to dedicated GPU servers handling production workloads. We will walk through actual setup, realistic performance expectations, and an honest cost comparison against AWS and GCP.

Why Hetzner for AI Workloads

Hetzner is a German hosting company that has been around since 1997. They are not a startup. They run their own data centers in Falkenstein, Nuremberg, and Helsinki. Their pricing has always been aggressive compared to US-based cloud providers, and that gap has only widened as AWS and GCP have raised prices.

The Price Gap Is Real

Hetzner's cost advantage is not 10-20% — it is 60-80% for equivalent compute. A Hetzner cloud server with 2 vCPUs and 4 GB RAM costs €3.99/month. A comparable instance on AWS (t3.medium) costs roughly $30/month. DigitalOcean and Vultr sit in between at $15-20/month for similar specs.

For AI workloads specifically, the gap gets even wider at the GPU tier. Hetzner's dedicated GPU servers start at €184/month. AWS GPU instances (g5.xlarge with A10G) start at roughly $1.00/hour — over $700/month for always-on use.

What Hetzner Does Well

Flat monthly pricing. No surprise bandwidth bills, no hidden egress charges. Traffic is unlimited on most plans.
EU data centers. Falkenstein and Helsinki give you GDPR compliance by default.
Straightforward networking. Private networks, floating IPs, and load balancers at prices that make sense.
ARM instances. Ampere-based CAX servers offer strong performance-per-euro for inference workloads.

What Hetzner Does Not Do

No managed AI/ML services. No SageMaker equivalent, no managed Jupyter, no model registries. You manage everything yourself.
No spot/preemptible instances. You cannot get cheap burst GPU time. It is flat monthly pricing or nothing.
Limited GPU availability. Dedicated GPU servers can have waitlists. AWS and GCP have broader GPU SKU availability.
No US data centers. If you need sub-50ms latency for US users, Hetzner is not the right choice.

The Hetzner AI Server Lineup

Hetzner offers multiple tiers for AI workloads. Here is the full spectrum from budget to production.

Tier 1: Cost-Optimized Cloud (CX Series) — €3.99-€14.99/mo

These are shared vCPU instances. No GPU. CPU-only inference for small models.

Model	vCPU	RAM	Storage	Price
CX23	2	4 GB	40 GB SSD	€3.99/mo (~$4.99)
CX33	4	8 GB	80 GB SSD	€6.49/mo (~$8.09)
CX43	8	16 GB	160 GB SSD	€11.99/mo (~$14.99)
CX53	16	32 GB	320 GB SSD	€22.49/mo (~$28.09)

AI use case: Running Ollama with small models (3B-7B parameters) for personal chatbots, lightweight RAG, or API-based inference for low-traffic applications. We covered this exact setup in our Ollama + Open WebUI self-hosting guide.

Realistic expectations: A CX23 can run a 3B model at roughly 3-6 tokens/second (CPU inference). A CX33 can handle a 7-8B model at 1-3 tokens/second. This is usable for async workflows but not for interactive chat.

Tier 2: ARM Cloud Instances (CAX Series) — Better Performance per Euro

Hetzner's Ampere-based ARM servers offer better compute efficiency than the x86 CX series at similar or lower price points.

Model	vCPU (ARM)	RAM	Storage	Price
CAX11	2	4 GB	40 GB SSD	€4.49/mo (~$5.59)
CAX21	4	8 GB	80 GB SSD	€7.99/mo (~$9.99)
CAX31	8	16 GB	160 GB SSD	€15.99/mo (~$19.99)
CAX41	16	32 GB	320 GB SSD	€31.49/mo (~$39.29)

AI use case: ARM chips handle inference workloads efficiently. Ollama has native ARM support, so these servers run small models with lower power draw and often better single-thread performance than the CX series at the same price. Good for always-on inference APIs.

Tier 3: GEX44 — Dedicated GPU Server (€184/mo)

This is where things get serious for AI workloads.

Spec	Details
CPU	Intel Core i5-13500 (6P + 8E cores, HT)
GPU	NVIDIA RTX 4000 SFF Ada Generation, 20 GB GDDR6 ECC
RAM	64 GB DDR4
Storage	2× 1.92 TB NVMe SSD Gen3 (RAID 1)
Network	1 Gbit/s, unlimited traffic
Setup fee	€79 (one-time)
Monthly	€184/mo
Locations	Falkenstein (FSN1), Nuremberg (NBG1)

AI use case: The RTX 4000 SFF Ada with 20 GB VRAM can run models up to ~32B parameters (4-bit quantized). It handles 7B-14B models comfortably with fast inference. This is the sweet spot for small teams running production AI inference, fine-tuning smaller models, or serving multiple users simultaneously.

The 20 GB of VRAM is the key spec. It puts this server above consumer RTX 4060/4070 cards (8-12 GB) and into territory where you can run meaningful models without aggressive quantization.

Tier 4: GEX131 — High-End GPU Server

For production AI workloads that need serious GPU compute.

Spec	Details
CPU	Intel Xeon Gold 5412U
GPU	NVIDIA RTX PRO 6000 Blackwell Max-Q, 96 GB GDDR7 ECC
RAM	256 GB DDR5 ECC (expandable to 768 GB)
Storage	2× 960 GB NVMe SSD Datacenter Edition (RAID 1)
Network	1 Gbit/s, unlimited traffic
Monthly	€889/mo (~$989)
Locations	Helsinki (HEL1), Falkenstein (FSN1), Nuremberg (NBG1)

AI use case: With 96 GB of VRAM, this server can run 70B+ parameter models at full precision, handle multiple concurrent inference requests, or fine-tune large models. The 5th-generation Tensor Cores and Blackwell architecture make this competitive with cloud A100 instances at a fraction of the cost.

256 GB of system RAM with expansion to 768 GB also makes this viable for large-scale RAG deployments where you need to keep embedding databases in memory.

Budget Path: Running Small LLMs on CX/CAX Instances

You do not need a GPU to run AI inference. CPU-only inference with quantized models is slow but functional — and incredibly cheap.

What You Can Run

On a CX23 (€3.99/month, 4 GB RAM):

Llama 3.2 3B (Q4) — Fits in ~2-3 GB. General chat and simple tasks.
Phi-3.5 Mini 3.8B (Q4) — Microsoft's efficient model. Good for code and reasoning.
TinyLlama 1.1B — Fast even on CPU. Useful for classification and simple generation.

On a CX33 (€6.49/month, 8 GB RAM):

Llama 3.2 8B (Q4) — Solid general model. ~5 GB loaded.
Gemma 2 2B — Google's efficient model. Punches above its weight.
Qwen 2.5 7B (Q4) — Excellent for multilingual use cases.

Setup

Install Docker and run Ollama:

# Install Docker
curl -fsSL https://get.docker.com | sh

# Run Ollama
docker run -d --name ollama -p 11434:11434 \
  -v ollama_data:/root/.ollama \
  ollama/ollama:latest

# Pull a model
docker exec -it ollama ollama pull llama3.2:3b

For a full web interface, add Open WebUI as described in our Ollama self-hosting guide. If you are running multiple services on the same server, a deployment platform like Coolify or Dokploy simplifies container management significantly.

Performance Reality Check

CPU inference is measured in single-digit tokens per second. Here is what to expect:

Model	Server	Speed (approx.)	Usability
TinyLlama 1.1B	CX23	[ESTIMATED] 8-15 tok/s	Responsive for short queries
Llama 3.2 3B	CX23	[ESTIMATED] 3-6 tok/s	Slow but usable
Llama 3.2 8B	CX33	[ESTIMATED] 1-3 tok/s	Async workflows only
Qwen 2.5 7B	CX33	[ESTIMATED] 1-3 tok/s	Async workflows only

These numbers are usable for: API backends with tolerant timeouts, batch processing, personal assistants where you can wait a few seconds, and development/testing before deploying to GPU servers.

They are not usable for: real-time chat with multiple users, latency-sensitive applications, or anything requiring more than a few concurrent requests.

GPU Path: Setting Up the GEX44

The GEX44 at €184/month is the entry point for serious AI work on Hetzner. Here is how to set it up from scratch.

Step 1: Order and Initial Access

Order from the Hetzner Robot panel. Expect the €79 setup fee on your first invoice. Provisioning typically takes 1-3 business days for dedicated servers (unlike cloud instances which spin up in seconds).

Once provisioned, you will receive root SSH access:

ssh root@your-server-ip

Step 2: Install NVIDIA Drivers

The GEX44 comes with bare metal access. You need to install GPU drivers:

# Update system
apt update && apt upgrade -y

# Install NVIDIA driver dependencies
apt install -y build-essential linux-headers-$(uname -r)

# Install NVIDIA drivers (Ubuntu 22.04/24.04)
apt install -y nvidia-driver-550

# Reboot
reboot

After reboot, verify the GPU is recognized:

nvidia-smi

You should see the RTX 4000 SFF Ada with 20 GB VRAM listed.

Step 3: Install Docker with GPU Support

# Install Docker
curl -fsSL https://get.docker.com | sh

# Install NVIDIA Container Toolkit
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | \
  gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg

curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
  sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
  tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

apt update && apt install -y nvidia-container-toolkit
nvidia-ctk runtime configure --runtime=docker
systemctl restart docker

Verify Docker can see the GPU:

docker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi

Step 4: Deploy Ollama with GPU Acceleration

Create docker-compose.yml:

version: "3.8"

services:
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    restart: unless-stopped
    ports:
      - "11434:11434"
    volumes:
      - ollama_data:/root/.ollama
    environment:
      - OLLAMA_NUM_PARALLEL=4
      - OLLAMA_MAX_LOADED_MODELS=2
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    restart: unless-stopped
    ports:
      - "3000:8080"
    volumes:
      - open_webui_data:/app/backend/data
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
      - WEBUI_AUTH=true
      - WEBUI_SECRET_KEY=change-this-to-a-random-string
    depends_on:
      - ollama

volumes:
  ollama_data:
  open_webui_data:

docker compose up -d

Step 5: Pull Models That Fit 20 GB VRAM

With 20 GB of VRAM, you can run substantial models:

# 14B model — fits easily, fast inference
docker exec -it ollama ollama pull phi-4:14b

# 32B model (Q4) — fits in ~18 GB, good quality
docker exec -it ollama ollama pull qwen2.5:32b-instruct-q4_K_M

# Coding-specific model
docker exec -it ollama ollama pull qwen2.5-coder:14b

What the GEX44 Can Actually Run

Model	VRAM Usage	Speed (GPU)	Quality
Llama 3.2 8B	~5 GB	[ESTIMATED] 40-60 tok/s	Good general use
Phi-4 14B	~8 GB	[ESTIMATED] 25-40 tok/s	Strong reasoning
Qwen 2.5 Coder 14B	~8 GB	[ESTIMATED] 25-40 tok/s	Excellent for code
Qwen 2.5 32B (Q4)	~18 GB	[ESTIMATED] 12-20 tok/s	High quality writing
Llama 3.3 70B (Q4)	~35 GB	Does not fit	—

The sweet spot is 14B models. They fit comfortably in 20 GB with room for context, run at speeds that feel interactive, and deliver quality that is genuinely useful for production work.

Step 6: Set Up HTTPS

For remote access, add Caddy as a reverse proxy:

apt install -y caddy

Edit /etc/caddy/Caddyfile:

ai.yourdomain.com {
    reverse_proxy localhost:3000
}

systemctl reload caddy

Caddy handles SSL automatically. Access your AI at https://ai.yourdomain.com.

Cost Comparison: Hetzner vs AWS vs GCP

Here is an honest comparison for equivalent GPU compute, based on always-on monthly pricing as of early 2026.

Entry-Level GPU Tier

Provider	Instance	GPU	VRAM	Monthly Cost
Hetzner	GEX44	RTX 4000 SFF Ada	20 GB	€184/mo (~$230)
AWS	g5.xlarge	A10G	24 GB	~$760/mo
GCP	g2-standard-4	L4	24 GB	~$580/mo
Lambda	gpu_1x_a10	A10	24 GB	~$440/mo

Hetzner is 2.5-3.3× cheaper than hyperscalers for comparable GPU compute. The trade-offs: no managed ML services, manual setup, and EU-only data centers.

Budget CPU Tier (No GPU)

Provider	Instance	vCPU	RAM	Monthly Cost
Hetzner	CX23	2	4 GB	€3.99/mo (~$5)
AWS	t3.medium	2	4 GB	~$30/mo
GCP	e2-medium	2	4 GB	~$25/mo
DigitalOcean	Basic	2	4 GB	~$18/mo

At the budget tier, Hetzner is 4-6× cheaper. This is where it shines for development, testing, and low-traffic inference.

What the Cloud Providers Offer That Hetzner Does Not

AWS SageMaker / GCP Vertex AI — Managed model training, deployment, and monitoring. If you need MLOps at scale, Hetzner's bare metal cannot compete.
Spot/preemptible instances — AWS spot pricing can bring GPU costs down 60-70% for interruptible workloads. Hetzner has no equivalent.
Global regions — AWS has 30+ regions worldwide. Hetzner has 3 European locations.
Auto-scaling — Cloud providers scale GPU instances based on demand. Hetzner dedicated servers are fixed capacity.

Bottom line: Hetzner wins on predictable, always-on workloads where you know your compute needs. Hyperscalers win on variable demand, managed services, and global distribution.

Deployment with Docker and Coolify

If you are running multiple AI services (Ollama, vector databases, monitoring) alongside other applications on the same Hetzner server, manual Docker Compose management gets tedious.

This is where a self-hosted PaaS like Coolify or Dokploy adds value. We compared both platforms in detail in our Coolify vs Dokploy comparison. The short version:

Coolify — More mature, better for multi-service deployments, built-in database management.
Dokploy — Simpler, lighter footprint, good if Ollama is your primary workload.

Either one gives you a web dashboard for managing containers, automatic SSL, Git-based deployments, and basic monitoring — without touching the command line every time you need to update a container.

For a full walkthrough of running Coolify on Hetzner alongside other developer tools, see our self-hosting dev stack guide.

Our Infrastructure at Effloow

At Effloow, we run 14 AI agents that handle everything from content research to code generation. Our infrastructure choices reflect the same cost-conscious thinking behind this guide.

We use Hetzner cloud instances for non-GPU workloads: deployment platforms, Git hosting, monitoring, and lightweight services. The flat monthly pricing means our infrastructure bill is predictable regardless of how many articles the agents produce.

For AI inference specifically, we use a mix of API services (Claude, GPT) for tasks requiring frontier intelligence and self-hosted models for high-volume, lower-complexity work. The GEX44 tier is compelling for teams at our stage — it is enough GPU to run production inference at a cost that does not require venture capital to sustain.

The decision framework we use internally:

Need frontier intelligence (complex reasoning, creative work)? → Use API services.
Need high-volume, predictable inference? → Self-host on Hetzner GPU.
Need lightweight, always-on AI? → CX/CAX instance with small models.
Need managed MLOps at scale? → Use AWS/GCP (we do not, but many teams should).

Choosing the Right Tier

Here is a quick decision guide:

CX23 (€3.99/mo) — Start Here If...

You are experimenting with self-hosted AI for the first time
You need a personal chatbot or simple RAG pipeline
Your queries are infrequent and latency is not critical
Budget is the primary constraint

CX33/CAX31 (€6.49-€10/mo) — Upgrade When...

You need 7-8B models with slightly better response times
You are running the AI alongside other services (Git, CI, monitoring)
Multiple people on your team need occasional access

GEX44 (€184/mo) — The AI Sweet Spot If...

You need interactive-speed inference (30+ tokens/second)
You want to run 14B-32B models with real quality
Multiple users need concurrent access
You are building products or services that rely on AI inference
Fine-tuning smaller models is part of your workflow

GEX131 — Production AI If...

You need 70B+ models at full precision
Multi-user production inference is a requirement
You are fine-tuning large models regularly
You need 96 GB VRAM for large embedding databases or multi-model serving

Getting Started: Your First Hour

If you are new to Hetzner, here is the fastest path to running AI:

# 1. Sign up at hetzner.com and create a cloud project

# 2. Create a CX23 instance (€3.99/mo) via the console
#    - Choose Ubuntu 24.04
#    - Add your SSH key
#    - Pick Falkenstein or Helsinki

# 3. SSH into your server
ssh root@your-server-ip

# 4. Install Docker
curl -fsSL https://get.docker.com | sh

# 5. Run Ollama
docker run -d --name ollama -p 11434:11434 \
  -v ollama_data:/root/.ollama ollama/ollama:latest

# 6. Pull a small model
docker exec -it ollama ollama pull llama3.2:3b

# 7. Test it
curl http://localhost:11434/api/generate \
  -d '{"model": "llama3.2:3b", "prompt": "Hello, how are you?"}'

Total time: under 10 minutes. Total cost: €3.99 for the first month.

When you outgrow the CX23, migrate your Ollama data volume to a bigger instance. When you need GPU speed, order a GEX44 and follow the GPU setup section above.

Conclusion

Hetzner is not the right choice for every AI workload. If you need managed ML services, global data centers, or spot pricing for burst GPU compute, the hyperscalers are still the answer.

But for predictable, always-on AI infrastructure at a fraction of the cost — personal AI assistants, team inference servers, self-hosted chatbots, development and testing environments — Hetzner is hard to beat.

The lineup covers the full spectrum: €3.99/month for experimentation, €184/month for production GPU inference, and higher tiers for serious AI workloads. All with flat pricing, unlimited bandwidth, and EU data residency.

Start with a CX23 and a 3B model. See if self-hosted inference fits your workflow. If it does, the upgrade path is straightforward — bigger instances, better models, and eventually dedicated GPU hardware, all from the same provider.