AI Coding Cost per Dockerfile: Generating Docker and Compose Configs

Containers are one of the best-fit tasks for AI coding agents. Dockerfiles and docker-compose files are boilerplate-heavy, follow well-documented patterns, and the model has seen millions of them. But the sticker price of "write me a Dockerfile" hides a real iteration cost — and if you don't estimate for it, a five-cent task quietly becomes a fifty-cent one. This is part of our "AI-assisted X: cost per Y" series, focused on the container layer.

Why Containers Are a Good AI Task (With a Catch)

A Dockerfile is small, patterned output. The model knows how to install dependencies, set a workdir, expose a port, and define an entrypoint without much prompting. That makes the first draft cheap and usually close to correct. The catch is everything after the first draft:

• Base image choice. Alpine vs. slim vs. distroless changes what breaks at build time.
• Multi-stage builds. Getting the build stage and runtime stage to hand off correctly takes iterations.
• Layer caching. Ordering COPY and RUN steps for cache efficiency is easy to get subtly wrong.
• Debugging failed builds. A missing system library or a wrong architecture flag sends the agent back into the loop.

The output is small; the iteration cost dominates. That is the profile you have to estimate.

The Token Profile of Container Generation

A single Dockerfile is only ~500–1,500 output tokens. What actually drives cost is the input context and the number of debugging passes. The input includes your package manifests (package.json, requirements.txt, go.mod), any existing config, and the model's own best-practice reasoning about base images and build order. Every failed docker build that feeds an error back into the agent is another pass — and each pass re-sends the accumulated context.

Worked Example — Containerizing a Node + Postgres App

Take a common task: containerize a Node service with a Postgres dependency, producing a Dockerfile plus a docker-compose.yml that wires the two together. A realistic per-pass profile is ~8,000 input tokens (package.json, existing scripts, env config, your instructions) and ~2,000 output tokens (the Dockerfile, the compose file, and a short explanation). Budget ~4 passes: the initial draft, then fixes for build errors, a missing native dependency, and the compose networking between app and database.

Totals across 4 passes: 32,000 input tokens (0.032M) and 8,000 output tokens (0.008M). Here is the cost on four models:

• DeepSeek V3.2 (in $0.229 / out $0.343): (0.032M × $0.229) + (0.008M × $0.343) ≈ $0.007 + $0.003 = $0.010
• Qwen3 Coder (in $0.22 / out $1.80): (0.032M × $0.22) + (0.008M × $1.80) ≈ $0.007 + $0.014 = $0.021
• Haiku 4.5 (in $1 / out $5): (0.032M × $1) + (0.008M × $5) = $0.032 + $0.040 = $0.072
• Sonnet 5 (in $2 / out $10): (0.032M × $2) + (0.008M × $10) = $0.064 + $0.080 = $0.144

One containerized service costs about a penny on DeepSeek V3.2 and about 14 cents on Sonnet 5 — a 14x spread. For pure boilerplate that builds on the first or second try, the cheap tier is hard to beat.

How It Scales to a Multi-Service Compose File

A real docker-compose.yml rarely has one service. Add a Redis cache, a worker, and an Nginx reverse proxy and you are generating four service definitions plus shared networks and volumes. Cost roughly scales per service, because each new service adds its own Dockerfile context and its own class of build errors. A four-service compose setup lands near 4x the single-service number on the per-service work, plus a modest overhead pass to reconcile networking and dependencies.

In practice that is still cheap: roughly $0.04–$0.06 on DeepSeek V3.2 or $0.55–$0.70 on Sonnet 5 for the whole stack. The number that hurts is not the tokens — it is the wall-clock time of failed builds if you did not give the model enough context up front.

Cost-Saving Tips for Container Work

1. Give exact runtime versions up front. Tell the model "Node 22.3, Postgres 17, Debian bookworm base." Wrong guesses cause failed builds, and every failed build is another paid iteration. Precise input is the cheapest cost control there is.
2. Route by difficulty. Use a cheap model like DeepSeek V3.2 or Qwen3 Coder for boilerplate Dockerfiles, and reserve a premium model for tricky multi-stage optimization or shaving image size.
3. Paste the actual build error, not the whole log. A 500-line build log is mostly noise; the model needs the failing step and the error line. Trimming it cuts input tokens on every retry pass.
4. Reuse a known-good base as a template. Hand the model a working Dockerfile from a similar service and ask for the delta. Fewer wrong guesses, fewer iterations.

The Bottom Line on Container Cost

Dockerfiles are among the cheapest things you can ask an AI to write, provided you kill the iteration cost with precise context. The output is tiny; the debugging loop is the whole ballgame. Estimate 4 passes for a real containerization task, route boilerplate to a cheap tier, and reserve premium models for the genuinely hard optimization work.

To price your own stack, drop your per-pass input, output, and iteration estimates into the AI cost calculator and compare the container job across every model tier before you run it.