pull down to refresh
oof indeed, yea not sure these compressed models are good for figuring things out... I try to think of them as executors
Worse thing about Chinese models is they distill the most annoying ones
My main beef with Grok though is its lazy and talks in shorthand riddles despite my best efforts at rules to make it not do that
It's what I like about Opus because in xhigh/max it actually follows instructions, whereas in formerly-normal-now-high it just ignores them (which is probably where the GLM trace input came from). Kimi feels good in instruction following too, at least for the little exposure I've had to it thus far. I'm hesitant to use it on real jobs though; I feed everything very long detailed prompts and costs hurt a bit.
I'm restoring my GPT-5.2+codex sandbox tonight.
I haven't dove into the Kimi hype since its more expensive than Grok or even Sol for me
Really hoping a Composer 3 drops based on it though, still got a couple automations running on 2.5 that was based on K2.6 iirc.
Yea and each passing day it seems less likely.
Before the deal closed the Cursor team was talking about training it, hype was building, and it seemed like it was going to drop any day... Under the LOI they were even using SpaceX infra to do the training... https://youtu.be/fWa7uxyhVDE?si=nvr295_nUZ3qu8jp&t=1389
(looking back at that Michael actually said from-scratch, so that nulls the K3 connection)
Then the deal closed and Grok 4.5 took the air out of it. 4.6 quickly fixed most of the 4.5 edges and speed that caused me to revert to C2.5 occassionally.
And now we're any day from G4.7
In the video they say 1.5T params, which is what G4.5/4.6 is
4.7 is supposed to be 2.1T
What Composer was GREAT at was being a daily driver that was fast and cheap so you could go to a bigger model only where necessary. They spoke to that being the way.
Grok is as cheap as Composer was effectively, making it my daily driver, but still not as fast as Composer. I'm guessing whatever they did to make it token efficient is what causes it to be lazy at times too.
4.7 being even bigger makes me think that won't be the daily driver they speak of compared to what Composer was.
So if 4.7 isn't a successor to 4.6 in terms daily-drivability, what's a true successor to 4.6? Is the next Composer something like a 4.7-Flash?
The suspense is killing me.
Also with everyone and their mother signing up for GrokBot makes me think again I dont have enough SPCX stonks before the next quarterly call. cc @BlokchainB
I don't know enough about Grok's architecture to understand how it could be sped up. We know that the Chinese models do all kinds of funky stuff to speed up, and I'd test qwen 3.8 to get a better feel for it, if I didn't get 499'd[1] on it every other query - hopefully someone will fix something some day.
I feel like there are a lot of things made in China lately that are usable conceptually, especially for the now-runner-ups like Xai and Meta. And maybe all you really need is a RL'd MoE version of Grok for coding - they did try that with grok-coder, but that was the old team. I'm sure that the expertise at Cursor, and their tracing captures, can help with this.
This is very disruptive in a coding agent environment because you don't know if you can retry it... whomever thought it was a good idea to ever respond w/ 499 - needs to do a serious year of penance in my to-be-developed isolation chambers because that's the dumbest brain fart I have ever encountered - it used to be an internal nginx thing - how on earth can I see it on my client if the error is that the client broke connection before the server could respond? it's not possible to get a status code without a connection. ↩
🚀🚀
lol fireship on ox just dropped
So, triggered by the flashy flash hype, I asked 5.3-flash to fix a bug that surfaced in CI, on some Rust code. It's... creative:
-async fn ensure_databases(couch: &CouchClient) { - for name in [core_db::RAW_EVENTS, core_db::NODES, core_db::CHECKPOINTS] { - couch.ensure_db(name).await.unwrap(); +/// Brings the shared databases back to a fresh install — deleted, recreated, +/// the stats design document back (§4.6) — under the test lock, so the reset +/// cannot race a case that is still running its explorer. +async fn reset_databases(couch: &CouchClient) { + for name in TEST_DATABASES { + // CouchDB's DELETE is not always settled by the time the answer + // arrives: recreating immediately can land on the database that is + // still going away, and the new case would inherit its documents. + // So the recreation is verified and retried until it is truly empty. + for attempt in 0..20 {oof. lol. I don't know how useful this is haha.
It worked on it for over 200 minutes, but the cheap part is true: only cost me $2.20. Last night I put Claude on another Rust task and it ate $65 past credit, stalled out because that was all the money for this month.