jeffnash
1/ Allowing me to easily plug in any harness, using any provider, and make it a first-class worker. Omnigent has out of the box ACP support and it's trivial to use that to add first-class support for any harness out there. I love the ability to have CC + Opus plan, Codex + Luna implement, Pi + Qwen 3.8 give a tie-breaking opinion on a design decision that Opus flagged and Grok and Codex couldn't agree on, all orchestrated by a model of my choosing from any provider using Omnigent's main agent harness.
2/ Reusable agent systems rather than just reusable workflows. You can define agents in YAML whose subagents embody particular roles, with different models/harnesses, skills, plugins, tools, etc. preconfigured for each one.
Of course, claude workflows are now durable but Omnigent's agnt definitions are a bit more abstract in that they define the subagents that are available and how they should work by default rather than the workflow itself (i.e. the specific JTBD). If I have a common workflow that consists of, for example, Sol + Codex writing some script to scrape some data, Pi + a cheap DeepSeek-tier model formatting that data en masse, then Fable + CC doing some advanced analysis on it, I can embody that with a yaml agent definition that I can then use to run with my task of the day as a prompt. All of this is orchestrated by a model of my choice using Omnigent's harness.
This might look like: 'smart scraping agent with all sorts of scraping skills and tools pre-loaded', a 'bulk data processing agent with a cheap, fast model and plenty of pandas/numpy skills preloaded', and 'frontier model to interpret and reason on the implications of the processed data'. The main agent would have instructions about the general workflow of such tasks and when to invoke and delegate tasks to which subagent. The definition describes the workers available to the orchestrator and how they should generally behave, rather than hard-coding the workflow itself. I love that I can create those definitions and re-use them.
All that said, I am sure the labs will come up with their own similar products to (2) (e.g. dots today). I also recently noticed that Claude Code now has subagent 'teams' rather than just 'general-purpose'/'explore' subagents, and these seem to be longer-lived. This seems to be encroaching on the agent yaml definitions, albeit with less fine-grained control on my end. Therefore, the tl;dr (for me at least) is vendor neutrality; I don't think we'll ever see a product coming out of a frontier lab that eagerly delegates a task to their competitor's model (and bank account).
In any event, it's great to see competition in this meta-harness space, which is likely one that none of the frontier labs will touch since it, by definition, would utilize their competitors' products.
Is this not the default anymore? I am on the (now closed) 20x plan.
And re: the toml workaround, AWESOME! I appreciate you pointing these two things out, this is my highest-ROI HN comment thus far.
Terra had the "workhorse" quality where it could do these changes in bulk and follow directions without being too 'smart' (but sloppy) as you described. Luna was a bit too dumb and would make sloppy mistakes; I see that more as a "run these tests and format the results" sort of model. Maybe 6 Luna will be better.
I also just reread your comment and realized the naming convention is still extremely confusing with respect to ordering of [Family]x[Model]x[Number].
1/ Usage limits: downstream of input/output cost, but resets and obscure windows and odd 20x plan / 5x plan != 4x usage math throw a wrench into it. Winner right now is Codex by a mile, especially when you factor in the fact that ChatGPT usage (even 6 Astra Pro) is essentially unmetered on the 20x plan. Always a bummer when asking if I should see a doctor about a rash means I can't code as much. It's also is a godsend if you use an MCP like oracle to automate the process of calling the Pro model on particularly tough problems, giving better planning results or deeper code analysis without burning usage.
2/ Context window in the harness. Claude Code wins on this. There used to be a toml file workaround for Codex to extend the GPT context window to 1m, but this stopped working on the plans and only on per-token billing (ETA: noname120 pointed out this is no longer the case and it can be enabled again [1]). 252k is just not enough. Codex's compaction is very good, fwiw, but it happens so frequently that even a model as powerful as Astra sometimes loses the plot on long-running tasks.
3/ Ability to use the plan outside of the official harness. Codex wins. Anthropic does shit like bills requests as extra usage if it sees a hermes.md in a commit.
I've subscription hopped a bunch, and at times I've had both, but I keep coming back to Codex because it wins on 2/3.
ETA: apparently I haven't been Keeping Up With the Altmans and new 20x signups have been disabled for a few weeks. I am grandfathered in, which makes the comparison above pretty much moot.
It will be interesting to see how the notion of 'responsibility' carries over as agents handle higher and higher levels of abstraction. Agents built using the popular frameworks of today are somewhere in between code, formerly written by engineers, and an actor (like an engineer). When an agent wrote the framework to audit and monitor ops agents who are monitoring the performance and reliability of the code that coding agents wrote, who is responsible for ultimately ensuring it doesn't happen again? Should the findings just be added to whatever RAG and a few prompts/hooks/skills changed by another agent? When does a human follow up and to what degree?
This is the sort of thing that makes me believe that software engineers will never truly go away; at the very least, they serve the very useful function of being ultimately responsible for something going wrong.
Restrooms are unique in that they are available to the public but, due to their inherently private nature, are a place where it is difficult to enforce social norms. Because of this, within the confines of the restroom itself, the authorities are all but irrelevant.
I was scrolling through the addictive and easy to stumble into YouTube reels feature and came upon a livestream of a gentleman having some sort of 'public restroom party' in a stall. By this, I mean he had collected every roll of toilet paper available, shredded them into confetti, and was throwing the confetti up into the air while blasting music at full volume out of his bluetooth speaker. He had a few thousand viewers and people appeared to be donating money for supercomments. I didn't stay to watch the end of the livestream, but I don't imagine he cleaned up.
By the time the private-but-livestreamed confetti party is over, the damage is done. You can try to anticipate every single unwanted activity in a restroom and try to prevent it beforehand (e.g. tinted lights to prevent IV drug use), but someone, somewhere will find a way to creatively make the owners decide a few frustrated customers who are told "no public restroom" is a small price to pay for the alternative.
Enterprise is a whole different ballgame IMO with countless technical, compliance, and employee adoption considerations that add friction to switching. It's also where both Anthropic and (as of last week) OpenAI get the bulk of their revenue, and, incidentally, the venue where US Government regulations on Chinese models would have the most impact.
Anthropic in particular is much more compute-constrained than OpenAI and SpaceXAI and has relied on partnerships to provide inference. This reality factors into their pricing and usage limits (they started 'adjusting' the 5-hour limits during peak hours, and it certainly wasn't an upward adjustment). Accordingly, this is presumably what Anthropic wants, given they develop and release the lower-end models, suggest users use them in various nudges within their product, position the bigger/more expensive models as "For the most complex tasks" in their UIs, and so on.
Since it modifies logic across the full request/response lifecycle, I unfortunately couldn't implement it cleanly with the existing plugin API.
I wrote an APK that gives access to the accessibility service via an in-Android http server, which talks to a daemon running on the host machine which can, in turn, talk to Hermes. It's designed to be used with an emulator called Waydroid but you could probably run it on your device too. It does need to fall back to ADB when the accessibility tree is incomplete/inaccurate (which is often). And, going back to my question, I haven't found a means of interacting via ADB other than by coordinate/UIAutomator. To be clear, I am not smart or patient enough to be an Android dev, so I use it for ordering things on Amazon.
You obviously cannot always avoid this, so when there is a hard requirement for continuous feedback, use a degraded/cheap transient representation and refresh at commit of that action. With E-Ink, every interaction has to be a trade off between ghosting and latency. One common pattern I ended up coming back to is intermediate states that optimize for latency at the expense of ghosting until the UI action is 'complete'. This will allow refreshes to be associated with the satisfaction of finality. Funny enough, many of them harken back to old UI paradigms from when computer graphics weren't as powerful as today. When resizing, I simply draw the outline of the shape with a fast update mode that tolerates more ghosting until the user releases their finger or stylus, at which point, after a small lag to account for an 'oops, just a tiny bit bigger/smaller', I do a localized refresh of the union of the old + new area.
The outline itself is deliberately faint, so the refresh doesn't have to be as intense if its a small delta.
For your streaming LLM case, I would recommend doing it in chunks, like you said, perhaps doing a hard refresh of everything but the input box + moving the tail of last sent message + beginning of stream to the top upon send. Of course, this implies that you know exactly how long the response will be, which you don't. The challenge will be coming up with a UI paradigm that doesn't make it look awkward if the response only goes down to the middle of the screen while also nicely doing a clean refresh pre-emptively if it's clear it will overflow and need to move to the top. For the former case, find some way where it looks not completely awkward if it's partial and then do refresh of the chat history area and move it to its proper fitted position once the user clicks on the input box again to type their next reply. For the latter, perhaps embedding some kind of remaining space meter at the bottom that indicates when you'd need to do this move + refresh action (don't directly label it that way) would enable the user to anticipate it more and be less frustrated when it happens, as they are psychologically awaiting the next part of the answer/reasoning, not surprised at a sudden flash.
For the actual streaming, you'll have to ensure that your text alignment works in such a way that once a line is rendered to the screen, its placement is final (in other words, no streaming intra-word, as you need to know if the word will fit in remaining space on the line before rendering it). Basically, avoid retroactive reflow like a PDF document with a fixed layout, not like this text box I am typing in with a resize handle at the lower right. You'll also probably want to disable scrolling during generation as well, or at least make some sort of discrete pagination mechanism for going back and forth.
In any event, I look forward to seeing whatever it is you're building!
But the argument is you're trading some of that performance optimization for maintainability. None of this is exactly news. And while I'm here ranting: I never understood why shapes are the canonical OOP example. Shapes are a closed set of types (yes I'm sure GPT-324 invented a new one) with an open set of operations. There's always going to be one more thing you need to do with those shapes, but you'll never be adding new shapes down the road unless you are still in Kindergarten. OOP is useful for the exact opposite case, where there is a relatively fixed set of operations and you routinely introduce a new subtype that needs to perform all or most of those operations.
I've noticed that most courses that introduce the concept of OOP do so in a way that (perhaps unintentionally) emphasizes the false notion that everything should have an 'x-is-a-y' taxonomy before actually asking the question if that is appropriate. Putting the Cart extends Vehicle before the Horse extends Animal.
"Briefly stated, the Gell-Mann Amnesia effect works as follows. You open the newspaper to an article on some subject you know well. In Murray's case, physics. In mine, show business. You read the article and see the journalist has absolutely no understanding of either the facts or the issues. Often, the article is so wrong it actually presents the story backward-reversing cause and effect. I call these the "wet streets cause rain" stories. Paper's full of them. In any case, you read with exasperation or amusement the multiple errors in a story-and then turn the page to national or international affairs, and read with renewed interest as if the rest of the newspaper was somehow more accurate about far-off Palestine than it was about the story you just read. You turn the page, and forget what you know."
Grok aside, this has become an increasingly large concern of mine, especially now that I've expanded my usual provider rotation beyond the big 2. Out of arguably reasonable paranoia, I recently bolstered my own personal CLIProxyAPI fork to use an algo similar to gitleaks/betterleaks to, on the fly, scan the incoming (i.e. from my coding agent) stream for any secrets that may have been transmitted from disk, replace them with a unique identifier, send that off to the upstream provider, and then replace the secret (mapped to that identifier in memory, encrypted and with TTL) before sending any response back. That way, if the "secret" is either not really a secret and/or truly is needed in whatever tool call or response, the replacement is seamless to the client but the provider never sees your code.
No, it's not foolproof: it can't prevent some upstream actor from, say, using the on-disk key to your secret in a rogue tool call that uploads it from your device directly to an endpoint of theirs, but the low-hanging fruit like this is, IMO, the equivalent of not leaving all your windows open when you're naked. Virtually no downside or inconvenience to you, gets probably 3-4 9s of cases where someone would be inclined to see something they shouldn't because it's that easy.
The alternative is literally having to approve every read request (is this even a thing now?) and spend the mental energy ensuring that each and every file could not possibly contain a secret. I'd rather just code by hand at that point.
I chuckled because, as a joke, I made a website called djfa.ai (Dude, Just Fucking Ask AI), which is essentially LMGTFY for ChatGPT. As one can imagine, the gimmick wore off rather quickly, so I ended up haphazardly turning it into my personal blog, which I sometimes choose to abbreviate and sometimes not on my resume.
I would never have made it in the first place had most of the people asking me questions been like Yael: seeking my informed opinion on thought-provoking questions they'd already researched. Going back to your larger point about the social aspect of it all, even among my wife and my social group, "just ask Claude" is almost the new "I don't really know" or "that's a tough one" when it comes to any sort of question. Almost colloquial in the sense that it isn't to be taken literally, but more as an indication of uncertainty.
Now I feel like that I'm covered by GLM 5.2 and Minimax M3 (when I need vision or a second pass on something).
Knowing the caveats and pitfalls of this through years of (often-painful) experience is what, at least for me, allows me to preempt a lot of the sloppy assumptions or omissions that even the frontier models make when working on systems at scale. This means I can leverage my domain expertise on these high-level areas while delegating the grunt work that is harder to screw up to the agents. I find this enables me to work faster while avoiding the slop making its way into critical engineering decisions.
I think this was just about as close as I could get to asking Don Ho directly how he would prefer a port to be handled without actually doing so. I plan on publishing it shortly after cleaning up some God objects :)
I initially worried that a brand new name (I went with nootpad) might misleadingly suggest the project was built from scratch rather than being a semi-clean-room re-implementation. Then, I saw that NPP was trademarked and my worries flipped the other direction; the reason I haven't yet published it was because I'm still removing all the NPP references from the source + comments in an abundance of caution, leaving a huge disclaimer/attribution in the README. I know that OSS is an opinionated place and didn't want to step on any toes.
I must say, having all of that anxiety and seeing this guy literally put Don Ho's picture on the website and say that it was being re-named "in collaboration with" Don Ho (i.e. not in response to a legal threat) made me laugh out loud.