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).
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).
All we need now is some sort of program to evaluate halting problem oracles...
```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
```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.
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.
GPT 5.4 is/was a very capable model.
Famously, this is also a problem for human coders in sprint planning.
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.
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.
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.
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.
A Principal Staff Engineer who costs $2400 a year and never feels any work is beneath them? Hell yeah.
OK OK, usage limits
The rest of us need to optimise a bit.
/s
- 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.
(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.