131–140 of 144 posts
Chances are whatever was needed to make earlier models perform well now either is no longer helping much or actively hurts performance (worse results, slower, uses more tokens …).
Most agent harnesses that have not been designed from scratch for current models are over-engineered. Chances are whatever was needed to make earlier models perform well now either is no longer helping much or actively hurts performance (worse results, slower, uses more tokens …).
Example: for large Eloqua/Marketo/HubSpot emails we would previously make a planner which delegated the sections to their own call.
GPT5.6 can do the whole thing. The planner is unhelpful.
My suggestion: feature flag your complex implementations so you can rapidly contrast with and without it. (Or a formal eval suite if you have one).
If you prefer the simpler path, delete the old path.
Note: the challenge is making things compatible with these tools. Obviously generating html directly has been simple for ages.
(Source: mopsy.ai)
Earlier quoted context omitted.
> Fable 5 is sick. [It] solves almost any task from start to finish, the way it should be done — no errors, perfect code. It's a miracle. > As for GPT-5.6 Sol — it doesn't even come close. I honestly don't understand why people even try to compare them. What kind of problems are you working on? I like Fable but when planning work on a complex C codebase it's making more mistakes than 5.6 Sol xhigh for me. In what sce…
I have a large monorepo that includes about 15 TypeScript services and many Rust services. Everything is well-documented and organized, with standardized and structured custom code. When an issue arises, I often test the systems by providing a minimal prompt, like: "this user, this is their email, this isn't working, figure it out in production." I send this to both Opus and ChatGPT, but it doesn't help. I've set up…
> The fix that worked is a schema transform at the provider boundary. For OpenAI-family models only, we rewrite every optional property to be required but nullable, using anyOf: [T, null], which gives the model an explicit way to say “not using this.” I admit, I've only used a bastardized form of MCP, but this smells... wrong? It's not clear to me why the Typescript type definitions would have any influence on (what…
Although tbh the article makes a lot of this obvious and trivial change in syntax.
AI wrapper companies still exist?
Why would I not just use Codex directly?
The we wrote a bunch of prompts argument is kind of meh. That sort of thing has not only diminishing value with subsequent model releases but I actually believe will turn negative. The model will know better by default.
For example, initially giving the model some advice on code best practice was helpful. But now it's unhelpful because the model already knows best.
Earlier quoted context omitted.
They also migrated and that also made the workflow cheaper. It has everything to do with the article.
Reasonix, the harness, only works with DeepSeek. Neither are mentioned in the article at all, which was about a migration from Claude Opus to GPT 5.6. Maybe a bit of DeepSeek astroturfing going on?
Migrating my workflow to Reasonix with cache hits on Deepseek make requests practically free, and that's on unsubsidized American providers.
What's your config, how does it compare to pi
What does a site build cost, in real $$ with Opus vs Sol? Could you share a ballpark?
Earlier quoted context omitted.
I would expect they have production based datasets they evaluate new models against.
I would not expect that. They wouldnt have missed mentioning it if that was the case. Its mostly driven by vibes.
What do you think that is referring to?