Avalon local LLM

[Pocster]

2 minutes ago, Sparrowhawk said:

 

"Just make one model that follows the green line, not 3 models where I have to work out which to use when and on which settings, and guess which will be more token efficient..."

Really helpful. I guess it depends what you are using the model for; but for me opus 4.8 is destroying gpt5.5 for coding in my experience.

I mean they have codex. If I get that to 'scout' it can take a minute+. Yet claude (git is local in both) takes 20 seconds, explains the code and proposes patch. Codex was never that reliable. Codex suggestions for patch I dumped back into gpt5.5! - it usually said they were wrong. But the claude "I can open a preview" and agentically fix the issue is AMAZING. i guess the claude environment is just far easier and cleaner for me than my attempt to harness gpt5.5. I did ok for 20 quid a month mind for quite a while.

[SimonD]

6 hours ago, Pocster said:

What isn't clear at all (probably deliberately) is things like is best sonnet better/worse than say opus on lowest setting?. Difference in settings is vague anyway - "reasons more" meaning what? it puts 10% more effort in. How would I know it really did "reason more". I think this cloud AI needs new rules on what you actually get for your money -  feels a bit make it up as they go along. Still love it - NEW TOY INDEED!

 

To answer this question, I thought I'd put it to Claude, using Sonnet 5 and this is the explanation 😁:

 

Good instinct to probe deeper — the "logic vs pattern matching" framing is close, but it's worth untangling because there's actually a common conflation happening in how people talk about this.

 

The big one: "reasoning models" (like OpenAI's o-series, DeepSeek R1, or Claude with extended thinking) are still generative models. They're the same transformer architecture, doing the same thing under the hood — predicting the next token based on learned statistical patterns. There's no logic engine, symbolic rule-checker, or formal proof system bolted on. So it's not really "reasoning vs. generative" as two separate categories — reasoning models are a subset of generative models, trained and used differently.

 

Where the real differences live:

1. Training objective. Standard generative/instruct models are trained mostly via next-token prediction on huge text corpora, then fine-tuned to be helpful and follow instructions. Reasoning models add another stage: reinforcement learning on tasks with verifiable answers — math problems, code that either passes tests or doesn't, logic puzzles. Because the reward signal is "did you get the right answer," the model gets pushed toward generating long chains of intermediate steps that make correct answers more likely — things like trying an approach, checking it, backtracking, trying another approach.

 

2. Inference-time behavior. A standard generative model maps input to output in roughly fixed compute — one pass, token by token, no deliberation step. A reasoning model spends variable extra compute before answering, generating a chain of thought that's often much longer than the final answer. This is often called "test-time compute" — you're trading latency and cost for accuracy on hard problems.

 

3. What's actually emerging is learned deliberation, not logic. The self-correction and step-by-step structure you see in a reasoning model's output are patterns the model learned statistically pay off on verifiable tasks — not the result of a discrete symbolic reasoning process. It's still fundamentally pattern completion; it's just learned to imitate and refine the pattern of "working through a problem carefully," because that pattern correlates with getting rewarded.

 

4. Where each shines. Reasoning models pull ahead specifically on tasks where there's a checkable ground truth — math, code, formal logic, some kinds of planning — because that's where the RL signal exists. On open-ended, subjective, or creative tasks (write me a poem, what's a good gift for my friend), the extra deliberation buys little, since there's no "correct answer" to verify against.

 

5. What genuinely didn't change. Neither type has guaranteed soundness. Both can hallucinate, make arithmetic slips, or confidently reason to a wrong conclusion — because underneath, it's still probability, not proof. If you want actual logical guarantees, you need to pair a model with an external tool: a code interpreter, a calculator, a formal theorem prover. That's a genuinely different paradigm — classical symbolic AI (expert systems, SAT solvers, planners) — which really does manipulate symbols with explicit rules and can guarantee correctness within its formal system. That's probably the sharper "fundamental" divide you're sensing: not reasoning-LLM vs. generative-LLM, but learned-statistical-generation (even when it looks like reasoning) vs. rule-based-symbolic-computation.

 

If it's useful, I could sketch a quick diagram contrasting the training/inference pipelines of the two approaches — let me know.

 

 

 

 

 

Both paths share the same foundation — the same pretraining, learning the statistics of language from huge amounts of text. They only diverge afterward.

 

 

The left branch is the familiar path: instruction tuning to make the model helpful and well-behaved, then inference in one fixed-length pass — you send a prompt, tokens come out, done.

 

The right branch adds a stage: reinforcement learning where the model is rewarded specifically for landing on verifiable correct answers (math, code, logic). That training pressure is what produces the "reasoning" behavior — and it shows up at inference time as a different mode entirely: the model generates a long chain of thought, checking and revising itself, spending variable compute depending on how hard the problem seems, before committing to an answer.

 

The thing worth sitting with: nothing in that right branch is a different kind of computation. It's the same token-by-token generation, just shaped by training to produce a "let me work through this" pattern because that pattern got rewarded. That's why reasoning models can still confidently reason their way to a wrong answer — there's no proof-checker in the loop, just a learned habit of deliberating that usually, but not always, tracks truth.

 

Q. What is it that makes one model better at something like coding versus problem solving complex questions

 

A few genuinely separate factors are stacked together here — it's not one lever, it's several:

 

1. How verifiable the reward signal is during training. This is probably the biggest one. Code has a built-in ground truth: does it compile, do the tests pass, does the output match. That's a clean, dense, automatic reward signal you can run at scale — write code, execute it, get a binary pass/fail, no human needed. Complex problem-solving (say, an ambiguous business strategy question, or a multi-step logic puzzle without a single "correct" answer) often doesn't have that. Even math and formal logic, which do have checkable final answers, don't verify the intermediate steps — a model can get the right answer via a flawed argument and still get rewarded. So coding ability tends to improve faster and more reliably under RL because the feedback loop is tighter and harder to game.

 

2. Data availability and density. GitHub alone provides enormous volumes of code paired with tests, comments, commit messages, and bug fixes — a rich signal for "this code was wrong, here's the fix." There's no equivalent firehose of "here's a flawed argument, here's the corrected reasoning" at that scale for general problem-solving.

 

3. Structure vs ambiguity. Code has strict syntax and (mostly) unambiguous semantics — a function either does what the spec says or it doesn't. Complex reasoning questions are often underdetermined — multiple defensible answers, judgment calls, incomplete information. Models trained hard on code get very good at satisfying a tight spec; that skill doesn't transfer cleanly to open-ended judgment.

 

4. Tool access changes the game. For coding, a model can be hooked up to an actual interpreter or execution sandbox, run its own code, see the error, and fix it — an external, ground-truth feedback loop at inference time, not just training time. For most "complex problem solving," there's no equivalent oracle to consult mid-answer, so the model is stuck relying on its own internal check, which is much less reliable.

 

5. What gets optimized gets improved. Labs benchmark heavily on things like coding benchmarks (SWE-bench, HumanEval) because they're measurable and commercially important. Effort follows measurability — so coding has had disproportionate optimization attention relative to fuzzier reasoning domains that are harder to even define "correct" for.

 

The upshot: it's less "this model is smarter" and more "this domain gave the training process a cleaner signal to learn from." A model can be excellent at code and mediocre at ambiguous judgment calls precisely because one of those had a built-in answer key and the other didn't.

 

There you go, hope that helps 😁

 

Edited 6 hours ago by SimonD

[Pocster]

Claude just stung me . Hit my 5hr limit early so bought more usage . Can see I’m using it - that’s fine . Then it stopped again saying I had reached my limit - which of course I hadn’t ! . Bought £5 more . Then got 10 mins then same again . Assume a bug . Emailed them ! Not much point to buying extra if you get blocked anyway !

Edited 6 hours ago by Pocster