Sorry. That shouldn't happen. It doesn't use a lot of memory and only uses WebGPU in the normal way. What version of macOS and Safari did you use, and what is your hardware, please?
even setting aside the artistic side of the profession, I see these things make all sorts of basic mistakes, so even the mechanical part doesn't seem "solved" ime
There are some users reporting it improved a lot in the last few weeks. The max sub usage for Grok is around $12,000 of API pricing now, so a 40x multiplier for the $300 plan.
It is the same multiplier for Sol with subscription. For Astra though the multiplier is ≈20x, so half of Sol usage.
For Claude it seems to be ≈40x too for Opus, but less for Fable (similar to Astra in GPT).
All on the most expensive plan. Previously, Grok usage escalated linearly from the $100 plan to $300 plan. That would be a really good $100 plan if it is still true.
Either this is untrue or my account is in some bugged state. I bought the 300 plan 3.5 weeks ago, and found it's usage about 1/10th of others, running out always the first day of usage for the whole week while CC for example would last 2-3 at higher usage.
It reset just a few hours ago and I've been running it, couldn't be more than 15 sessions none more than an hour long:
---
Session usage: no model calls yet in this session.
Weekly limit: 46%
Next reset: September 27, 23:20
---
I actually have to believe my account is messed up tbh, it's so bad. For reference I've ran 12 fable and some ~40 Opus sessions since reset yesterday on a CC account, at least 5x more usage by my estimate:
Current week (all models)
28% used
Resets Sep 28 at 5am (Pacific/Honolulu)
---
Ok looking at it more, Grok and Grok Build just really suck. They are about 10x less token efficient, often using 200+ tool calls in a row for what are not even big tasks where Opus would use 5-10. Their cache hit rate is worse, and two sessions got into basically unnecessary loops costing a solid quarter of the entire week. And this was on smaller tasks as I tend to use it for easier things.
I find I can just about get by with coding every day on a Cursor $60/mth sub with Grok fast mode disabled.
Doing pretty heavy coding work/requirements etc, but not much sub agents and no loops.
For me and what I’m doing that’s insanely good value.
I find grok build chews through my SuperGrok sub very quick - but I think that is due to it having the 500k context window which uses more credits. Cursor limits it to 256K (tho I see in today’s update for Grok 4.7 there’s now a toggle for context size).
Well when I ran out of Grok SuperHeavy subscription ($300) once and tried to use extra credits to cover half a day remaining till reset, $50 in extra credits went in two hours. Based on that, subscription definitely lasts longer; Grok subscription just about covers a week of my work (sometimes a bit extra remains unused, sometimes it runs out half a day to a day early). And as a point of comparison, it lasts for doing same tasks as 2.5-3 weekly limits of Codex on 5.6 Sol did (using xhigh on both Sol and Grok); I needed 3x$200 Codex subscriptions to cover my weekly usage.
There are two ways to subscribe, and it’s very confusing, but the best value is to get cursor ultra for $200 a month. I basically have infinite tokens with that plan, plus grok bot, which I really like
It used to be good, now the limits are very underwhelming.
Normal SuperGrok barely lasts me through the week with very mild usage and no coding. The sentiment around SuperGrok Plus is also not great and I haven’t seen someone saying they’re happy with it yet.
SuperGrok Heavy is $300/mo, so you could get a full ChatGPT Pro and Claude Max 5x for that price. That’s so far out of my budget for a single provider I haven’t bothered trying it.
I still have SuperGrok through X Premium+ but will downgrade that next billing cycle
Never heard of them. V looks neat in some ways, but there's still no 1.0, installation tells you to compile the compiler form source and it still uses and depends on a C compiler behind it. And defaults to GC. That's a ton of reasons why various people would drop it on sight. Also, inertia, of course.
Zig suffers from much of those, as does Nim. Rust OTOH appears well integrated and stable and I'm even seeing a lot of corporate use. I'd love to see V get to that level as well. But seems it's not even here in the present, let alone the future.
Such bafflement is often a medium-strength signal of the Bystander Effect. If someone wrote and submitted to HN your own blog post comparing the Zig/Rust examples from this article to ones from V, I’d read it in its entirety knowing nothing whatsoever about V. Perhaps it will be written by you!
The V pitch was a bunch of features that seemed implausible like automatic C++ translation and near-GC ergonomics with near-manual-memory behavior, without Rust-style explicit lifetime annotations or pervasive reference counting. so basically the pitch was the holy grail of systems, which caused drama as the project was met with extreme skepticism.
That was 7 years ago and since then the project has not delivered the grail, instead settling to be more of a mashup between go and C.
Bend is completely different it was just announced last week. It doesn’t have any users and has a weird ai integration so I done see how it’s relevant as a contender in the systems space at all.
Amazing work, one question regarding the guide, it states:
> That same file is the CPU program and the GPU kernel: clang builds it for the host, Metal or CUDA builds it for the device, so a `!` runs the exact same code on either chip.
What exactly is this saying? The guide doesn't really explicitly define `!`, and it's unclear from this sentence whether it's saying that, "clang builds it for the host and Metal, and CUDA builds it for the device", or if it's saying, "clang builds it for the host, Metal, and CUDA, and builds it for the device", or something else entirely.
It just means that Bend compiles to a single .c file, and that file compiles to either Metal or CUDA, via macros, depending on your target. This shouldn't be relevant to most users. It is just a way I found to keep the file small and reuse as much code as possible, rather than rewriting the runtime 3 times (once for C, once for Metal, once for CUDA).
> We need something like Emacs, but a well designed Emacs.
Wow. This is brilliant. Nobody ever. Not once. Not even theoretically. Nobody in 50 years of Emacs' existence ever tried that. Not a single programmer ever said this or attempted to do this. With exception of insignificant fools such as XEmacs, Zmacs, Hemlock, Climacs, Edwin, JEmacs, Yi, Lem, Guile Emacs, Remacs, emacs-ng, and the eleven thousand config frameworks that were going to fix it from the inside. I salute your effort, and may the spirit of your burned tokens please the digital gods and may they accept your sacrifice. Godspeed.
Buddy, I did. I did. And I can rant for a quite a while for why the opinions there have jack squat of sound reasoning. On [almost] every single point there.
What I love about Vim and Emacs is that they taught me humility. I am grateful to my younger self for forcing me to learn them, deeply. They cut my enormously inflated hubris down to size, and I believe they made me not only a better programmer but a better person. I won't tell you to try that path, because that would sound patronizing, and would undo this entire paragraph.
reply