One thing you can try is to build specialised subagents to help tease out more thinking when you're stuck with a model with limited reasoning budget as all the codex sub models seem to be (compared to API) --- but I have no firm, hard evidence of this so treat it as guesswork on my part.
Let me explain.
Creat a subagent that is told to just mull about a subject. This can be a simple file.
Have the agent expound on it with its own thoughts and additions.
Now rinse and repeat: give the file to another blank 'reasoning' subagent; then another; and so on.
This will eventually reach a point where they are unlikely to add more real value.
I believe they've locked down temperature and other sampling parameters so you cannot tweak these to get it to consider more unusual approaches.
The absolute best approach is a second model that is of a different family. Try Deepseek, GLM, Qwen, etc. and have it add its own thoughts. As a bonus, these models do not hide their reasoning. Put that in a file also.
start with a $10/m OpenCode Go plan, get yourself a gateway like GoModel and put all your credentials there, and then use a vendor neutral harness like OpenCode (because the big labs are not interested in supporting other model families than their own, they hold you down for the sake of their profits)
If all you're going to do is chat with an AI, you don't need a 400B parameter MoE model.
13 TPS is unusable for agentic coding, because if decode is that slow, then prefill is absolutely abysmal, and agentic work live and die by prefill speeds.
I’ve been agentic coding at home with like 15 TPS on average. I don’t mind it at all. I can give my agent a big task or a list of little ones and just… do something else. Why do I need to watch it work?
Seconding this. 2-bit quant of DSv4Flash 0731 (Unsloth) running on lemonade-llamacpp on a Corsair Strix Halo. OpenCode had an issue giving me 400s constantly for the past few weeks, so I just went all-in on local dev with omp. Yes, it takes time, but also: it works quite well. I've since gotten OpenCode to behave, so I'm back to using that quite a bit, but the local machine is really good as a "smol" model in omp, for example.
It doesn’t. Decode is by far the most dominant and expensive part of agentic tasks and once prefill hits a certain achievable speed decode dominates the time in ant agentic flows with reasoning. There is a reason input is so much cheaper :)
Isn’t input so much cheaper because it’s just less work? Prefill is usually 10-20x as fast as generation.
If you have 200k context, but only 200t/s prefill, then you’ll wait multiple minutes when continuing an average session from yesterday. Or compaction - might take 15 minutes.
No commercial service has 200 t/s prefill though. It is 1000s of pps for prefill. It is largely compute bound and very very fast on modern GPUs and model architectures. That is my point. It is an order of magnitude faster than decode, which is largely bound by memory bandwidth and just has a much harder limit. Prefill tends to look like a small slice in typical compute / token generation budgets. I am not saying it isn't important (I have been working hard on my own inference engine for flash next and am intimately familiar). I am saying it does not dominate. Also compaction and reading the whole prompt tends to be one of the few times you really hit peak pps because it is cached and you can just fill your data pipes for a bit. Also Deepseek showed you can make kv cache really cheap. Decode is still decode.
The math. It’s pretty brutal. You have to multiply insanely large matrices in memory. A dense model has to have and multiply across every parameter basically. MoE models work around it, sure, but you still have to hold a lot in memory and density of activated parameters matters. There is not much of a way around it yet. We are potentially getting there, but its not obvious yet.
I have not tried Flash Next yet; but 27B is a cracking, little model. It is the first small model that I, as someone with 30 years of experience, can finally say is good enough to hand off small and mid-sized tasks and expect a pretty good result.
It is also a competent tool caller when quantised to NVFP4 for use with ninfer; my own harness only reports the occasional hiccup and it is only because the model will sometimes emit tool calling tokens in its reasoning loop.
Delphi would compile & link 2 MLOC of code on a crappy work laptop in 30 seconds to a minute. Incremental compiles were instant. So fast most developers never bothered learning the "go to next error" hotkey and just spammed F9 (compile & run) whenever they fixed a syntax error. It was that fast.
Trivial C interop - yes. Both pascal and cdecl style calling conventions.
Toolchain? Back then - yes. Today? Probably not; depends what you mean by it. It had perfect COM interop which mattered back then, and you could trivially link stuff if you wanted to. And people did.
Comptime here means not "compilation time", but rather ability to run some your code during compilation (i. e. compile-time metaprogramming). Pascal didn't had this.
They probably know that. I specifically mentioned actual compilation time as another one of the things that's great about Zig, so it is relevant to mention. Certainly the language sounds nice from what I'm hearing. These days most languages are deeply neglecting compilation time as a feature (interpreted languages aside), so Zig is a breath of fresh air for me in that regard.
This includes some languages inspired by Golang, that have "inherited" Pascal influences, such as Vlang. There's also a focus on fast compilation and being useful for prototyping.
Meh. The challenge is 4k+ at high display frequency that doesn't cost the same as a small boat. There are gazillions of KVM switches that do 1080. That's easy.
It is 4K, just not the 120Hz or higher gaming grade the parent was asking for, and better than the 1080p of the JetKVM Mini. The JetKVM Mini does offer Ethernet, however (not sure if it can be powered by PoE, however, which would be a huge plus).
I think that's mostly marketing waffle, but I suspect the argument is that this will allow a LLM or agent to remote control your phone, tablet or computer in a format that is a bit more directly accessible for them than the VNC-like UIs most of this new crop of PiKVM-derived IP KVMs offer.
It's not like a lot of these small-time outfits used their own photography to begin with.
They'd pick a kebab from a menu of professionally made kebab pictures the printer has in stock. Or worse, they'd take pics of their own plated food with a dead-centre point flash in a dark cupboard or something and you end up with awful-looking food, no matter how good.
I'm not sure if I'm working with ChatGPT Images 2.5 or 2.0 here...
The original photo I took was at https://www.reddit.com/r/Tovala/comments/1pfuwrb/meatloaf_pa... - it's a cheeseburger meatloaf with potato wedges taken with a phone camera. And I was going for a consistent documentation approach for the photograph, not trying for menu proper.
I suspect that someone doing a menu could take a properly plated meal from the kitchen (rather than me photographing on top of my oven) and have it get redone for a good image for a menu without fundamentally changing what is being served.
But functional programming and OOP are intrinsically the same, but expressed using different primitives.
The thing that empowers first-class functions and closures (lexical binding) is the exact same method by which encapsulation works, even if the latter opts for heap vs stack. The fundamentals are the same.
Here's a simple one in Emacs Lisp:
(defmacro send (object method &rest args)
"Sends a METHOD to an OBJECT with ARGS."
`(funcall ,object ',method ,@args))
(defun make-animal (name)
;; 'hunger' is entirely private (encapsulated)
(let ((hunger 5))
;; here's our lambda using lexical binding
(lambda (method &rest args)
(cond
((eq method 'get-name) name)
((eq method 'feed)
(setq hunger (max 0 (1- hunger)))
"Yum!")
(t (error "Animal does not understand: %s" method))))))
(let ((good-boy (make-animal "Rex")))
;; "call" (via our macro) the "get-name" method; then feed. hunger does down 1.
(send good-boy get-name)
(send good-boy feed)
;; pretty-print the "object" good-boy
(pp good-boy))
;; this is the state of it after the two calls.
#[(method &rest args)
((cond ((eq method 'get-name) name)
((eq method 'feed) (setq hunger (max 0 (1- hunger))) "Yum!")
(t (error "Animal does not understand: %s" method))))
((hunger . 4) (name . "Rex"))]
Yes, you can express everything using lambda calculus. Kinda.. so why not use a thing that already exists? Why invent a new language (encapsulation) when previous (binding) suffices?
OOP is fine. Not using OOP is fine too if your architecture / design demands it.
What people forget -- much like the design patterns in the gang of four book -- is that languages and frameworks evolve.
A decorator pattern was a niche but useful abstraction in the 1990s. In Python today you can @decorate stuff just like that. It's evolution.
The same holds for OOP. Encapsulation and co-located methods with the encapsulating slots was an incredibly powerful upgrade over basic structs. Now most languages have first-class functions and lexical scoping so you can build your own encapsulation that way.
I used to be OOP hater, but realized that it has it's place and some problems are OOP shaped and OOP is a wide range of techniques. I do think that python is a sloppy language and generally don't like it.
Functional programming has it's place and I love it and is probably what my mind goes to the most, but often in Functional languages I find you can 'over fit' to a particular way of doing things, And with OOP your get more degrees of freedom with things you can do with a class and things can be modified easier, think sort of problems like a board game just as an example treating the pieces as an object can make it easier to modify any section of the logic of the game and add new pieces then the typical functional approach.
I often have to teach basic OOP concepts to junior - mid level developers.
Many who've entered the career in the last decade or so seem to have missed what I 'd consider to be quite a fundamental grounding.
Not even advanced concepts from the gang of four book - though I have taught these too - but often just an un-awareness of OOP in general, even simple things like understanding encapsulation.
Frameworks and languages do evolve, but never being taught basic things like encapsulating state or exposing dependencies seems an issue. Very differnt from my own time as a junior when this stuff was constantly hammered home.
You're probably right. But they most likely know more about functional programming, logic programming (if they studied CS), and have some awareness of advanced concepts that generally weren't widely known when we were young.
I think it's just a shift in how development works: epicycles and all that. Luckily most OOP stuff they need to know can be taught quite quickly. And perhaps not knowing about GoF is a minor win for cyclomatic complexity in your codebase :-)
If you're a Typescript developer doing React you're probably not going to reach for classes, for example, as it's just not a common paradigm in most modern React/TS codebases.
OOP hate is definitely a popular way to signal that you aren't just a "common grunt programmer". And there are personalities who have made it a big part of their appeal.
But I also spent some time with modern Spring Boot, and I get where the hate is coming from. There is a lot of complexity that just doesn't seem necessary at all.
> But I also spent some time with modern Spring Boot, and I get where the hate is coming from. There is a lot of complexity that just doesn't seem necessary at all.
I'm sure there is some (very high) level of inherent project complexity where the massive number of abstractions and tools that Spring Boot gives you (and forces on you) actually starts turning into a net positive... And I'm also fairly sure that most projects don't quite break even, and would be better off with something more lightweight.
the functionality is often necessary and useful the question is if they're required to be implemented in the way that they are or if there is a simpler approach.
also a lot of oop hate is 1) hatred of compile-time hierarchies attempting to match the domain model and 2) all the complexity in oop systems which isn't really inherent to OOP but made possible by it. oop doesn't require a PrototypeFactoryInjectorFactoryBean but it doesn't prevent you either :)
on the flip side I've seen functional codebases which are also full of complexity because of how fragmented everything is, like 20 functions all applied when it could have been a single imperative one making it hard to keep track of what is happening.
I think the hate typically comes from the mis-application of various tools; overly complex solutions for simple problems. There's nothing wrong with patterns per say, or frameworks that have complex building blocks for every conceivable permutation of relatively common issues. However, when people reach for unnecessarily complex tools out of laziness/habit, some hate is justified. I suspect this is very similar to what you're saying, and of course, it's not OOP specific. Functional languages have their patterns too, but instead of a famous book enumerating them, we have a famous blog post stating that functional languages are so awesome that they don't need patterns (or at least, this is how most people seem to interpret it).
Well, I just wrote a comment that could be considered an "OOP hate". I was debating whether to do it.
The point is not to be snug about it. Functional programming (and monads) are actually simpler. You just need to resist the urge to "make it more understandable".
Abstract math doesn't have good analogies to the real world. By trying to make an analogy with the concrete ("monads are mappable") you lose simplicity.
Monads might be simple but it's easy to create confusing large stacks of monad transformers in the haskell world, At least I have found and can often become not the most pleasant to work with aliasing complex monad stacks and all the rest, It can really lose elegance. Some problems beautifully fit as Monads and single monad code can be nice indeed but a few transformers and you can end up with a lot of mess. I do think there is some things that functional programming paradigm struggles with like games programming and other things, I really do think OOP is a better choice for some problems.
That relates to another misunderstanding. These ideas like "everything is a function" or "everything is a category" are not there to help you understand complex system better.
They are supposed to help you build better foundations; the abstractions to better understand your complexity you need to build (or at least pick) yourself.
Good foundations then help you relate the abstractions. For example, the categoric dual of a product is a sum. We can apply it to relation (relational algebra), and we get that sum is data inheritance.
So that gives you understanding of how functions (foreign keys), product (relation) and sum (inheritance) fit together. This sometimes helps to build abstractions in a consistent way.
Oh, I agree. But there's value in people who set out to do things a certain way, even if that approach ends up not working well in the long term.
We're collectively shaking a lot of trees when we build frameworks, languages and tools. What works? What does not? What is the right level of abstraction? How much developer ergonomy do we want to sacrifice?
Sadly we only seem to know in hindsight what works well. But that is also how we learn and grow; it was just meant to be this way.
Some problems don't require OOP, but most large complex problems do, IMO.
Most complex codebases I've seen which were pure Functional Programming were spaghetti code; unmaintainable.
What I saw every single time was that the project was syncing a huge amount of state in a central place and then passing it through a large number of components and sub-components. The top level component basically had to have full awareness of everything going on inside the system in order to do its job and there were no separation of responsibilities because none of the components had sovereignty over the state they needed to do their job independently. It's just components micro-managing components all the way down.
React with Redux is probably the best FP implementation I've seen thus far but even it is kind of a mess. I have nightmares about Redux Saga. The Redux Saga logo is literally a stylized drawing of entangled spaghetti.
Had Redux + Saga been presented to people as part of React at the time it was introduced, React would probably not have become so popular. Because people would have understood that it creates too much unnecessary baggage which isn't worth it. React was used as a gateway drug to Redux which was itself a gateway drug for Saga! And what I observed in practice is that most React apps are glitchy AF; and those glitches are usually difficult to reproduce and fix, even if you know all the ins and outs of the framework!
Component is not a term out of the FP schoolbook. I am sorry to be making what smells like a true scottsman here, but you seem to be describing a React codebase since they call themselves functional with that Redux stuff, you think this is functional programming. A graph of "components" all talking amongst each other. Functional. Programming. Come one, man :)
What you are describing is OOP. Passing messages between identities over calling pure functions with values.
In the newer versions of React with Redux, the components are all pure functions and state is centralized and passed down into the components. IMO it's as close as a codebase can be to pure functional programming whilst still functioning.
> IMO it's as close as a codebase can be to pure functional programming whilst still functioning.
You know, people have put functioning codebases using pure functional programming languages like Haskell, Elm, Purescript, etc. I really don't see what in your opinion is too close to FP to work.
Not a frontend developer and my frontend skills are lacking, but the argument I think that is being made is that a react component should generally be written with no side effects and rely on signal for state change and do reactive programming. While of course something like Elm is more so this model and actually is functional from the get go. In js/ts react you are writing a lot of code that aims to be side effect free.
Most programs code bases of course need some way of doing side effects and not being 100% pure so many haskell projects would not be classed as 100% pure.
That is just not the case. I have worked, full time, as a functional programmer coming up to 15 years, in different langauges. Actual functional programming and not merely doing web programming with React.
"[...] pure functional programming whilst still functioning."
I mean, what is this?
When I read what you are saying here, you are saying that an "advanced codebase", whatever that means, using functional programming leads to centralized state and distributed components. And you know this because the codebase you are thinking about has this software architecture.
I have been in such codebases too, they tend to be frontend and maybe that is just the way you have to do it, maybe not. But this is not a property inherent to functional programming. Solving problems with a component or object concept as a central abstraction for "a thing" is the OOP way. I know this because this is how I spent the first half of my career. You think you need a _substantive_ onto which you perform verbs. Nothing wrong with this though, I am not picking a fight with OOP.
I can offer what I refer to when I talk about FP so that we can at least have a real thing to disagree over :)
1. model the domain and interactions with it with strong types such that neither interactions nor state can represent values outside of the domain.
2. parse, don't validate
3. Use modules, stateless collections of declarations, to organize stateless functions. No this. No self.
4. No magic code. I.e.: no null checks, no magic number checks, no arbitrary logic in four places that together make up the fact that prices can have taxes. Abstract it and "store" these runtime decisions using typed values, use functions that accept these typed values to force use of the aforementioned types.
5. Control the side effects. This does not mean that you have to use Haskell or monads or anything like that. Just that managing it is a good thing.
6. #5 implies keeping track of state. I.e.: no, you may not just willy-nilly read it from the persistent store, cache or file.
> none of the components had sovereignty over the state they needed to do their job independently. It's just components micro-managing components all the way down.
Isn't one of the tenants of FP that nothing is mutable anywhere?
Correct, technically they pass copies of the state; which gets cloned at every component/module/function boundary. This protects you from 'spooky action at a distance' which is a real problem which can happen when mutable state is shared by different components but FP can introduce other issues related to passing around a lot of state which can become outdated as it traverses the many layers of spaghetti code.
ya ive seen the same but in OOP codebases, where the state is all distributed and incapsulated and it's just impossible to reason about how the entire system works because despite it's separation of responsibilities everything is still intrinsically coupled together. and then you have all sorts of hidden mutations and other shenanigans.
to me the best way to design large systems is sort of like an ecs. you don't separate components by state + behaviour, you separate systems and state.
video games are oop for historical reasons mostly. ue6 is built on verse which is a crazy functional language. carmack himself flirted with haskel and racket. but games are so perf oriented that for a long time the only options were c or c++ (c style ofc).
the current trend are ecs's which are distinctly not classical oop
You typically won't see it installed at all because it's considered an intermediate artefact. You'll have to compile Emacs yourself from source to get it.
Let me explain.
Creat a subagent that is told to just mull about a subject. This can be a simple file.
Have the agent expound on it with its own thoughts and additions.
Now rinse and repeat: give the file to another blank 'reasoning' subagent; then another; and so on.
This will eventually reach a point where they are unlikely to add more real value.
I believe they've locked down temperature and other sampling parameters so you cannot tweak these to get it to consider more unusual approaches.
The absolute best approach is a second model that is of a different family. Try Deepseek, GLM, Qwen, etc. and have it add its own thoughts. As a bonus, these models do not hide their reasoning. Put that in a file also.
reply