Hacker News new | ask | show | jobs
by GodelNumbering 2 days ago
"Half the money I spend on advertising is wasted; the trouble is I don't know which half." -John Wanamaker

This applies even more strongly to model choosing. I know for a fact that majority of my work doesn't require a very strong model, but separating the trivial and non-trivial tasks is a famously hard problem (if at all decidable).

11 comments

I don't see why it should be all that difficult. All you have to do is first find a library that implements a decent solution to the halting problem and you're off to the races.
Its funny because you can write a halting problem oracle by calling out to an LLM and have it return yes / no / not sure and get it to work reliably for almost all real code, like that is an entirely practical thing to do in 2026.

All we need now is some sort of program to evaluate halting problem oracles...

Wasn't the original proof something like "a program that loops indefinitely when the oracle says it will halt, and stops immediately if an oracle says it will not stop"? The whole point was the you can construct a contradictory program that cannot be decided by any oracle by its very nature.

```python

source_code = open(__file__, 'rt').read()

response = ask_llm("will this program halt, only answer 'yes' or 'no'?\n" + source_code)

will_halt = response == 'yes'

while will_halt:

   continue
```
You're right of course, LLMs provide a partial, unsound oracle.

The "halting problem is unsolvable" argument relies on the oracle not being able to output "not sure". But adding that option admits trivial oracles, like ones which output "not sure" for everything, so some are better than others.

The "real world" use most people have for halting oracles is as part of software safety, where if the checker outputs "not sure" you modify the software until the checker can decide if it halts.

Even if we had an answer to the halting problem, from a practical point of view, it's solving the wrong problem anyway. There's no point in distinguishing a function that would run forever from one that would exit after a century. They are both too slow.

Knowing that functions terminate is important for proof languages like Lean, where you often want to prove things without running the code at all. You're proving that one could, theoretically, calculate an answer, without actually calculating it.

It's an engineering vs science question, and we've solved the practical but not the theoretical. LLMs being non-deterministic is another one of those things.
You can use my script p-noteq-np.sh too if that helps.
I checked out your script but it looks like it's just a wrapper for ! ( p-eq-np.sh )
ya im partial to oracle.ts xD
Luna is comparable to GPT 5.4 from 4 months ago on many benchmarks. I know many who have said during that time, myself included, that if that's the model they had to use for the rest of their lives, they'd be fine.

GPT 5.4 is/was a very capable model.

Agree on 5.4. And it has 4x more quota than 5.6.
Canary tests on my data showed I needed xhigh to get good results, but they are good.
Cosmically apt username given the substance of this comment.
Exactly. I haven't reached the "let 1000 agents bloom" mode yet, so currently I'm spending real headspace managing agents doing work, and that work is all important, so why "settle" for sub-frontier models for that work? Maybe I'll get there for non-coding work.
> separating the trivial and non-trivial tasks is a famously hard problem (if at all decidable).

Famously, this is also a problem for human coders in sprint planning.

Highlighting https://news.ycombinator.com/item?id=49113236 in response.

HN could be run as a BBS on 70's hardware. Instead of using a CPU with ~10 thousand transistors, you're likely using one with ~10 billion to do basically the same thing, and you don't think twice about it.

If you have agents and users, you can run evals and see how far the models go. Luna is not greatest in tool calls, but if you define your problem well and the tools well, it is comparable to Gemini 4 Flash with much lower price tag.
Luna is good as an end user model for simple tasks like classification, but not as a coding model. Also do you mean Gemini 3.6 Flash? 4 doesn't exist, and Gemma 4 exists but doesn't have a Flash option.
Yeah, been running too many evals in the past week I start to mix the versions up. Probably should sleep...

We run an agent company and outside coding the new Gemini 3.6 Flash and GPT 5.6 Luna are very interesting. Luna can do a bit of research and create reports. Gemini is great for computer use.

For programming it's all Kimi K3 now.

Not my experience at all. I've been driving Luna xhigh in CoPilot CLI since it was released as my daily driver. Good reasoning, no problems with tool calls.
Not sure what you're working on as for coding it's still pretty bad at least for more complex projects compared to Opus.
don't expect it to be opus, but luna does coding just fine for its size/price
I get frustrated with a poor quality model leaving my codebase littered with wrong comments, which then later trip up smarter models.
I find you gotta do a smart model sandwich. Write plans with smart models, implement with cheaper models, review its work with smarter models. Catches a lot of mistakes before they propagate.
This is annoying. Similar with "context poisoning". LLMs can be highly productive... until they're "poisoned" with contradicting inputs / guidance.
Use a harness like OMP that lets you choose which model does which things. My main model is GLM 5.2, it handles planning and anything I dont have covered by other models. Tasks from todos and in sub agents are done by deepseek, I have different models for the git work like add/commit/push (that goes through cheap Minimax M3), and so on...

This way the expensive/strong model only handles the architecture and orchestration tasks. The cheaper models handle everything else and the strong one knows how to tell them what to do in enough detail to get good work out of them.

I've done a little bit in this space to try and see what works, and maybe it is different per language/framework but found the use case seems best for largely mechanical code changes, eg small direction, lots of simple changes. This sounds good until you realize that IDEs generally have built in functionality to do these tasks waaay faster, cheaper and more accurately.
I remember bugs always end up being more expensive then the first time I implemented the feature… so for me always sol always max… I don’t want to pay for a bug later
Using Sol or Fable for implementing is like having your Principal Staff Engineer with 30 year tenure routinely write CRUD functions for a REST API.

You use the big models to plan. Not just the overall plan, but which files need to be edited etc. Then they give that to the lower end model. So Luna or Sonnet, which are perfectly capable of following instructions and still creative enough to not get stuck.

> Using Sol or Fable for implementing is like having your Principal Staff Engineer with 30 year tenure routinely write CRUD functions for a REST API.

A Principal Staff Engineer who costs $2400 a year and never feels any work is beneath them? Hell yeah.

OK OK, usage limits

If you have bcherny levels of token quotas, you can use Fable for everything =)

The rest of us need to optimise a bit.

Where I'm at too, though max overthinks like crazy. xhigh is my sweetspot.
You just need a very strong frontier model to do triage of your tasks.

/s

That's not necessarily a joke; the article proposes exactly that.
It's funny how codex itself can't do Sol orchestrator / Luna implementor out of the box.
That's surprising. Does it have no sub agent support at all or does it just use the same agent as the parent?
They do have subagents, released v2 of that feature with the launch of 5.6 model series in fact. It's just... very poorly executed, is a significant regression from subagents v1 and thousands of miles behind subagents of Claude code.

- Models that can be launched as subagents are hardcoded (can only be another Sol or Terra, but not Luna). Most of the time it'll just launch same model as parent anyway.

- They encrypt initial task delegation from root agent to subagent, for whatever reason

- You can't switch into subagent view at all, despite the fact that apart from initial root>subagent task handoff, all session is visible in transcript.

Which is why I use CLI subprocesses as subagents... Codex in 2026 is still nowhere near where CC was in summer of 2025...
With Claude you can have "use a lower tier subagent when appropriate" in CLAUDE.md and it'll just work. The "smart" agent goes in a busy loop observing the subagent(s) and will confirm their work afterwards.

(also you need to gate it with "tell the subagent it's a subagent" and "if you are a subagent, don't spawn subagents" or you'll get a matroshka doll of sonnets all the way down =P )

Codex kinda sorta can launch a subagent, but that's about it.

I mean, yeah. Alternatively I’ve seen the approach of starter with the cheaper/faster model but give it a tool to handoff or talk to a strong model if it gets stuck.