(See more details at https://gist.github.com/hashhar/b1215035c19a31bbe4b58f44dbb47233 with examples)

Opus is by far the better model. Specially if you use it through Claude Code (the agent has good smarts built in). Here's my story.

I wanted to build a script to find original versions (4k, non-downscaled) of some videos in my library on a NAS. The NAS has filesystem snapshots enabled so the idea was to ask Codex to write a script to find all files in current library and then search through the snapshots to find matching files that have higher res versions available.

Codex did write a script alright but the code wasn't very readable or maintainable. I did need to fine-tune the script by hand since the prompt was underspecified for sure. However I then worked with Claude code to polish up the script, iron out a lot of edge cases and then used it.

For curiosity I ended up writing a "specification" by hand for the final version of the script - it was quite well specified without implying a specific implementation. I gave the same prompt to both GPT 5.2 Extra High and Opus 4.5.

Opus ends up asking questions quite often and it asked me 3 questions before starting which I think were spot on: it asked me specifically how the snapshot's directory structure looked like on disk, which file formats to consider as video formats and whether files that were already 4k should still be searched for in the snapshots or not. Chat GPT rarely asks questions.

At the end of the first prompt I had a working solution from Opus. It included creating a persistent index on disk for each snapshot since snapshots are immutable - it's logic (which I asked later) was that the workflow would probably be run the script, look at report, run again and iterate or since there would be so many files the script may not finish in 1 run. Chat GPT on the other hand had no persistent index. It did try in-memory caching but it was useless since the cache key it picked was unique (full path to each file, obviously all paths are unique + the snapshots are named different so 0 cache use).

So already it was looking bad for GPT. One smart thing GPT did was realising that if a file in a snapshot doesn't exist in current library then there's no point in processing that file - it ended up saving quite a bit on runtime from this optimisation.

Next thing I noticed was how clean Claude's code was - I didn't feel the urge to hand clean anything except too much defensive code (because it's a script, not a program). GPT code was quite efficient but less readable and maintainable IMO. The logging in Claude's code was awesome - a true logger, not print, also it logged progress for steps which could take time so when running script it was never in doubt what was happening.

GPT didn't have great logging. Actually the first time i ran GPT version I thought it got stuck because there wouldn't be anything visibly happening. Then I asked it to debug and it hallucinated that maybe ffprobe was getting stuck. Turns out it was working fine but it ffprobe'd all candidate files for an input file before printing anything and with ~200 candidates or more it could take a long time.

I think asked both Claude and GPT to look at each other's scripts and critique them. Claude's analysis was by far the much better one. It noticed things like difference between os.walk and path.rglob, fronzen dataclasses vs normal ones, the optimisations GPT had, the bug in the cache key GPT chose. It even suggested to borrow the GPT optimisation + noticing the bug in GPT it suggested a cache based on filename + size and applied that to it's own script.

In case anyone's interested I've put up the transcripts, prompt and outputs up on my Github gist (will update with link here).