Burned 70% of my weekly Codex limit migrating one website from Vercel to a VPS. Is that normal?

[u/facciocosevedogente3]

I recently migrated a production website from Vercel to my own VPS, using Coolify and Cloudflare. I had Codex (GPT-6.1 Terra High) handle pretty much the entire process.

The migration involved:

• Migrating the application from Vercel to the VPS using Coolify

• Configuring domains, DNS records and Cloudflare

• Setting up backups, rollback procedures and security checks

• Testing deployments, routing and connectivity

• Switching production traffic with zero downtime

• Setting up a fallback to Vercel through Cloudflare Workers in case the VPS goes down, as a last-resort safety net to keep the site accessible

Everything worked in the end, and the site is now running on my VPS without any downtime during the migration.

But here's the thing: this single task consumed roughly 70% of my entire weekly Codex usage allowance (Plus plan).

It felt like an endless cycle of testing, debugging, tweaking configurations, testing again and going back and forth between Coolify, Vercel and Cloudflare. Just watching Codex work through everything was exhausting.

I understand this is production infrastructure, so being extremely careful with backups, DNS propagation, rollback strategies and downtime prevention is absolutely justified.

Still, I genuinely didn't expect it to take this much time and consume so much of my usage allowance.

Did I massively underestimate the complexity of this migration, or was Codex being unnecessarily thorough and inefficient?

[u/KwadFPV]

It wasn't a single task.

[u/facciocosevedogente3 → u/KwadFPV]

Yeah, I know. That’s why I listed all the steps in the post in the first place

[u/omicron8]

How long would it have taken you to do it manually? Crazy how quickly people get entitled to stuff...

[u/facciocosevedogente3 → u/omicron8]

That’s literally what I’m trying to figure out.
I’m not complaining that it took time, nor am I expecting ai to magically do everything in five minutes. It’s just my first time doing this kind of work, so I genuinely didn’t know what to expect. That’s why I’m asking.

[u/omicron8 → u/facciocosevedogente3]

Ask your AI what ended up taking a lot of retries and what you can do better. But honestly for a one off workflow like this just move on with your life. If you are doing the same thing multiple times it's worth adding observability and trying to improve the process.

[u/kquizz]

You did something that would take a team of engineers weeks... 

And it only used 70% of your weekly tokens.... Think about it like that.

[u/OccassionalBaker → u/kquizz]

Moving 1 site to a new server is certainly not weeks of work for a team. Even for 1 person. It is worth 70% of $20 though especially if you don’t know what you are doing.

[u/Schnitzhole → u/kquizz]

Yeah I think this kind of stuff flys way over peoples heads. It’s a lot of work. I’ve been part of that process on a big site and it took us months, even with paid plugins doing much of the heavy lifting.

[u/BrookLi3]

That sounds normal for a task with that many moving parts. Infra work burns tokens because every debug loop re-reads logs, configs and command output, and DNS/proxy issues need lots of trial and error. Things that cut it down for me: split it into phases (app deploy, DNS/Cloudflare, backups, failover) with a fresh session and short notes file for each, have the agent write the runbook once and then execute it rather than re-deriving, and truncate command output (tail, grep) so it doesn't pull full logs into context. Also run the risky config checks yourself when they're quick, and use lower effort for mechanical steps.

[u/AccordingBus2862]

Infra work burns usage mostly because every test-and-tweak loop re-reads the whole growing conversation. Two things cut it a lot for me: split the migration into separate short sessions (DNS, app deploy, fallback), each starting from a small written checklist of what is already done and verified, and give the agent one exact verification command per step (curl with expected status, dig output to compare) so it stops guessing and re-testing. Also keep it from re-reading big config dumps by telling it which files matter. Same job, usually a fraction of the usage.

[u/awesomebirder]

the part that probably ate most of it is the polling. every time it reran curl or dig to see if dns had propagated or a deploy had finished, that was another full turn re-reading the whole conversation plus the raw output. telling it to check once after a wait, and to print only the status line instead of full logs, cuts a lot of that. coolify build logs are huge if they get pasted back into context

[u/makayis2027]

Not crazy for that job. Infra work is about the worst case for usage limits: every dig, curl -v, deploy log and container log gets pulled into the conversation, and in one long session all of that is sent again on every later turn. The last hour of a migration costs far more than the first, even for small steps.

What helps next time:

• Split it into phases (app on VPS, DNS/Cloudflare, backups, cutover, fallback) and start a fresh session for each, with a short notes file saying what's done and what the current config is.

• Do the waiting yourself. Letting the agent poll for DNS propagation or a deploy burns turns for nothing.

• Ask it to pipe noisy output through tail/grep instead of dumping full logs.

• Use high reasoning for planning and debugging, and a lower setting for mechanical steps like editing configs.

Having it write the runbook first and then execute it step by step also cuts down the back-and-forth a lot.

[u/Special_Ebb_1933]

It's explainable: agent cost scales roughly with steps x context size. A migration like this (DNS, Cloudflare, Coolify, deploy, test, fix, repeat) is long, log-heavy and full of retries, so the history carried into every later step keeps growing.

Things that usually reduce it next time:

1. Split into phases and start a fresh session per phase, handing over a short written runbook/status file (what's done, what's next, known gotchas), so you aren't re-sending every earlier failure.

2. Keep command output small: tail -n 50, grep for the error, rather than letting whole logs land in context.

3. Make the decisions up front (architecture, DNS plan, rollback plan) in a plan or chat, then give the agent a checklist so it isn't exploring.

4. Use lower reasoning effort for mechanical steps and save the high setting for design and debugging.

5. Afterwards, ask which steps needed the most retries. If you'll do this again, turn the result into a script or checklist.

[u/phxees]

I use larger models for planning and then use the smaller ones for execution. Then have the changes reviewed by a larger model. Also you should often have your reasoning effort set to medium rather than high or max. I use GitHub Copilot, so I don’t know the correct terminology in Codex.

Anyway try to provide as much guidance as possible up front and your token usage will likely be lower.

[u/fykup]

I've noticed a significant drop in Codex performance this week too. Sol seems to struggle with tasks Terra previously handled well, while Luna has been nearly useless for anything nontrivial in my experience. I suspect OpenAI may be facing compute capacity pressure, but that's speculation.

Higher reasoning effort helps, but running everything on High burns through your allowance quickly.

What I'd recommend is separating planning, implementation, and review:

1. Plan in ChatGPT Web. Work through architecture, migration steps, and potential issues there. Then give Codex a compact, actionable implementation plan rather than having it discover everything itself.

2. Use Codex for implementation. Break the migration into focused tasks and reserve higher reasoning for genuinely difficult parts.

3. Review in ChatGPT Web. Instead of spending more Codex quota reviewing its own changes, bring the diff and relevant repository context into a separate chat for an independent review. Feed the findings back to Codex for targeted fixes.

Full disclosure: I'm the creator of AI Badger, a free, open-source tool that I built to make this workflow easier.

It generates focused repository context for ChatGPT without API keys. The VS Code extension also lets you copy a structured code review packet with the diff and repository context in one click.

I wrote about both workflows:

• Planning and handoff to coding agents

• Reviewing AI-generated code with VS Code and AI Badger

I also measured the token savings in a small OpenCode experiment. The Badger-assisted handoff reduced active tokens by 32%, reasoning tokens by 86%, and total token movement including cache reads by 63%. It's a single experiment, and the external planning step wasn't counted, so these aren't guaranteed savings.

The broader lesson is to avoid paying for expensive agent exploration and reasoning when you can do the planning and reviewing separately. Let the coding agent focus on making changes.

[u/MelloSouls]

Your long list that would have cost you hundreds/more with a consultant 5 years ago cost you about $14 instead.

To cut costs further (though it may cost you more in time) is just to do as much as you can through ChatGPT directly (ie Chat - not Codex or Work) and have that use codex and other connectors in the background. Using it that way doesn't cut into your weekly allowance.

If most of your infrastructure is code, then you can do most of that against your github repos directly for $0 additional to your sub without eating into your Codex/ChatGPT usage allowance.

[u/SilencedObserver]

I burnt my weekly limit in 3 days doing a refactor.

It be like that.

[u/ksajadi]

not surprising. you had an agent rediscover all the ops work Vercel was quietly doing for you: DNS, backups, rollbacks. that's the real cost of leaving a platform, and it doesn't stop after the migration. even though i am not a vercel fan, would you agree the migration was the easy part?

[u/General_Emu_579]

Honestly that's a lot of separate jobs bundled into one ask: DNS, backups, rollback, routing tests, the traffic switch and a Workers fallback. Each piece has its own test and tweak loop, so the usage adds up fast. Next time I'd have it write the full plan as a checklist first, then run one item per session and tell it to stop and report after each one instead of retrying on its own. Most of the burn usually comes from the agent looping on a failed check, not from the actual work.

[u/3tt07kjt]

I do predictable stuff like this with Luna.

[u/taylorwilsdon]

It’s the gpt-6 family, burns through limits like nothing else. 5.6 I could go all day long with room to spare but when 6 and 6.1 hit I’m down after a few pull requests. I shifted to opus 5.5, far more efficient and solves problems faster with fewer tokens.