bhu8

> Success of autoregressive next token prediction feels like a stroke of luck.

Hard disagree. Self-attention + MLP was a godsend because it keeps scaling with compute ("the curve goes up and up and up"). Autoregressive next-token prediction turned out to be the most compute efficient way to train it.

We are almost 10 years into this, and it's still here (and in a field that moves at light speed!).

This is not a stroke of luck. It's here to stay.

It’s probably more efficient caching methods and smaller models (6 sol is actually 6 terra and opus 5.5 is smaller than 5.1 etc). Don’t overthink this please

You could use a dumber model (luna or haiku) for compact to get around this

tl;dr: Google stands out with statistical significance; Alibaba (Qwen) is probably in second place, but data are not conclusive.

The applied mathematician’s joke is that log n is bounded above by 45 or so.

> I can't imagine OpenAI not backtracking this unless Anthropic does the price hike too.

Same here, but I’m worried it’s the latter. We’ll probably see an Anthropic price hike in a couple of weeks.

These are garbage but Opus 5.5 can actually do much better: https://x.com/emollick/status/2103272686570918334

For anything with CLI access and permissions CLI >>> MCP, not even close

Also this how most ADEs enable agent messaging and the like

I wouldn't be very bullish.

Homomorphic encryption got significantly efficient with the first few iterations, but I don't really see the necessary orders of magnitude savings coming soon. You could reduce this by some partial encryption schemes (e.g., for LLMs you need a handful of basic operations) but a better alternative already exists: multi-party computation.

Source: I did research in this area in the past.

Absolutely yes, but that's how you become twitter/X famous

May I plugin my own stuff? https://getviberia.com

Factorio/SimCity like interface for managing multiple agents: https://getviberia.com

It's like the love child of Polytopia and Conductor. As many other agent management platforms/harnesses, Viberia has been building itself, and honestly this has been too much fun to stop.

I like how the original triplet's initials represent their behavior well:

- Opus is OP, like OverPowered

- Sonnet is SO, like your significant other (this was more meaningful in Sonnet 3.7 days)

- Haiku is HA, like the reaction to a bad joke

The latest model, naturally, needed three letters: FAB.

I'm now looking forward to ABS and LO

Just use direnv? You’ll probably need to adjust the port you are hosting the local page on, but that’s just N=mod(hash based on the worktree name) and then port=default_port+N.

Tell your claude to set this up. Should do it in a single prompt

It would unfortunately impact it. ACP uses Claude SDK and is developed by a third-party.

Gpt-5.3-codex is miles better than 5.4 in that regard. It’s better at orchestration, and does the things that it said it did. Haven’t tested 5.5 yet but using 5.4 for exploration + brainstorming and handing over the findings to 5.3-codex works pretty well

Feels like an issue in their caching. First non-cached turns are sent properly but everything that is second+ turn fails.

I am working on a (yet another) local app for managing multiple claude/codex/gemini sessions in a game like environment: https://getviberia.com/

I think something is broken though. I got 20 nematodes in a row. It's around 1% prob.

Ah thanks, I see. This was 8-9 months ago.

I was starting from scratch and mainly relying on Opus/Sonnet 4.

I also kept running into the Godot 3 vs 4 issue before adding specific guidance about this into CLAUDE.md

Great work but why not use C# instead of GDScript?

LLMs are really good at C# (and tscn files for some reason), so that solves the "LLMs suck at GDScript" problem. Also, C# can be cheaper in terms of token usage (even accounting for not having to load the additional APIs): one agent writes the interfaces, another one fills in the details.

Saying this because I had really enjoyed vibecoding a Godot game in C# - and it was REALLY painful to vibecode with GDScript.

This is amazing. I checked some games and the blunders make me think that the LLMs are not really great at forecasting what happens if they play X on Y.

Can you actually introduce that into the decision making? That is, you would:

1. Have the LLM come up with N many potential actions

2. Run XMage run in parallel and provide the outcome for each different action

3. Revert XMage to the original state

4. Provide the LLM with the different outcomes and have them choose the action/outcome pair rather than just the action

This would actually help them analyze the counterfactual outcomes more effectively and should prevent 99% of the blunders

If you happen to be token rich, you could even do this in a MCTS manner and have them think really deep

Very nice! I am working on something very similar at www.viberia.net

My take was that it’s easier to trace who is doing what (and what the agent hierarchy looks like) when agents’ locations are fixed.

Noted. Thanks!

> Opting to introduce them sooner will almost certainly increase the complexity of your codebase prematurely

Agreed, but how else are you going to scale mostly AI written code? Relying mostly on AI agents gives you that organizational complexity.

> Given how long gpt codex 5 has been out, there’s no way you’ve followed these practices for a reasonable enough time to consider them definitive

Yeah, fair. Codex has been out for less than 2 weeks at this point. I was relying on gpt-5 in August and opus before that.

Not yet unfortunately, but I'm in the process of building one.

This was my journey: I vibe-coded an Electron app and ended up with a terrible monolithic architecture, and mostly badly written code. Then, I took the app's architecture docs and spent a lot of my time shouting "MAKE THIS ARCHITECTURE MORE ORTHOGONAL, SOLID, KISS, DRY" to gpt-5-pro, and ended up with a 1500+ liner monster doc.

I'm now turning this into a Tauri app and following the new architecture to a T. I would say that it is has a pretty clean structure with multiple microservices.

Now, new features are gated based on the architecture doc, so I'm always maintaining a single source of truth that serves as the main context for any new discussions/features. Also, each microservice has its own README file(s) which are updated with each code change.

IMHO, jumping from Level 2 to Level 5 is a matter of:

- Better structured codebases - we need hierarchical codebases with minimal depth, maximal orthogonality and reasonable width. Think microservices.

- Better documentation - most code documentations are not built to handle updates. We need a proper graph structure with few sources of truth that get propagated downstream. Again, some optimal sort of hierarchy is crucial here.

At this point, I really don't think that we necessarily need better agents.

Setup your codebase optimally, spin up 5-10 instances of gpt-5-codex-high for each issue/feature/refactor (pick the best according to some criteria) and your life will go smoothly