A Tale of Two Commit Messages

A developer who switched from Anthropic's Claude Code to OpenAI's Codex (Terra/Sol/Astra) reported that Codex's Astra model generated a one-line git commit message — "Fix YouTube resolver playback and isolate proxy traffic" — for a change that added a YouTube resolver, scoped a Bright Data proxy, changed the playback path, added a fallback download and ffmpeg merge flow, and updated cron behavior, dependencies, and docs, while Claude produced a multi-paragraph message explaining a background-job ingest fix. The developer, Par Trivedi, said the terse Codex output contrasted with Claude's detailed style and described the switch as "a nice breath of fresh air.

Ok so I recently switched from Claude Code to OpenAI Codex Terra/Sol/Astra . First of all, I was surprised at how fast Astra Medium blew through my usage doing some pretty rote stuff. Learned my lesson and am using Terra more regularly now. Now I'm ok to admit I'm one of those people that has the AI do my git commit and pushes for me, and let it draft the messages and all. Today I had Astra 'commit and push' for me, and for shits and giggles I looked at the git log, expecting to see some kind of novella-esque message like what Claude would generate. But I was really surprised: commit 2a4f143949a8214b90da4850d6b5daa2ff211efb Author: Par Trivedi <par. @gmail.com Date: Thu Sep 10 21:30:49 2026 -0400 Fix YouTube resolver playback and isolate proxy traffic Now this was a pretty beefy task we did here, the change itself adds a new YouTube resolver, scopes a Bright Data proxy so it does not accidentally route unrelated requests through it, changes the playback path, adds a fallback download and ffmpeg merge flow, validates the output video, updates cron behavior, dependencies, and docs. Now look at a pretty standard commit message that Claude generated: commit d5767c4dd42426a9c8857f50d67dae741a7f8c1b Author: Par Trivedi <par. @gmail.com Date: Sat Aug 15 10:38:00 2026 -0400 Run admin video ingest as a background job instead of in-request The ingest scrape/download + two ffmpeg passes + two S3 uploads runs for minutes, past nginx's 60s uwsgi read timeout, so the admin page 504'd. The work was actually completing — there's no harakiri set, so the worker kept going after nginx hung up — but the result was unreachable. POST now enqueues a VideoIngestJob and returns immediately via POST-redirect-GET, spawning a detached process video ingest jobs --job-id N . The page polls ingest-video-status for live stages downloading - transcoding - thumbnail - s3 - refreshing cache - done and renders the same preview on completion. Closing the tab no longer matters. Job claiming is a conditional UPDATE pending - running , so the spawned worker and the cron safety net can't double-process. Cron runs every 5 min to pick up jobs whose spawn failed and to requeue ones orphaned by a restart mid-run. Also fixes the Instagram download itself: download direct sent no User-Agent, so scontent- .cdninstagram.com rejected it. The resolver path never hit this because it hands the CDN URL to the app rather than fetching the bytes server-side. The failure was also swallowed into a print, surfacing only as "download failed". Co-Authored-By: Claude Opus 5 1M context <noreply@anthropic.com In the words of gen z: "dead ass". Both commits are relatively similar in scope: It really gives you a sense of the 'personality' behind the creators of these two models, and I gotta say, I did switch from Claude because I felt like it was getting too stuffy lately, and I think switching over has been a nice breath of fresh air. But I'll be honest, I didn't expect to see this