Consider that as of (always and) 2026 you are held accountable for whatever AI-slop* you produce. Will that change within 5 years? The mindset is shifting from doing the right thing, to instructing the AI to do the right thing. Even if you're not responsible for the instructing part (e.g. using AI export feature drafts, to use an AI software factory to refine and implement), you're still owning said implementation in the end because you're responsible for the refinement and review. You should know how to do the work and reason about it—but you're also responsible now for correcting AI—less work but more responsibility.
As someone building AI software factories for the greater part of a year, I can share some learnings:
- Smart models like Claude Opus cannot be replaced with dumber models at a reasonable expenditure with similar cost by iterating multiple times. Mythos will be the same cost or more expensive. Don't think you can throw enough funding at qwen-next-coder to rival Opus at a similar price.
- Mythos (like Opus) will change the way we work, but not in the way you think. The use case for Opus is narrowing in comparison to Sonnet - a lot of what Opus used to do, Sonnet can do for cheaper, and sometimes better too. Opus is great at exploring a problem space and filling in the gaps - but any agent harness will not leave such intelligence to fate—they'll do fine-tuning or add specific instructions and possibly guardrails. Lazy (but long-term optimal) solutions will leave more reasoning to smarter models and dictate less.
- A lot of what we do (and should do) is a cost optimization problem. Categorizing what we do (exploration vs. reasoning) tends to be structural (like Haiku), logical (like Sonnet instruct/non-thinking), and reasoning-driven (like Opus/thinking). Sometimes the challenge is long context-based reasoning, e.g. when planning a vision breakdown encompassing 50+ features, Sonnet could* do it given 1M context, but it struggles to reason about long context problems (Opus long-term reasoning drops off less) e.g. first 5 features are accurate, but the further you go, the less accurate it becomes (near-sighted vision).
- If Mythos has like a 10m context size long reasoning window, Mythos would become the go-to model for medium-term planning (3-6 months). Opus 1m doesn't cut it for 3m-6m horizon planning, not to mention long-term (1y+ with 100++ features). The industry is in need of a x10 compression/context size improvement to tackle bigger problems. One of the challenges right now is we (as humans) can't refine and reason about features fast enough to keep pace with what AI can deliver—until AI has the ability to perform longer-term reasoning, we can't trust it to plan things longer term. There's another problem with this long-term reasoning in that we (as humans) can't (easily) reason so far ahead, but AI could if it could keep the entire context in mind.
In short, unless Mythos is cheaper than Sonnet (which is 3-5x more expensive than what is out there today, e.g., GPT Mini, Minimax 2.7, GPT-OSS 120b), it's unlikely it would become the go-to model.
I'd add that a smarter reasoning model can only be better if you provide relevant context and reasoning constraints — otherwise, you can't expect it to behave better (in actual terms) compared to a slightly dumber model. When you start reasoning about the future in terms of AI, it's turtles all the way down (i.e. need AI to efficiently reason about the choices made by AI)
I've always been fond of Rethinkdb, but never actually used it. Perhaps if I came across pragmatic examples of how to do x with y, like you typically see with Redis, I could have convinced my team/s otherwise.
One of the aspects of Rethinkdb I admire most is the tooling. I find myself often trying out something new with React, Postgres, ASP.NET Core, Elm, Go, Kotlin or what not and biasing my experience getting started with preference to use.
I recond Rethink as Pied Piper in Silicon Valley; a great product ultimately being misunderstood. I'm relieved to hear Rethinkdb will live on under the Linux Foundation (and applaud them for doing so) and earnestly hope it re-establishes itself in a niche, such as that of Firebase/Parse, with partnerships and a legacy to rival that of Postgres one day.
Looks to be the case based on the config. I'm suprised storage wasn't abstracted to accommodate redis or the like which is essential in a load balanced scenario.
The API doesn't seem quite idiomatic either, I'd expect to create a struct containing options and a function that closes over the http.Handler interface e.g. func(l *Limiter) Limit(next http.Handler) http.Handler or a function that takes options and a next http.Handler that creates a struct implementing http.Handler.
Edit: The whole idea behind clustering is to run an application instance per thread/core for better performance and load balance requests between the application instances. This article seems absurd in its intention to force you to choose between multi-threaded synchronous application instances or a single application instance using callbacks.
We've been running a Koa.js API server using Cluster in production for over a year now with no hiccups (on a Windows machine).
I've been thinking about making the switch to iisnode, as it handles clustering, graceful shutdown and zero-downtime from within IIS (and does a couple of other things). It uses named pipes to proxy connections and also supports web sockets among other things.
With the nodeProcessCommandLine configuration setting, you can pass parameters to node (e.g. --harmony), use babel-node or io.js.
