I used to rely solely on Cursor for my work, but lately I find myself trusting Claude Code more for complex tasks. Because of this, paying for the Ultra plan feels less worthwhile than before.
i just blew a third of my API budget in an Ultra account using Fable 5.1 in 2 hours … kind of wondering if I should open an Anthropic account, especially if OpenAI is going to Axe Cursor, I’ll be trending towards Fable / Opus usage without GPT around for reviewing code and plans. Grok is just not cutting it either.
Sam Altman is a jerk.
Even if not with Fable, I find that planning and reviewing before modifying a project works better with Opus than with Grok, and sometimes GPT‑5.6 Sol is even more reliable. I definitely agree that the API budget disappears too quickly. It would be great if some measures could be taken on this, or if Grok and Composer could become more capable.
As a developer, I am writing this with genuine love for Cursor.
API pricing is hard to swallow if you’re building personally and don’t have a company budget to backstop you. I run with omnigent and have CC and Codex subscriptions, which makes it easy to work between the models as needed. Then the problem is making sure tooling is shared, but I built some stuff to make that easier to understand.
You are truly admirable. Still, having tools like this makes things so much better than before. I hope that, after reading this, Cursor will evolve into a more economical yet powerful tool.
I’m on an Ultra plan and have a SuperGrok Heavy sub.
I find Grok meets most of my needs. About 90% of my usage was Grok/Composer. Only 10% was Fable 5.1.
Last month I used 515,690,892 claude-fable-5-1-thinking-high tokens.
I also used cursor-grok-4.6-high: 748,568,844 tokens, and composer-2.5: 205,851,662 tokens. Those hardly put a dent in my limit.
On SuperGrok Heavy, I did 3,615,450,281 tokens, which is maybe 50% of my limit. I never hit my weekly.
I don’t understand how people can’t use Grok and Composer for what they do.
I’m working on 28 year old software that was orginally a commercial BeOS product. Basically it emulates a PPC processor and runs Mac OS up to 9.0.4. It’s mostly written in C++, C, and Objective-C.
I have added support for Mac OS 9.1.2 and OS X 10.3 by creating a NewWorld device tree (MacRISC2, memory, CPU, chosen, PCI, video, ADB, PMU, NVRAM), a PPC32 MMU. With the Guest Toolbox, 68k emulator, Window Manager, HFS, Disk First Aid, all running as guest code. Also added an ARM64 JIT that walks the PPC32 MMU. The JIT was x86_64 only and was missing from ARM64. It greatly improves performance on M Series Macs.
I did 90% of that with Grok/Composer.
Before it could even begin t had to create disassemblers for the ROM and the files on the ISO and Disk Image in Swift. It wrote an HFS driver for mounting classic filesystems on modern Macs (Apple removed the driver from the kernel). It has dumped devices from QEMU for reference. Wrote tests and automation scripts to verify no regressions in the GUI, mouse, and video driver. Takes screenshots and measures performance improvements. It has dozens of rules it must follow before moving on to the next task.
Right now, it is finding calls that aren’t making it to the JIT and are being emulated by C. It created a histogram, and it is working on the top hits. Millions of C calls are being removed, greatly increasing performance.
If Grok/Composer can do that, I’m sure it can make Web apps.
I’m still on a yearly Pro plan and have made decent progress with a grok / opus mix with the exception of regular disconnect loops and remote freezing. However, after burning up the extra models API in 2 days and an extra $25 on demand in just 1 hour it seemed sensible to try claude code. Opus always produces better work and is useful for calling out mistakes made by grok. I’ve now signed up to a CC $20 pro plan CLI and so far have completed 2 full days of work and still within the weekly limit - a far better tradeoff than paying extra for on demand usage. CC CLI has many advantages as it’s engineered to optimize token usage and stores your code in memory whereas cursor typically dumps huge multi-million tokens in one turn thus maxing out in minutes. Cursor desperately requires efficiency improvements. It’s still decent and useful but I’ll avoid renewing unless this changes.
I feel the same way. Please keep pushing forward, Cursor.
I’ll put in my two cents here:
If you’re using Fable to build web apps, then you are probably doing something wrong. I am guilty of this because the idea that I can just toggle on Fable or Sol and let it go to work is attractive. However, these models are better suited to orchestration: write structured build plans that Grok 4.6 can easily follow and do the “grunt work” of writing the code.
The frontier models are intentionally not cost-effective. But you wouldn’t buy a Ferrari to commute to work when a Toyota would do just fine. (And Grok is more comparable to a Tesla ;))
I agree. A higher‑tier model doesn’t necessarily produce better code.
As you know, coding often involves repetitive or similar tasks. In the past we used copy & paste, but now auto mode or Composer alone is often enough.
After such work, it’s often better to let Opus or Codex handle the verification.