Woah, metr results look impressive. Still looking exponential
Building more with GPT-5.1-Codex-Max
71–80 of 332 posts
Re: Building more with GPT-5.1-Codex-Max
#72The new detergent now washes even whiter
I love how programming discussions du jour have basically devolved into "really? my socks definitely smell better after using 2 scoops of last month's soap. what spin cycle are you using?"
Re: Building more with GPT-5.1-Codex-Max
#73I rarely used Codex compared to Claude because it was extremely slow in GitHub copilot . Like maybe 2-5X slower than Claude Sonnet. I really wish they just made their models faster than “better”
Very interesting to see the range of peoples' preferences. I would almost always prefer smart over fast; I have all my LLMs to be all-thinking-all-the-time.
It’s a balance, I haven’t felt like codex provided anything that Sonnet 4.5 didn’t. Why wait longer for getting the same results.
Though that does bring up an interesting point. Anecdotally, Sonnet does a lot more grep-ing while Codex reads files straight up. Might be the difference in speed and maybe smarter models will do better. Once this model is on copilot, I can test it out.
Re: Building more with GPT-5.1-Codex-Max
#74OpenAI likes to time their announcements alongside major competitor announcements to suck up some of the hype. (See for instance the announcement of GPT-4o a single day before Google's IO conference) They were probably sitting on this for a while. That makes me think this is a fairly incremental update for Codex.
That’s how the game is played. We should be grateful for all the competition that is driving these improvements, not whinging about the realities of what companies have to do to contest each other’s position.
Re: Building more with GPT-5.1-Codex-Max
#75OpenAI likes to time their announcements alongside major competitor announcements to suck up some of the hype. (See for instance the announcement of GPT-4o a single day before Google's IO conference) They were probably sitting on this for a while. That makes me think this is a fairly incremental update for Codex.
it's really getting old
Re: Building more with GPT-5.1-Codex-Max
#76OpenAI likes to time their announcements alongside major competitor announcements to suck up some of the hype. (See for instance the announcement of GPT-4o a single day before Google's IO conference) They were probably sitting on this for a while. That makes me think this is a fairly incremental update for Codex.
Gemini is eating their lunch, and OpenAI knows it.
Re: Building more with GPT-5.1-Codex-Max
#77I would love to see all the big players put 1% of the effort they put into model training into making the basic process of paying and signing in suck less. Claude: they barely have a signin system at all. Multiple account support doesn’t exist. The minimum seat count for business is nonsense. The data retention policies are weak. OpenAI: Make ZDR a thing you can use or buy without talking to sales, already. And for t…
Last night, just after Gemini 3 was released and became available for Gemini-CLI, I saw Gemini-CLI's team post that you could access Gemini 3 with either an API key OR with _Gemini AI Ultra_, so I thought: great, I'll get that!
Now you CAN NOT get the Google One stuff if your account is part of a workspace. I thought: how awful. I want to pay, but I simply can't?
Oh, but then I noticed: You CAN add a _Gemini AI Ultra_ license via the Google Workspace Admin area, great!
Turns out: you fucking can't. That's _Google AI Ultra FOR BUSINESS_ and that IS NOT supported.
So I had to get the Google One subscription on my personal account after all.
Combine that with the _pathetic_ usage limits: somehow not token-based, but amount of requests per 24 hour window (which is 500 for Gemini 3) and Gemini 3's incredible chattiness (it uses A LOT more requests to get something done compared to Claude) and you hit the usage limits in just 2 hours.
Re: Building more with GPT-5.1-Codex-Max
#78Rest assured that we are better at training models than naming them ;D - New benchmark SOTAs with 77.9% on SWE-Bench-Verified, 79.9% on SWE-Lancer, and 58.1% on TerminalBench 2.0 - Natively trained to work across many hours across multiple context windows via compaction - 30% more token-efficient at the same reasoning level across many tasks Let us know what you think!
Sorry don’t like the max model, feels like it needs a lot more guiding. The plans it writes however are better, so I tried feeding it back in (meta prompt style) and working okay so far. Very large repository.
Re: Building more with GPT-5.1-Codex-Max
#79I would love to see all the big players put 1% of the effort they put into model training into making the basic process of paying and signing in suck less. Claude: they barely have a signin system at all. Multiple account support doesn’t exist. The minimum seat count for business is nonsense. The data retention policies are weak. OpenAI: Make ZDR a thing you can use or buy without talking to sales, already. And for t…
Adding to this, Google's models can only be used with GCP while OpenAI's models can be used with Azure, Anthropic's models can be used with AWD Bedrock, in addition to their own platforms. I'd love to see the Gemini models being available by other providers :) or if they just build a simple prepaid wallet like OpenAI and Anthropic.
Didn't realize these stipulations for the models. Looking at devops-y job descriptions the last few months I noticed nearly everyone has some kind of Azure requirement now (which I've mostly avoided because I don't want to end up managing someone's AD), but is openai the actual reason for it?
Re: Building more with GPT-5.1-Codex-Max
#80Earlier quoted context omitted.
> due to context-window limits
context window is not some physical barrier but rather the attention just getting saturated. what did i get wrong here?
In theory, auto-regressive models should not have limit on context. It should generate the next token with all previous tokens.
In practice, when training a model, people select a context window so that during inference, you know how much GPU memory to allocate for a prompt and reject the prompt if it exceeds the memory limit.
Of course there's also degrading performance as context gets longer, but I suspect memory limit is the primary factor of why we have context window limits.