Yeah go for it. It was really fun to build and I learned a lot about how these harnesses work. Definitely recommend building something like this.
For me, the use case is in my Remote Terminal app I'm building [1].
I have an agents sidebar that shows every running agent on the machine with the state. So I end up creating a kanban like board for all the agents based on if it needs my attention, is done or still working.
1. I don't want to extend the the harnesses in any way, not even hooks/plugins/etc
2. I don't want to poll, ever. It must be system events, file system watches
So I have to basically watch each session file from every harness for changes and derive a state from that.
Most CLI's have a file per process with some stats like the pid, state, is idle or not, etc, which is really helpful.
Each agent has a small provider that knows how that specific harness works, and watches it for changes. e.g. ~/.claude/sessions/{pid}.json
Those registries are small and change much less than transcript formats do.
But yeah, I think this will always be a matter of keeping it up to date.
I would like to retain support for older harness versions as I go.
I'm not sure. The problem with the cloud llm's is they are complete black boxes that change frequently and randomly day by day.
If you run Qwen 3.8 on your own hardware, every single day, it's the exact same model running in the exact same way.
Yes, it's nowhere near as "smart" as the cloud based models. But it's consistent.
So the workflows and "ways of working" you create will work mostly similar day to day.
With Claude/OpenAI you frequently find days where the models are useless, and days when they are out of this world.
So I guess the choice comes down to:
1. Randomly the smartest thing on the planet with unpredictable rate limits that is mostly amazing, but frequently messes with your workflows
2. A really good local coding model that is consistent every day with no rate limits
I'm not sure. My gut feeling is maybe the right answer is a mix of both.
Gambling on the biggest models, hoping they are working smart that day, when planning or doing very complex work. Then doing most of the tasks/daily work using local models??
You can run any open model on a shared API host via OpenRouter and pin to which host you want to go for the quant/privacy/etc. mix you care about. You can pay them directly if you don't want the OpenRouter overhead - but the convenience of switching, having one invoice, etc. is worth it IMO
It's not closed hosted models vs open local models, it's hosted open models vs local open models where the math doesn't work for local LLMs.
The only local inference use-case I can think of is porn generation (because most providers don't want to deal with it) and illegal shit like hacking to minimize the tracing.
And if you're super paranoid - but honestly giving sensitive info to LLMs in any scenario is a gamble.
If you game and can use your GPU I guess then it works as well but models that fit into a gaming GPU suck too much to bother IMO.
I don't like Apple as a company or how they act around locking people out of the devices they buy.
I'm willing to pay double the cost of a MacBook Pro for anything that can run Linux, similar performance to M5, have a decent battery, good touchpad, be silent, have a good display, be light and portable.
It doesn't exist. MacBook's simply have the best hardware, but terrible software/philosophy of software.
So I'd say their moat is hardware in general. Performance, yes to an extent, but it's performance vs heat vs energy vs battery life and all their peripherals.
> I'm willing to pay double the cost of a MacBook Pro for anything that can run Linux, similar performance to M5, have a decent battery, good touchpad, be silent, have a good display, be light and portable.
This is Zenbook A16 right now, with recent patches posted to Linux ARM mailing list that support it in full.
I specifically check the touchpad as well, since right now I am on a MacBook running Asahi and I just can't stand other touchpads. I even tried a Thinkpad for a while and had to return it.
However, while ZenBook's touchpad is not haptic, it's at least a glass one and generally praised for being quite good in comparison. I asked a bunch of people. Notably I prefer to double tap than press on my touchpads, so I don't really care about the haptic feedback, but to each their own. Still, I think it's worth trying it. BestBuy should have them in store if you're in US, I haven't tried it myself yet.
And yes, it's surprisingly quiet. It's a bigger form factor (16") despite very low weight, so that helps with heat dissipation and X2 is very efficient.
To add to my other post: just today I saw a report on Zenbooks good touchpad quality from a previous M2 Pro user. And they also specifically cared about it.
I think the answer to this is yes, it'll be just like "reading and understanding your assembly". We just don't check what instructions your code compiles down to anymore, and I think the same will be for code.
100% agree. I've ended up building my own [1][2] mostly because I got annoyed the agent cli's are building remote control into the agents, instead of into the terminal. I really want the agent cli's to focus on being the best autonomous agents, then let me choose a great terminal that does all the extra.
Another great option (not mine) is Orca [3] and it's a lot more mature. Really nice to use.
I'm glad it works for you, but I've got enough electron apps running on my computer already. I have to run a bunch for work and fully half my cpu is just electron at idle
Did they give a reason why it was declined? Was it some bureaucratic "form not filled in correct" thing, or are they actually against the concept of it?
To elaborate: it should be plain obvious that not every Emoji proposal can be accepted even though all of them are correctly filed, as there would be too many Emojis there then. So there has to be some threshold, and that threshold is mostly stipulated by vendors' willingness to process new Emoji characters for designing fonts and updating softwares in time.
That list only includes suggestions that were seriously considered and voted on.
Since it's a vote, there is no single official 'reason' for rejection. If I had to guess: it would be confusing to anyone who didn't grow up with American TV shows.
They were grandfathered in, not voted on. Or rather there was a vote that resulted in adopting the character sets developed by Japanese telecoms en masse.
Weirdly this is in line with Unicode in general. Widespread (and not even widespread) historic use in say print results in characters getting included.
what's the connection to american TV shows? i'm only aware of the tinfoil hat through cultural osmosis i guess, something about shielding from radio waves
it's a popular image/byword/archetype for conspiracy theorists, idk if it's a common enough symbol to justify emoji inclusion. the submitted proposals probably have analyses of that though :p
Generally Unicode is for encoding all existing encodings/writing.
So you generally can’t add something because it would be cool or fun or useful, but only because it is currently in use and cannot be encoded by Unicode.
That's not at all the case. Unicode began as a standard for making things like string(':)') in to a single character.
Consider all of the languages it supports. Consider: ﷽ (which isn't an emoji, but the point stands) which is an entire sentence. It was already in use in certain places and unicode decided they wanted to support it, so now they do. Previously, one would have to type out the entire sentence in the original characters, but now it is a single unicode, just like u+263a () used to be alt+1 (). The emoji was already in use long before unicode existed, and in seeing it in common use, they decided to support it.
I'm not sure if this [1] is still relevant, but it appears that Vivaldi makes money by promoting search engines and bookmarks to their users via their closed source, secret, Chromium fork.
If my usage of their Chromium clone is being used to sell search engines/website bookmarks, then I am indeed the product.
There does also seem to be a VPN option on their site that I'm assuming I can pay for, which seems it could be an actually buyable product rather than selling my usage of their browser.
"Being the product" refers to recording user behavior and processing it for gains. Displaying non-personalized ads (which are trivial to completely avoid in Vivaldi) is not that.
That's not really what "being the product" is commonly recognised as.
Vivaldi go out to their customers (that's not you) and say "We have 1000 suckers who have downloaded and use our closed source, Chromium cloned, browser. We can serve your website as a bookmark to them, or add you to their search engine list if you give us $x."
Since you are not their "customer" (that's the people paying them to appear in your settings) what are you? You are the "product", you are what Vivaldi is selling.
That's actually NOT what this phrase implies. It is really about targeted ads and the drive for more ads and more precise targeting based on user data. Look up attention economy.
Vivaldi is not that. The only place where it shows anything remotely like ads is its default start page with prepopulated links and that can be hidden by flipping a single setting. I haven't seen this page for at least a couple of months now o my Vivaldi instances.
You have a different definition of "being the product" than I do. A business that takes money from advertisers in exchange for your attention is selling your attention. You are the product is shorthand for your attention is the product, short of slavery.
But in order to fit the phrase the business has to actively fight for user attention to get the space for ads. This is specifically the search engine and social media model. Vivaldi is not fighting this fight. At all.
I'm building yet another terminal [1][2] for macOS and Linux. I've been unsatisfied with the window management of iterm2 and other terminals, my one acts a bit more like Chrome with projects at the top level.
It also allows remote control. I don't like AI harnesses (Claude / OpenAI) having remote control inside, it feels like it should be at the terminal level, not the cli.
It also allows commands at the terminal level. So if you use multiple ai cli's you don't only need to write the command once, then use cmd+l to inject into any cli.
I've put macros in too, that again can automate doing the same thing in a terminal.
Anyway I'm sure this will just end up another terminal in a sea of already existing ones.
For me, the use case is in my Remote Terminal app I'm building [1].
I have an agents sidebar that shows every running agent on the machine with the state. So I end up creating a kanban like board for all the agents based on if it needs my attention, is done or still working.
1. https://terminay.com
reply