I use Codex with the $20 plan, plus some additional credits ready to kick in if I go over. I may switch to the $100 plan in the near future, but so far this setup has been enough for me.
To keep the cost down, keep it slow, both in the chat and in the settings. I use high reasoning mostly during brainstorming, and switch it to medium or low for regular development or small tweaks.
The most important thing, though, is having a good AGENTS.md. Whenever you see it doing the wrong thing, especially if you find yourself giving the same steering over and over, say something like:
Update AGENTS.md so this does not happen again.
Keep an eye on that file so it does not grow too large. Sometimes it will add too much detail, but overall this helps it converge very quickly toward the way you want it to work.
That said, I am not doing a lot of Anvil development at the moment. The day I restart doing more of it, this agents file will probably contain more details.
For now, I usually rely more on examples from my existing apps. I’ll say something like:
Do X, Y, and Z. I’ve done something similar in this other app. Please look at it to see how I did it, and use the same pattern.
I do the same thing when creating a new app. Instead of putting everything in AGENTS.md, I usually clone an existing app and then say something like:
This is an existing app I cloned only to use as an example. Please remove all forms, create a new form with X, one with Y, etc. Preserve user authentication, routing, style, look, and dependencies from the old app.
This is the generic part of my agents-anvil.md. It helps prevent Codex from creating too many fallbacks, validation checks, and hardening code, and it makes sure it understands that we are working with Anvil, not with a more common Python web framework:
- Follow Anvil best practices, not Django, Flask, or other frameworks.
- Avoid JavaScript when there is a Python alternative, for example use js.get_dom_node to access the DOM rather than custom JavaScript.
- When changing behavior, implement the new behavior as the only path unless backward compatibility is explicitly requested.
- When fixing reported wrong behavior, do not add hardening by default; ask first if extra hardening is desired.
- Do not add validation checks unless the prompt explicitly requests validation; allow invalid data to fail rather than adding guard clauses by default.
- When inspecting recent changes in an Anvil repo that uses anvil-cli, do not rely on plain git diff for working-tree inspection because syncing can rewrite the latest commit in real time; prefer comparisons such as git diff HEAD~1 HEAD.
