Fable is better than Opus and I do not think there is much argument there. And yes, it is natural to get used to a new tool and even end up liking it more over time. What I am trying to say is that it does not feel like the step change they are claiming it to be.
I fully agree with your point about Taleb. And yes, it can come across as a bit glib, but the underlying point is not new. Do not judge a book by its cover. That idea exists across many cultures, fables, and stories, so it holds IMHO.
The surgeon example is just an illustration of that idea, and it is a great example because it makes the point memorable. In practice, of course, I agree that most modern surgeons are trained to broadly similar standards and look and act the same, with some outliers and historical exceptions.
When I said "running it yourself" I didn't mean me personally running it at home. That will be unfeasible. A company can afford it though and also a supplier that serves multiple customers can do that as well. In fact, I was talking to a company that does this and the model is fully in UK where we need them to be.
At the end of the day it is about the sense of optionality. We know that this is the business model for almost all open source projects. It is not like you cannot download and run the project yourself and some do for practical reasons, but often times the cloud version is priced such that it is the path of least resistance so people go for that.
I couldn't find a situation where Fable was significantly outperforming Opus enough to make me say wow.
I tried to make it fix a browser game that is sort of like a Mario clone. It couldn't. It fumbled in the same places Opus was struggling too. I tried it with other code as well, but I couldn't get any significant performance improvement out of it, except perhaps in improving my account's token burn.
If anything, in my opinion, GLM 5.2 had a better moment than Fable recently. Not because it is better, but because it was not hyped at all, and many people realised that it is possible to run a serious open-weight model yourself, as long as you can get the hardware to support it.
I am not drawing a direct comparison here, because Fable is clearly the better LLM. But GLM 5.2 is a good, honest model, and I think open-weight models will only get better going forward.
GPT 5.6 is claimed to be at a similar level, or even better than Fable. We will see. They don't seem to hype it as much, and I have not read anywhere that anyone found a soul or consciousness inside it. And if it benchmarks well, I would possibly use it more for this very reason.
It reminds me of that story from Nassim Taleb's Incerto series where if you have two surgeons at practically the same level, but one looks like the typical surgeon and the other looks like a butcher, who are you going to choose? Taleb suggests that the answer should probably be the butcher, because to get to the same level while looking the part so much less, they probably had to be much better than the data shows for.
I cannot also understand the hype online claiming that the Fable transitioning to token-based billing after the gratis period is equivalent of being in the permanent underclass. The only impressive demo that I saw was it writing NES games which kind of looked fun but I couldn't find more details and I am not sure if you can get this done with another model - probably you can but nobody is trying.
So great model but it does not have the same effect as Opus 4.5 and Codex which made me feel that there was a stepping-stone change.
IMHO, cheaper inference means higher costs overall :) because everyone will use more thus driving up the investment required to stay current or to compete.
Switching models is also kind of easy but not plug-and-play. Most harnesses out there do very poor job with the open weight models. Unlike Opus, GLM 5.2 ends up in loops and hallucinates a lot more. If your harness is built on the expectation that the LLM will perform well, then switching to GLM 5.2 will be an uphill struggle. We had to refactor our harness and introduce more defences because of GLM.
The cost savings are substantial. Obviously it really depends on your workloads but it is noticeable cheaper for agentic work. Coding - I don't know. We do have some coding agents on GLM 5.2 and what I noticed with some landing page experiments that the results between GLM and Opus are identical - they might be using the same training data? Obviously Opus is still substantially better model. I don't think there is an argument to be made here but GLM 5.2 is cost effective and really good too.
Overall, we switched all of our internal agents to GLM 5.2 and because it is Open Weight we are in talks to get the model from certain geo locations giving us more freedom as well as extra protection.
Overall I think this industry will be in much better place because of GLM 5.2 and whatever open-weight models come next.
Even if the current generation of frontier models becomes 10x cheaper, companies will still end up spending much more per employee than they do today.
Lower prices will not reduce AI spend. They will simply increase usage.
There is no real ceiling on how much companies can delegate to AI. The only limit is the floor where spend too little, and you simply stop being competitive.
Agents already run unsupervised, and they can code unsupervised too. The real question is what worthwhile work we should point these capabilities at. Nobody has really cracked that yet.
Yes. I built recently an agent that has very broad set of objectives and nothing in particular. I don't even know what it does most of the time but hopefully it will do something useful eventually.
Saving time does not automatically translate into higher productivity, or even lower costs. That should be obvious?
In fact, I would argue the that with AI, companies should expect to spend more on average, without necessarily seeing any meaningful cost savings nor increase in profits.
That does not mean they can escape this though. It is just like paying for ads, backlinks etc.
Cool. The main thing I like about MCP is the authentication story, particularly the standardisation around OAuth.
Because of that, I think it is often worth wrapping an API in an MCP server. I actually had to do this recently.
I have been working on an open-source project called crmkit.ai. I was not planning to add MCP support because the project already works in a very agent-native way, where the agent reads the `setup.md` file at the root of the server and then uses `curl`.
That works well for normal agents. It kind of works in claude.ai, although you need to allowlist the domain. It does not work on chatgpt.com because the sandbox does not allow arbitrary outbound web requests. It should work fine in Codex, Claude Code, etc. because those run locally.
For ChatGPT, I was forced to write an MCP server. But because this is supposed to be an agent-first CRM, I thought that instead of exposing hundreds of small tools and polluting the context, why not expose a single tool called `request`, where the LLM writes the actual HTTP request?
That should work, right?
It does not. ChatGPT effectively forces you to unwrap the entire API into lots of small tools, because each one may need to be authorised separately.
Anyway, I ended up doing it, but needless to say, the design feels wrong. It would have been much better if the MCP server could expose a single `request` tool and keep the context tight.
The single-tool concept does work. We use crmkit internally with fully autonomous agents, and I even use it personally as a productivity tool.
The moral of the story is that MCP has great authentication but I rather not use it if I can. If I need to use it I would prefer to expose a single tool that write the raw request even-though it feels like a hack and it does not work across all chat systems.
I am not surprised it is not open source. These harnesses are hard to build - they are not just wrappers - and often they contain business logic that is not suitable for public distribution for all kinds of reasons.
I might be in the minority here, but although x402 sounds useful, it seems to me that adoption will be an uphill struggle, especially for per-request micropayments.
The most likely scenario is Stripe, or someone similar, creating an agentic API connected to the agent owner linked account or something along those lines. I am not sure how this would work with 3DS, or whether it would be acceptable at all, since these kinds of transactions could be disputed easily ("I did not make the purchase, my rogue agent did.")
Another way to handle payments on the internet is obviously not to reinvent the wheel and simply email a payment link to the owner. That seems simple enough to me and does not require additional infrastructure. Payment processed, mint a key, the agent is allowed to proceed.
It is just a small agent using a remote harness, so the local dependencies are limited. It is specialised in the sense that the prompt, tools, and skills are all custom and baked into the binary, including the key to the harness API. I don't consider it sensitive in this context because the key is scoped.
The agent has a single mission to maintain the system it is dropped into. It has its own in-process heartbeat and is launched as a service.
As I said above, it is kind of amusing to think that it exists at all. It checks whether things are running fine and can possibly correct them if it finds something wrong.
I can see this becoming a more serious kind of system agent.
I try not to advertise in this forum but I can drop a link if interested.
I wrote a small agent (single go binary) that does all the monitoring and maintenance for me. Possibly overkill but it is amusing to think there is a little ghost in the machine.
https://cbk.ai
https://chatbotkit.com
https://github.com/pdparchitect