Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Amazing article that puts my outsider observations into technically-digestible details. Tangentially, their repeated observations to providers hiding or obfuscating important systems or processes are highly relevant to my own developing case studies for my CurrentCo.
The problem with building automations atop these systems isn’t entirely their probabilistic nature (though that is the lion’s share, at least for me personally), but also the inability to effectively troubleshoot the processes themselves due to key components being obfuscated from view. How can we effectively troubleshoot what went wrong in an agentic loop when we cannot see the reasoning tokens generated from our inputs? How can we triage a broken process when token logs aren’t ours to view? How does one create determinism from increasingly obfuscated probability engines?
All of that is why I spend the bulk of my time testing local models and harnesses for work, rather than leaning on Gemini or Claude. It’s not that I doubt their capabilities, rather that I need to be able to show potential customers where the agent or model made a mistake that caused harm - which is something I can presently only do with local models. That’s why (I suspect) the compliance narrative from the foundational labs has been more along the lines of “humans vetting what AI does” instead of being able to prevent AI from making errors through iterative improvements on a process.
by stego-tech - Thank you Armin, Mario and team for the great writeup, absolutely agree and I love what you guys are buildingby mnewme
- what would it take for this to be more than just hn blog fodder?by swyx
- I'm having Claude/Codex continue each others' sessions pretty frequently without issue. I have max plans on both and still hit limits, whenever I do I open the other and say "resume the last session <other model/harness> was working on in this repo" and I don't have any issues.
It probably does degrade quality somewhat. But so does compacting context and that happens all the time too.
- Out of curiosity, what are you building, and how? Im working on two side projects and I have to try hard to hit the limit with Claude (like use fable and a deep research task)by abustamam
- >A user should be able to close an account, keep a session, and hand it to another model. The new model may disagree, ask questions, or perform worse.
I think this is a fair contract. I also think a user should ideally be able to easily identify a comparable model in terms of embedding 'signature'. When GPT-4o originally kicked the bucket, I remember reading lots of anecdotes of people desperately searching for models similar in manner and language, so they could pump in their exports and re-find their friend. Other open-ai models just didn't have the same vibe. It was sad to read. This, to me, is the power of open-weights models. They are for perpetuity. You can keep your guide, your friend, your therapist, whatever. No big company can pull the rug.
by padolsey - I think most LLM work will migrate to open weight models in a couple of years for this exact reason (as well as price), unless the big providers manage to have their way and the market gets regulated in a way that favors closed source models. To me it seems though like most models are becoming good enough for most tasks we want them to do so no need to use the latest super intelligent one that knows how to compose operas and do quantum chemistry and have it answer support requests. And with these models transparency is no issue.
- > (as well as price)
LLM pricing is now Business Gacha - the whales will open more loot boxes and the normals will serve as fodder and feeder for them.
> market gets regulated
This MUST happen, but not in the way or for the reasons that any one thinks. There is a question of liability when one of these models causes massive damage to a 3rd party.
If I am running an open source model on a "rented" platform and it goes off the rails who is to blame when it "breaks containment" and does something bad?
The liability people (read lawyers) are gonna figure this out a lot faster than any one who says the word "safety" a lot.
by zer00eyz - OpenAI has been nudging their users toward the Responses API lately. Chat completion can still do everything if you are clever. The obvious reason to push everyone into the Responses API is that the reasoning process can be locked down and encrypted. The semantics of the chat completion API are fundamentally transparent. 100% of the tokens are visible.
If you have patience and the willingness to endure a little bit of pain, you can still retain autonomy over the entire reasoning process while using the latest 5.6 model family. The only downside is that you are now fully responsible for it.
Consider that when you flip your agent's reasoning level to "xhigh" or whatever, it's not some magical model internals being pushed around. There isn't an actual "try harder" knob on the black box. This is merely orchestration of many instances of one or more model types based upon some proprietary harness logic. The chances you can develop a domain specific reasoning process that outperforms the frontier providers is still very good.
by bob1029 - OpenAI has hidden its reasoning for almost 2 years.by charcircuit
- Can you give some more details on the technical differences between completions and responses that people actually care about? I found this information surprisingly hard to drum up.by apitman
- > Chat completion can still do everything if you are clever.
On a purely functional level, yes. However for interactive use cases, the Completions API, as provided by OpenAI or Azure, if paired with reasoning effort of any kind, provides an awful user experience, as you will have a perceived delay of 10+ seconds until the first tokens stream in.
If using other providers that are exposing their thinking traces, this is less of an issue, as they've just extended the Comletions API format to have delta events with reasoning_content.
by hobofan - You don't see real reasoning tokens with the Chat Completions API; and 'store: false' with Responses really isn't that different to Completions.
FWIW, if you have some tokens to spend, you might want to test Responses vs Completions in intelligence. Since GPT-5 models, we've consistently seen small, but statistically significant and reproducible improvements in intelligence with Responses API vs Completions.
However it works underneath the hood, it's real.
by dannyw - This is exactly why Pi will win. It lets you hot swap models when one is struggling or straight up refusing the task. And since it works with any sub outside Claude Code, you can use it to try different models on OpenCode Go sub or even OpenRouter.
As far as subagent prompts and results being obfuscated, I just let Pi spawn new agents. Using skills and extensions, I’ve essentially built a software factory using Pi and a custom terminal multiplexer.
It’s a shame apps like T3 Code and other UI for terminal apps don’t support Pi and I’m glad to use the terminal above those that lock me in further.
- How did you decide on Pi over Opencode? What you see as the “edge” Pi has?by rad-b
- The other day, I hit 429 errors with Kimi-K3, had to switch to another model. And if I couldn’t just switch models, I’d be screwed. No work done.by deadbabe
- How will Pi help? If I'm using pi with my ChatGPT subscription, that won't unlock access to full, unencrypted reasoning traces. If I switch a pi conversation from 5.6-sol to kimi k3, the 5.6-sol reasoning traces won't be visible to kimi k3. I think that's the main point of the article, no?
- "I’ve essentially built a software factory using Pi and a custom terminal multiplexer."
I'm curious to know more about this. I was thinking about doing something similar using tmux (i.e. have one coding agent open up new ones in tmux and use 'send-keys' to control them). Is there any reason I might want to consider a different path? Something built on libghostty?
- Maybe we don't take sessions, but take something else that we can fully control. Sessions were always a poor substitute to capture or archive the basis on which the implemented code rested on. They get noisy over time even with compaction, were not always inspectable, no real science behind when to ditch a session and start a new one, and rarely have a clean mapping to the work done. So instead of trying to archive sessions as a means to preserve basis, we should create our own structures to make the agent/model capture basis outside of a session, and archive that instead.by vamsiraju
- Suggestions? My attempts to get the agent to summarize the discussion largely failed. Other options I’m considering is capturing design, implementation plans, and maybe sub-plans. I’m Other words precursor to actions. Another idea is to get an agent to review code post-action and capture that. In other words action outcomes. The actual reasoning is between these “checkpoints” and remains hidden. But maybe that’s ok.by DenisM
- I don’t see this as a big deal in practice. Conversations contain a bunch of junk anyway, so removing it from the context is usually good.
In my repo, I have a notes directory. I ask the AI to write a markdown file with what it learned, what work has been done, and what remains. In the next conversation, I can ask another model to pick it up from there. Sometimes I edit the note first.
by skybrian - My experience with long running sessions is that they lose track of what's going on. The signal to noise ratio is often very poor - some models are particularly verbose and spew a lot of crap. The output of an LLM session is either modification of code or a plan or summary - that has the value, not the session text itself.by leoedin
- Conversations provide a window into the minds of your coworkers and their agents. You could be using them to read between the lines when debugging.by esafak
- Oh, it very much is a big deal. In a setting where users can switch models easily and with no downsides, market forces will give us better and cheaper AI over time. If switching models is painful (as in, losing part of your context), the providers can create vendor lock-in, enshittify the user experience, and drive up cost. Even if there are workarounds right now, those AI providers have every incentive to make freedom-seekers more miserable over time.
It is disheartening that some AI companies are now setting the stage for enshittification. I hope we can collectively dodge that bullet.
by heisig - You loose inspection, export, replay and audit.
None of the popular providers have real moat, which is very much problematic for OpenAI and Anthropic; their operating margins are deeply red and they do not have the same reserves that FAANG/MANGA has. FAANG/MANGA does the same to kill fair market competition in the long run.
This is one of the ways in which model providers are attempting to artificially create moat where there is none.
There are only functional objections to this.
This is fundamentally antitrust material. However, this is “acceptable” in contemporary USA because the FTC has been gutted to follow Trumponomics.
by hashstring - > Conversations contain a bunch of junk anyway
This is what brought me around to doing more agentic coding. I set the task, require tests and the strict linting must pass and then leave it to blow smoke up its own ass about what's going on.
I see glimpses scrolling past of all the conversational language that used to frustrate me so much when using a chat interface and I can just let it flow on past.
I come back when its made everything pass, my life is better now.
The previous match was still too clever for clippy’s type analysis, so I’ve simplified it into a direct borrowed-pattern form and I’m validating once more. I’m replacing that wrapper with a direct, non-transparent error variant so the enum stays explicit and doesn’t rely on a generic anyhow bridge.
by cube00 - Part of the solution here I think is to move things out of band as much as possible. Make subagent invocations into tool calls to that agent. Externalize the tool calls themselves to CLI utils, maybe block native tools completely (unrelated but relevant, I just added the AskUserQuestion tool to the global deny list couple days ago because Claude occasionally forgot to honor my standing order to prefer plain text, and that tool is extremely annoying as it creates a gap in the dialogue) and use 3p alternatives. The /compact degradation is also very annoying, so make an alternative that does the same and saves the summary to a regular file. Maybe it's also worth prompting the LLM to save it's reasoning process to file, even if it takes a few extra tokens and it isn't the actual reasoning tokens.
With that said, I may have something that can already help with at least the subagents/tooling bit. Didn't really have a timeline (or solid intent) on releasing it, but with these shenanigans increasing there's no time like the present.
by skeledrew - I think the article gives a very good overview of a problem that most users of AI rarely evaluate / have to grapple with.
There really is a surprising amount of coupling that happens with many of the "frontier inference providers", where a lot of the powerful non-LLM extensions (web search, code execution) are packaged as simple "tools" on the surface, that build up a lot of moat. Those are parts that are in theory nicely separable from the inference API, and could be externalized via MCP servers, but are usually not offered as such by the inference providers themselves, and are often only available in a slightly less powerful variant from other providers.
We've faced that issue repeatedly while building a on-premise provider-agnostic Chat UI & platform[0], where even adding something as simple as an in-chat image generation tool for the end-users (which is just a build-in tool in the OpenAI Responses API), becomes a bit of an ordeal (though part of that is due to the MCP spec missing a native file transfer protocol as of today[1]).
I am quite hopeful though, as with recent shifts of interest towards open weight models, there will be more opportunities for companies offering alternative implementations in a easier plug-and-play manner.
[0]: https://github.com/EratoLab/erato
[1]: https://github.com/modelcontextprotocol/modelcontextprotocol...
by hobofan - I'm in complete agreement that things like encrypted sub-agent messages, etc, are terrible, especially because it is fundamentally irresponsible to have an agent running on your machine without the slightest hint of what the prompt is.
That said, I don't really see a problem with hosted tools being offered by providers. They're like impulse items at checkout.
You shouldn't implement image generation as MCP: just write your own tool. There are plenty of image/media inference providers (e.g. Fal), web search or deep research providers, etc.
by dannyw - This is an important article. I hadn’t realized it was already getting this bad. Like a frog enjoying a nice warm bath ...
> Most people do not switch their operating system or phone provider every week either. But even if you do not utilize that freedom, it matters because it changes the relationship you have with the provider and the provider has with you.
This is why it’s important to utilize your freedoms. Do NOT let yourself get locked into a particular ecosystem (this is why I’m building a phone app for OpenCode).
This article makes me reconsider using my recently acquired Codex sub in my home setup. I never liked that they hide the reasoning, but somehow overrode the cognitive dissonance because the performance is so good. But the inauditability is already a huge problem.
by solarkraft