I’ve started coding with Grok (after months on Claude)

I’ve written about Claude on this blog more than once. It’s what I code with almost every day: agents that read the repo, propose changes, run tests and remember the six places you have to touch when you publish a podcast episode. In How I code in 2026 I described that stack as if it were the weather. Grok, SpaceXAI’s model (formerly xAI), sat on the sidelines. I even wrote a recap of what had been going on with Grok without really using it in my workflow.

This week I changed that. I didn’t throw Claude away. I started using Grok for real —mainly Grok Build, the terminal agent— and forced myself through a one-day project, not a hello-world. Here’s what I took away, without hype and without a hatchet.

Why now #

Three reasons, in order of honesty:

1. Technical curiosity. Grok 4.5 is sold for coding and agentic work. If Claude is my default, I want a decent plan B —the same logic that led me to move my fitness app’s AI onto Apple’s cloud: less dependence on a single vendor.
2. The product got serious. It’s no longer just the chatbot on X. There’s a CLI, a session, credits, an agent TUI. That looks more like how I work than a web chat.
3. I wanted a bounded experiment. Not “migrate all of Moodle to Grok”. Something small, finishable in a day, that forces a fight with auth, macOS signing and a real problem.

How I’m using it #

The flow is closer to Claude Code than I expected: open the agent in the project directory, give a natural-language instruction, and the model reads files, edits, runs commands and closes the loop. In my case that’s Grok Build on the Mac (desktop or the home mini, depending on the day).

What I use it for right now:

• New or one-day projects, where I’m not dragging years of mental context in another agent.
• macOS utilities / scripts, where the cost of being wrong is low.
• Exploring APIs and repos without burning a thread that already has Jitsi or the blog loaded.

What I still do with Claude (for now):

• Moodle plugins and mod_jitsi debt.
• Work where cross-session memory and my skills are already sharp.
• Day-to-day blog and mini-web work, which already has hooks and conventions the other agent “knows”.

It isn’t a divorce. It’s a dual stack.

What feels different (real use, not a leaderboard) #

Comparing models on benchmark tables is an Olympic sport. I care more about the feeling after a couple of hours of real work:

• Pace. Grok Build moves with intent: proposes, applies, compiles. On a small project that’s a plus. On a huge one I haven’t squeezed it the same way yet.
• Less of a “taken house”. Claude has months in my flow (skills, hooks, memory). With Grok I start from zero: more friction at first, less inertia.
• Credits. With Claude I have a spend habit. With Grok I don’t, and I hated not seeing the % without opening the TUI and running /usage. That led to the experiment below.
• Undocumented bits hurt the same everywhere. When you have to hunt a billing endpoint or an OIDC contract, the brand doesn’t matter: read binary strings, probe, and note that it works today.

I’m not going to say Grok is “better” or “worse” than Claude. I don’t know that at Moodle scale yet. I do know it’s usable enough to build something real in an afternoon.

The experiment: a menu bar with Grok’s usage % #

So I wouldn’t fly blind on spend, I built GrokUsageBar: a macOS menu bar app that shows the credit usage percentage for the period —the same idea as /usage (or /cost) inside Grok Build.

In the bar: the Grok logo and something like 0.7% (one decimal under 10%). On click: panel with used/limit, period, history sparkline, notifications at 80% and 100%, and open-at-login.

The interesting part isn’t SwiftUI —a MenuBarExtra in half a morning— but where the number comes from:

• Grok Build stores the session in ~/.grok/auth.json (OAuth).
• Usage is fetched with
  GET https://cli-chat-proxy.grok.com/v1/billing
  using that session token.
• The percentage is used / monthlyLimit. No invented dollar estimates.
• When the token expires, the app refreshes via OIDC and writes back to auth.json, like the CLI does.

Fine print: that endpoint isn’t a catalogue “public billing API”. It’s what the client uses today. It can change. The app is personal; Apple Development signing and a copy in /Applications is enough for me. Shipping it to someone else would mean Developer ID and notarization.

Code on GitHub: SergioComeron/GrokUsageBar. On my Mac: ./install.sh (signed Release → Applications).

What I haven’t changed (yet) #

• I haven’t rewritten the blog or the mini pipeline “because Grok”.
• I haven’t stopped opening Claude when the project context already lives there.
• I don’t have a sacred “+X% productivity” metric. I have hours of use and an artifact that didn’t exist yesterday.

That’s enough not to call this a “migration”. It’s opening a second seat at the table.

What I’m taking away #

Not long ago I wrote about Grok as news. This week I used it as a tool. The difference shows: you stop judging only from X threads and start judging from commits and real friction.

Claude is still the main course. Grok is on the menu. And I now have a reminder in the Mac menu bar that credits aren’t infinite —something worth remembering with any vendor.

If you try Grok Build and build something similar (or another silly utility that removes a daily friction), tell me. Small experiments are the best way to learn whether a new agent deserves a permanent seat in the stack… or just a week of curiosity.