Not Statistics, but Working Mileage

Recently I opened my Codex profile and paused for a moment: 2.9B lifetime tokens, 117.5M tokens on the peak day, 417 threads, 306 used skills, 49 explored skills, and the longest task ran for 4 hours and 11 minutes.

At first glance, these are just numbers in an interface. But to me they look more like working mileage. Not "played around with a neural network", not "generated a landing page for fun", but several real months spent inside AI development: websites, apps, prototypes, Swift projects, MVPs, internal tools, architecture, refactoring, deployment, errors, fixes, and then more errors.

A designer used to have Figma, a browser, and notes. Now my toolbox looks different: 306 skills, a project graph, a browser, deployment, refactoring, and AI that helps not only think, but build.

Is That a Lot or a Little?

For a regular ChatGPT user, this probably looks like a ridiculous amount. For someone who builds something through AI coding tools almost every day, it already feels like a normal work history.

In this mode, tokens stop being just "usage". They become a trace of thinking. A history of how many times you did not stop at "nice idea, I should build it someday", and instead actually went and started building.

What I Tested

During this time I seriously tried Codex, Claude Code, Cursor IDE with Composer 2.5, and the new Antigravity.

I was not choosing a tool as a religion. I am not interested in arguing about whose logo is better or which model is being discussed more loudly on X right now. I care about something else: that the project moves. That the code builds, the architecture does not fall apart, the app launches, and in the morning I can describe a task and a few hours later have not a conversation, but a working result.

Why Codex Became My Main Tool

In the end, my main setup became Codex + GPT-5.5 on High Effort. And when I first need to think through the architecture of a future project instead of writing code immediately, I go into Plan Mode on Extra High.

This is where Codex turned out to be the most practical. Not always the most magical. Not always the prettiest in the first answer. But the most convenient for real work. It handles a long process well, lets me move in iterations, and does not constantly make me feel like the oxygen is about to run out.

Skills, Plugins, and a New Operating System for Projects

The most interesting thing about Codex for me is not only the tokens, but these 306 used skills and 49 explored skills. At some point, AI stops being just a prompt window and becomes a working system: skills, plugins, project memory, planning, code, browser, deployment, project graph, refactoring.

A designer used to have Figma, a browser, and notes. Now the toolbox looks different: AI can read the project, build a map of relationships, check the result in the browser, help with deployment, and clean up the architecture. This is no longer just a chat. It is almost an operating system for assembling ideas.

Claude Code: a Strong Architect, but Expensive in Tokens

I also respect Claude Code a lot. Especially with Opus 4.8, when I need a first architectural pass, a view from above, weak points found, and the system broken down into sane modules.

But the problem is that Claude Code burns through tokens very quickly. Even with project memory, even in the most careful mode, even with the graphify skill, when a project graph is built and everything should supposedly become easier to manage.

So right now Claude Code is not my main builder. It is more like an expensive architect-consultant. I call it in, get a strong first view, take the plan, and then go build somewhere else.

Cursor + Composer 2.5: a Workshop for Finishing Things Properly

Cursor + Composer 2.5 turned out to be very good as a working shop. It does not have that annoying five-hour window, tokens are consumed slowly, and the quality on finishing and refactoring is genuinely strong.

It picks up a project well after Claude Code or Codex: cleaning up loose ends, putting code in order, carefully refactoring without staging a revolution where a normal cleanup is enough.

And this is a very important mode, because almost any AI tool can generate an MVP now. But bringing it to a state where you are not embarrassed to open it, show it, and keep developing it is a different task.

Antigravity and Swift Projects

Antigravity surprised me separately. I am not ready to make a final judgment about it yet, but on the Swift project for my personal app Nevsky OS, it performed very well.

Especially when I was finishing a desktop app for transcribing English speech and giving script prompts in real time. There Antigravity did not just "write a piece of code". It actually helped move the app forward. So it definitely deserves separate time and proper testing, especially on Swift, macOS, and iOS projects.

What This Changes for Me

I spent many years as a product designer. I am used to thinking in interfaces, scenarios, logic, and system behavior. But before, there was always a wall between design and a real product: timelines, developers, budgets, backlog, someone else's speed.

Now that wall has become much lower. I can build a landing page, an MVP, an internal tool, a Swift app, or a working prototype myself. And that changes your head a lot: you no longer think "someday I will build this". You think "what if I build it tonight?"

The most interesting thing in AI development is not the moment when it writes code. It is the moment when it starts holding the whole project as a system: context, architecture, errors, UI, API, and the next step.

My Conclusion

Today my stack looks like this:

  • Codex + GPT-5.5 High Effort is my main tool for work and project development.
  • Codex Plan Mode / Extra High Effort is for architecture and difficult decisions in planning mode.
  • Claude Code + Opus 4.8 is for a focused first architectural pass, especially for reactive sites with admin panels and user accounts.
  • Cursor + Composer 2.5 is for finishing, refactoring, and cleanup after Claude Code or Codex.
  • Antigravity is a promising tool, especially for Swift, macOS, and iOS. I still want to test it properly, because it produced strong enough results, the projects built without problems in Xcode, and I could test them on real devices.

But if you remove the names, the conclusion is simple: the winner is not the person who found "the smartest tool". The winner is the one who can think quickly, build quickly, check quickly, and avoid getting stuck in endless choosing. For my head and my rhythm right now, the most practical tool is Codex.