# Codex Hosted vs Running Codex Yourself: An Honest Comparison

DIY Codex on a laptop, VPS, or CI runner is free and fine for personal scripts. The honest ops comparison: uptime, auth refresh, queueing, logs, and the real costs.

*Published 2026-06-12 · https://proxyllm.ai/blog/codex-hosted-vs-running-codex-yourself*

Running Codex yourself is free, documented, and for personal scripts it is the right call; we will not pretend otherwise. Codex Hosted earns its $129 when the same idea has to behave like production infrastructure: stay up, refresh auth, queue concurrent requests, survive usage windows, and log everything. This page compares the two, ops line by ops line.

## The three DIY shapes

**Laptop.** `codex exec` from your terminal or a local script. Costs nothing, works today, stops when the lid closes. Good for personal automation, unusable as an endpoint other apps depend on.

**VPS.** A $5-20 box at Hetzner or DigitalOcean running the CLI under tmux or systemd, signed in via device code. This is real self-hosting and it works; the complete walkthrough is in [running Codex CLI on a VPS](/blog/codex-cli-on-vps).

**Docker or CI.** The CLI in a container with `~/.codex` on a volume, or exec calls inside pipeline jobs. Reproducible and scriptable; auth handling is the fiddly part. Setup details live in [Codex CLI in Docker](/blog/codex-cli-docker-guide).

All three run the same free CLI on your own account, which is documented use. What differs is who carries the operations.

## The ops checklist

| Operational concern        | Laptop                   | VPS / Docker                                              | Codex Hosted             |
| -------------------------- | ------------------------ | --------------------------------------------------------- | ------------------------ |
| Uptime                     | until the lid closes     | yours to monitor                                          | managed around the clock |
| Auth refresh               | re-sign-in when prompted | detect and refresh yourself, often after a silent failure | handled in the container |
| Concurrency                | one session, no queue    | build a queue yourself                                    | queued at the gateway    |
| Usage-limit handling       | you wait for the reset   | scripts, or you wait                                      | automatic lane fallback  |
| Request logs               | none                     | build them yourself                                       | per-request, per-lane    |
| OpenAI-compatible endpoint | no                       | wrap exec yourself                                        | included                 |
| Monthly cost               | $0                       | $5-20 plus your hours                                     | $129 flat                |

Nothing in the right column is exotic. It is the same list of chores, done by software that already exists, plus someone else carrying the pager.

## What actually breaks first

Self-hosted setups fail in a consistent order. Auth goes first: the saved session eventually needs a refresh, and a headless box fails quietly, so the discovery is usually a cron job erroring at 3 a.m. Queueing goes second: `codex exec` runs sequentially per session, and two apps calling one box at the same time need a queue you have to build. Usage windows go third: a burst exhausts the plan window mid-job, and without a fallback lane the workload simply stops until the reset. The exec mechanics behind all three are covered in [the codex exec guide](/blog/codex-exec-non-interactive-mode-guide).

None of these are hard problems. They are recurring ones, and recurring is the expensive kind.

## When DIY is the right call

- Personal scripts and single cron jobs, where an outage costs you nothing.
- Learning the tool before committing to anything.
- A hard requirement to keep everything on your own metal.
- A budget of exactly $0, honestly held.

If only you notice when it breaks, self-host. We mean that.

## When hosted is the right call

- Other software, or other people, depend on the endpoint.
- You want fallback lanes (second account, API key) without writing failover logic.
- You bill clients and need per-request logs showing what ran where.
- Your hours are the scarcest line item on the books.

## The cost math, with assumptions shown

A capable VPS runs about $6 a month. Budget two to four hours a month for the chores above once the setup serves real traffic: refresh checks, queue tweaks, the occasional silent-failure post-mortem. Call it three hours.

```text
Hosted:            $129 / month
DIY:               $6 VPS + 3 hours of your time
Breakeven rate:    ($129 - $6) / 3 hours = $41 / hour
```

If your time bills above $41 an hour, three hours of monthly proxy maintenance already costs more than the hosting fee. At $100 an hour, the DIY setup costs about $306 a month in real terms. At $0 an hour, DIY wins on price, and for hobby work that is a legitimate answer.

One more honest note: the capacity economics are identical on both paths, because both run your own subscription on your own account. The comparison is purely operational. What the hosted layer includes, end to end, is in [what is Codex Hosted?](/blog/what-is-codex-hosted)

If the ops column is the part you are weighing, the [calculator](/calculator) prices the full hosted setup against your current API bill, fee included.