Hey thank you for calling out the broken link. That should be fixed now. Will make sure to track down the other broken links. We'll track down why loading is taking a while for you. Should definitely be snappier.

Cool, looks like I'll stay on Cursor. All alternatives come out buggy, they care a lot about developer experience.

BTW OpenAI should think a bit about polishing their main apps instead of trying to come out with new ones while the originals are still buggy.

Same here. From my experience, codex usually knocks backend/highly "logical?" tasks out of the park while fairly basic front-end/UI tasks it stumbles over at times.

But overall it does seem to be consistently improving. Looking to see how this makes it easier to work with.

It’s possible to run up to 4 agents at once vs. Claude Code’s single thread. Sometimes I’ll find meaningful quality differences between what agents produce.

oh i didn't know that claude code has a desktop app already

The main thing I noticed in the video is that they have heavily sped up all the code generation sections... seems to be on 5x speed or more. (because people got used to how fast and good Sonnet, and especially Gemini 3.0 Flash, are)

> truly good (Claude, Gemini) to evolve

Claude yes, but Codex is much better than Gemini in every way that matters except speed in my experience.

Gemini 3 Flash is an amazing model, but Gemini 3 Pro isn't great. It can do good work, but it's pretty random if it will or it will go off the rails and do completely the wrong thing. OTOH GPT 5.2 Codex with high thinking is the best model currently available (slightly better than Opus 4.5)

I can't speak to the typos, but launching first for MacOS not something new for OpenAI. They did the same with their dedicated desktop client.

What’s the “7MM Tokens” typo?

Not sure when you last evaluated the tools, but I strongly prefer Codex to Claude Code and Gemini.

Codex gets complex tasks right and I don't keep hitting usage limits constantly. (this is comparing the 20$ ChatGPT to the 200$ Claude Pro Max plans fwiw)

The tooling around ChatGPT and Codex is less, but their models are far more dependable imo than Antropic's at this very moment.

I don’t hit Codex limits because it’s so much slower, is what I’ve found personally.

It's amazing to me that in the official Gemini app on Android, the hamburger menu on the left does not open on swipe - only if you click the hamburger button. A basic native UI interaction in the home screen of one of Google's flagship apps.

> this just calls Codex CLI with OS sandboxing

The git and terminal views are a big plus for me. I usually have those open and active in addition to my codex CLI sessions.

Excited to try skills, too.

Windows is almost ready. It's already running but we are solving a few more things before the release to make sure it works well.

Desktop GUI is a lost art. Gen X were the last people to master it.

It's already out.

Not totally understanding this. Crazy free tier but that it used a crazy amount of tokens that cost you? Sry just trynna see what you’re saying

Claude responds differently to "think", "think hard", and "think very hard". Just because it's hidden to you, doesn't mean a user doesn't have a choice.

Saying gpt-3.5-turbo is better than gpt-5.2 makes me think something you got some of them hidden motives.

https://code.claude.com/docs/en/common-workflows#use-extende...

>This requires calling native APIs (e.g., Win32), which is not feasible from Electron.

Who told you that? You can write entire C libraries and call them from Electron just fine. Browser is a native application after all. All this "native applications" debate boils down to the UI implementation strategy. Maintaining three separate UI stacks (WinUI, SwiftUI, GTK/Qt) is dramatically more expensive and slower to iterate on than a single web-based UI with shared logic

We already have three major OSes, all doing things differently. The browsers, on the other hand, use the same language, same rendering model, same layout system, and same accessibility layer everywhere, which is a massive abstraction win.

You don't casually give up massive abstraction wins just to say "it's native". If "just build it natively" were actually easier, faster, or cheaper at scale, everyone would do just that.

- Video games often use HTML/JS-based UI these days.

- UE5 has its own custom UI framework, which definitely does not feel "native" on any platform. Not really any better than Electron.

- You can easily call native APIs from Electron.

I agree that Electron apps that feel "web-y" or hog resources unnecessarily are distasteful, but most people don't know or care whether the apps they're running use native UI frameworks, and being able to reassign web developers to work on desktop apps is a significant selling point that will keep companies coming back to Electron instead of native.

The situation for Desktop development is nasty. Microsoft had so many halfassed frameworks and nobody knows which one to use. It’s probably the de facto platform on Windows IS Electron, and Microsoft use them often, too.

On MacOS is much better. But most of the team either ended up with locked in Mac-only or go cross platform with Electron.

It's baffling to me that people still throw around the word "native" like it means anything. Go use VSCode or Obsidian, then go use Apple Music. Electron can be so much better than anything native. The problem isn't that macos ChatGPT, Codex, or Claude isn't native. Their apps just really suck. They're poorly engineered and bad.

My main take is exactly the opposite. Why not build everything with a simple text interface (shell command) so the models learn to use these tools natively in pretraining. Even TUI like codex-cli or claude code are needless abstractions for such use cases and make full automation hard. You could add as many observability or input layers for humans as you want but the core should be simple calls that are saved in historical and documentation logs. [the headless/noninteractive modes come close, as do the session logs]

> even with the help of AI.

This is what you get when you build with AI, an electron app with an input field.

Hi! Romain here, I work on Codex at OpenAI. We totally hear you. The team actually built the app in Electron specifically so we can support Windows and Linux as well. We shipped macOS first, but Windows is coming very soon. Appreciate you calling this out. Stay tuned!

They have the same stack of a boot camper, quite telling.

If you were going to release a product for developers as soon as it was ready for developers to try, such that you could only launch on one platform and then follow up later with the rest, macOS is the obvious choice. There's nothing contemptuous about that.

Kudos to the OpenAI reps for responding to my comment and doing so politely.

My ire was provoked by this following on from the Windows ChatGPT app that was just a container for the webpage compared to the earlier bells and whistles Mac app. Perceptions are built on those sorts of decisions.

It’s just irrelevant for most users. These companies are getting more adoption than they can handle, no matter how clunky their desktop apps are. They’re optimizing for experimentation. Not performance.

The use of the name Codex and the focus on diffs and worktrees suggests this is still more dev-focused than Cowork.

Just jumping on the thread. I think the conversation is conflating two very different things:

1. Turing test UX's, where a chat app is the product and the feature (Electron is fine) 2. The class of things LLMs are good at that often do not need a UI, let alone a chat app, and need automation glue (Electron may cause friction)

Personally, I feel like we're jumping on capabilities and missing a much larger issue of permissioning and security.

In an API or MCP context, permissions may be scoped via tokens at the very least, but within an OS context, that boundary is not necessarily present. Once an agent can read and write files or executed commands as the logged in user, there's a level of trust and access that goes against most best practices.

This is probably a startup to be hatched, but it seems to me this space of getting agents to be scoped properly and stay in bounds, just like cursor has rules, would be a prereq before giving access to an OS at all.

It's interesting, isn't it? On the one hand the game is quite impressive. Although it doesn't have anything particularly novel (and it shouldn't, given the prompt), it still would have taken me several days, probably a week, working nonstop. On the other hand, there's plenty of paper cuts.

I think these subtle issues are just harder to provide a "harness" for, like a compiler or rigorous test suite that lets the LLM converge toward a good (if sometimes inelegant) solution. Probably a finer-tuned QA agent would have changed the final result.

I think deploying can already be done with the help of LLMs using docker and vpc's (e.g. hetzner and co.) rather easily.

What I struggle with is the legal overhead of e.g. collecting money for an app/website. I have a semi-finished app which I know I could delploy within a few hours but to collect money, living in Germany is a minefield from what I understand. I don't want my name made public with the app. GmbH (LLCs) cost thousands (?). The whole GDPR minefield, google-font usage scam etc. makes me hold back.

Googling/reddit only gives so much insights.

If someone has a good reference about starting a SaaS/App from within EU/Germany with all the legalities etc. I'd be super interested!

So much this. I'm eagerly waiting to see what anthropic and OpenAI do to make dictation-first interaction a first class citizen instead of requiring me to use a separate app like Super Whisper. It would dramatically improve complex, flow-breaking interactions when adding files, referencing users or commands, etc.

Importantly I want full voice control over the app and interactions not just dictating prompts.

I just want Anthropic to spend like two weeks making their own "Codex app", but with Opus.

Always sounds so interesting and then I do a search only to found out it's another product trying to sell you your 20th "AI credit package." I really don't see how these apps will last that long. I pay for the big three already - and no I don't want to cancel them just so I can use your product.

They are probably providing it for free for 1 month.

no

We have been working on this, letting any coding agent define infrastructure so we can define it effortlessly: https://specific.dev. We aren't just targeting non-developers though, we think this is useful to anyone building primarily through coding agents.

Replit already does this

interestingly opencode's first product was an IaC platform... seems to be where this is all going.

Aren't there 500+ aggregator services?

At least codex inside pycharm has auto edit off by default.

I wouldn't trust it. I'm moving to always running AI coding in a full VM.

I dont think these are made for non-devs, Lovable and other which are built for non-devs already provide hosting.

(I work on Codex) We have a robust sandbox for macOS and Linux. Not quite yet for Windows, but working on that! Docs: https://developers.openai.com/codex/security

Majority of devs > 60% in the valley use MacOS for development. Apple hardware is best in class. It's unix like. Cost isn't an issue. Macbooks look cool. Many reasons.

An idea just came into my mind. What if an agent could spawn other agents and provide them with immutable resource files and a 'chrooted' mutable directory those spawned agents could use recursively to prepare immutable resources for other recursively called sub-agents. The immutability and chrooting could be enforced by the harness.

Can't build iOS apps on anything else sadly.

Not going to solve your exact problem but I started this project with this approach in mind. It is exposed to the Internet though on a VPS or server but using caddy basic auth in front of the coding url

https://github.com/jgbrwn/vibebin

My bad then. I meant that it's "Crazy Good" as in that the free tier gave me a tremendous amount of tokens.

What I didn't realize though, is that the limit doesn't reset each 5 hours as is the case for claude. I hit the limit of the free tier about 2 hours in, and while I was expecting to be able to continue later today, it alerts me that I can continue in a week.

So my hype for the amount of tokens one gets compared to claude was a bit too eager. Hitting the limit and having to wait a week probably means that we get a comparable token amount vs the $20 claude plan. I wonder how much more I'd get when buying the $20 plus package. The pricing page doesn't make that clear (since there was no free plan before yesterday I guess): https://developers.openai.com/codex/pricing/

I am a gen X, this hurts, but it might be true :(

Is the integration with Sentry native or via MCP ?

and specifically, the big companies, in a way that people notice. Claude Artifacts, AI Studio, etc. all kinda suck. If you have used Manus or connected your own CF, GCP, AWS, etc. you see how easy it could be if one of the big guys wanted it to be (or could get out of their own way).

the big boys probably don't want people who don't know sec deploying on their infra lol.

That’s not really a negative for me as I can easily jump into vscode where I already have my workspace for coding set up exactly as I like it. This being a completely separate app just to get the agentic work right is a good direction imo

Usage like this is becoming a rarity. Most people are editing significantly less and "agent interfaces" are slowly taking the focus.

I'm not taking OpenAI's side here but have you reviewed what claude did?

PS: Yes, I spent several hours on the weekend getting Codex to add animations, sound effects, and a mini game to our home page hero graphic. That was fun. I look forward to the creativity that people unleash with tools like this in the coming months.

It's also interesting how the functionality of the game barely changes between 60k tokens, 800k tokens, and 7MM tokens. It seems like the additional tokens made the game look more finished, but it plays almost exactly the same in all of them.

I wonder what it was doing with all those tokens?

Agreed, had the same experience. Codex feels lazy - I have to explicitly tell it to research existing code before it stops giving hand-wavy answers. Doc lookup is particularly bad; I even gave it access to a Context7 MCP server for documentation and it barely made a difference. The personality also feels off-putting, even after tweaking the experimental flag settings to make it friendlier.

For people suggesting it’s a skill issue: I’ve been using Claude Code for the past 6 months and I genuinely want to make Codex work - it was highly recommended by peers and friends. I’ve tried different model settings, explicitly instructed it to plan first and only execute after my approval, tested it on both Python and TypeScript backend codebases. Results are consistently underwhelming compared to Claude Code.

Claude Code just works for me out of the box. My default workflow is plan mode - a few iterations to nail the approach, then Claude one-shots the implementation after I approve. Haven’t been able to replicate anything close to that with Codex

This is what I've been doing. Iterating on specs is better than iterating on code. More token efficient and easier to review. Good code effortlessly follows from good specs. It's also a good way to stop the code turning into quicksand (aside from constraining the code with e2e tests, CLI shape, etc).

But what is your concept of "stages"? For me, the spec files are a MECE decomposition, each file is responsible for its unique silo (one file owns repo layout, etc), with cross references between them if needed to eliminate redundancy. There's no hierarchy between them. But I'm open to new approaches.

That depends on whether Gemini CLI counts. I've had generally bad experiences with it, but it is free for at least some usage.

Just tell it to use your gcp/aws account using the cli, makes it infinitely powerful in terms of deployment. (Also, while I might miss some parts of programming that I have given to AI, I certainly don't miss working with clouds).

Shameless plug, but you can sandbox codex cli without a container using my macOS app: https://multitui.com

If you're using 5.2 high, with all due respect, this has to be a skill issue. If you're using 5.2 Codex high — use 5.2 high. gpt-5.2 is slow, yes (ok, keeping it real, it's excruciatingly slow). But it's not the moronic caricature you're saying it is.

If you need it to be up to date with your version of a framework, then ask it to use the context7 mcp server. Expecting training data to be up to date is unreasonable for any LLM and we now have useful solutions to the training data issue.

If you need it to specify the latest version, don't say "latest". That word would be interpreted differently by humans as well.

Claude is well known at its one-shotting skills. But that's at the expense of strict instruction following adherence and thinner context (it doesn't spend as much time to gather context in larger codebases).

(I work on Codex) I think for us the big unlock was GPT-5.2 and GPT-5.2-Codex, where we found ourselves needing to make many fewer manual edits.

Which paper?

I mean if they were targeting "software engineers" in general then Windows would be the obvious choice in 2026 as much as in 2006. But these early releases are all about the SF bubble where Mac is very much dominant.

Can you explain how to use it? I’ve tried asking it to do “create 3 files using multiple sub agents” and other similar wording. It never works.

Is it in the main Codex build? There doesn’t seem to be an experiment for it.

https://github.com/openai/codex/issues/2604

’’’Phrases like “think”, “think hard”, “ultrathink”, and “think more” are interpreted as regular prompt instructions and don’t allocate thinking tokens.’’’

I do it with ssh and tmux. I suppose tools could make it better.

I think a lot of AI talk doesn't explain where it shines the brightest (imo): Write the code you don't want to write.

I've recently had an issue "add VNC authentication" which covers adding vnc password auth to our inhouse vnc server at work.

This is not hard, but just a bit of tedious work getting the plumbing done, adding some UI for the settings, fiddle with some bits according to the spec.

But it's (at least to me) not very enjoyable, there is nothing to learn, nothing new to discover, no much creativity necessary etc. and this is where Codex comes in. As long as you give it clearly scoped tasks in an environment where it can use existing structures and convetions, it will deliver. In this case it implemented 85% of the feature perfectly and I only had to tweak minor things like refactor 1-2 functions. Obviously I read and understood and checked everything it wrote, that is an absolute must for serious work.

So my point is, use AI as the "code monkey". I believe most developers enjoy the creative aspects of the job, but not the "type C++ on your keyboard". AI can help with the latter, it will type what you tell it and you can focuse on the architecture and creative part of the whole thing.

You don't have to trust AI in that sense, use it like autocompletion, you can program perfectly fine without it but it makes your fingers hurt more.

i wonder if the skills will divide a bit. That there will be those who still program by hand - and this will be a needed skill, though AI will be a part of their daily toolset to a greater or lesser degree.

Then there will be the AI wranglers who act almost like DevOps engineers for the AI - producing software in a different way ...

I feel the same way about using the Internet or books to code. I'd rather just have the source code so that I'm not dependent on anything other then my own brain.

You can't write code in the Codex App, it's not an editor. You just manage agents (and ask them to write/implement whatever)

Coding agents with full automation like this require a different workflow that is almost purely conversational compared to Cursor/Windsurf/VS Code. It requires more trust in the model (but you can always keep Cursor open off to the side and verify its edits). But, once you get into the right rhythm with it, it can be _really_ powerful.

Or maybe, hear me out, we don't need any of this ""agent"" first shiny thingy

yeah, TUIs for AI is just lazy work imho. I'm glad at least this time it's a macOS app, but it's still just a shitty chat interface

also this feels like a unique opportunity to take some of that astronomical funding and point it towards building the right tooling for building a performant cross-platform UI toolkit in a memory-safe language—not to mention a great way for these companies to earn some goodwill from the FOSS community

Thanks for asking this - I had the same question.

Works fine with Azure setup in the config.toml because I think it’s Codex CLI underneath!

Wouldn’t maintaining the different UI stacks be something a language model could handle? Creating a new front end where the core logic is already defined or making a new one from an existing example has gone pretty fast for me. The “maintenance“ cost might not be as high as you think.

the three OSes is BS, none of them cares about linux

This is such a toy webdev take. It's like you guys forget that the web-browser wouldn't work at all if not for the server half, all compiled to native code.

The browser is compiled to native code. It wasn't that long ago that we had three seperate web browsers who couldn't agree on the same set of standards either.

Try porting your browser to Java or C# and see how much faster it is then. The OS the browser and the server run on are compiled to native code. Sun gave up on HotJava web browser in the 1990's, because it couldn't do %10 or %20 of what Netscape or IE could do, and was 10 x slower.

Not everybody is running a website selling internet widgets. Some of us actually have more on the line if our systems fail or are not performant than "oooh our shareholders are gonna be pissed".

People running critical emergency response systems day in, day out.

The very system you typed this bullshit on is running native code. But oh no, thats "too hard" for the webdev crowd. Everyone should bend to accomodate them. The OS should be ported to run inside the browser, because the browser is "so good".

Good one. It's hilarious to see this Silicon Valley/Bay Area, chia-seed eating bullshit in cheap spandex riding their bikes while the trucks shipping shit from coast to coast passing them by.

>If "just build it natively" were actually easier, faster, or cheaper at scale, everyone would do just that.

Exactly. Years go by and HN keeps crying about this despite it being extremely easy to understand for anyone. For such a smart community, it's baffling how some debates are so dumb.

The only metric really worth reviewing is resource usage (and perhaps appearance). These factors aren't relevant to the general population as otherwise, most people wouldn't use these apps (which clearly isn't the case).

Given that OpenAI managed to single-handedly triple the price of RAM globally, people will very much care about their chat application consuming what little scraps are left over for them, even if they don't know enough about anything to know why their system is running poorly.

microsoft also uses react native for the start menu and also bricked that during a recent upgrade apparently... along with breaking other stuff.

Qt with QML works fine. The real reason is that companies can't hire enough native developers because the skill is comparitively rare.

Win32 is the platform to use on Microsoft Windows. Everything else is built on top of it. So it will (a) work (b) be there forever.

I agree. I like using Claude or Codex in VM on top of the tmux. Much more flexibility that way. I open a new tmux window for each issue/task big enough to warrant it, issue a prompt to create a worktree and agents and let them go to town. I actually use claude and codex a the same time. I still get observability because of tmux and I can close my laptop and let them cook for a while in yolo mode since the VM is frequently backed up in proxmox pbs. I am a retired hobbyist but this has been a nice force multiplier without devolving a complete viby mess. I hope these new orchestration tool support this like vs code remote development does. Same for cloud. I want them to support my personal "cloud" instead of laggy github mess.

Do not give a shit about how they excuse doing a bad job. If their tools make them that much more productive, and being the developer of those tools should allow you to make great use of them.

Use native for osx Use .Net framework for windows Use whatever on Linux.

Its just being lazy and ineffective. I also do not care about whatever "business" justification anyone can come up with for half assing it.

Doesn't have to be. I just revived one of my C++ GLFW app from 2009. Codex was able to help me get it running again and added some nice new features.

I guess you get an Electron app if you don't prompt it otherwise. Probably because it's learned from what all the humans are putting out there these days.

That said.. unless you know better, it's going to keep happening. Even moreso when folks aren't learning the fundamentals anymore.

Claude code is perfectly capable of writing low level rendering and input code and it can be equally as mindless as vibe coding web apps.

E.g. just say "write a c++ gui widget library using dx11 and win32 and copy flutters layout philosophy, use harfbuzz for shaping, etc etc"

Only thing i'd add re windows is it's taking us some time to get really solid sandboxing working on Windows, where there are fewer OS-level primitives for it. There's some more at https://developers.openai.com/codex/windows and we'd love help with testing and feedback to make it robust.

Electron? Why can't Codex write, or at least translate, your application to native code instead of using a multi-hundred-mb browser wrapper to display text? Is this the future of software engineering Codex is promising me?

At the end of the day LLMs just reproduce the consensus of the internet, so it makes sense that a coding agent would spit out software that looks like most of what's on the internet.

LLM output is called slop for a reason.

Check out https://news.ycombinator.com/item?id=46829029

Because of that windows had thinking budget selectors for months before ios and macos (those got this only last week)

It's a smart move – while Codex has the same aspirations, limiting it to savvy power users will likely lead to better feedback, and less catastrophic misuse.

Yeah but its annoying to find the file the agent just edited without any IDE/editor integration, you have to add that command which opens the file in vscode after editing.

Deploying from Antigravity is as easy as say connecting the Firebase MCP [1] and asking it "deploy my app to firebase".

[1] https://firebase.google.com/docs/ai-assistance/mcp-server

I only use claude through the chat ui because it’s faster and it gives me more control. I read most of it and the code is almost always better than what I would do, simply because lazy ass me likes to take shortcuts way too often.

For greenfield apps you can vibecode it. For existing complex apps, where existing products where customers pay us a lot of money for working software, understanding the changes and context surrounding them in the code is critical or else nobody knows how the system works anymore and maintenance and support becomes impossible.

Sadly, my own small game-dev adventures look similar: I can implement the core mechanics fairly quickly, but polishing the game takes ages.

UPDATE: without AI usage at all (just to clarify).

I'd bet the initial token usage is all net new while the later token usage probably has reading+regenerating significant portions of the project for individual minor changes/fixes.

E.g. I wouldn't be surprised if identifying the lack of touch screen support on the menu, feeding it in, and then regenerating the menu code sometime between 800k and 7MM took a lot of tokens.

Curious, are you doing the same planning with Codex out-of-band or otherwise? In order to have the same measurable outcome you'd need to perhaps use Codex in a plan state (there's experimental settings - not recommended) or other means (explicit detailed -reusable- prompt for planning a change). It's a missing feature if your preference is planning in CLI (I do not prefer this).

You are correct in that this mode isn't "out of the box" as it is with Claude (but I don't use it in Claude either).

My preference is to have smart models generate a plan with provided source. I wrote (with AI) a simple python tool that'll filter a codebase and let me select all files or just a subset. I then attach that as context and have a smart model with large context (usually Opus, GPT-5.2, and Gemini 3 Pro in parallel), give me their version of a plan. I then take the best parts of each plan, slap it into a single markdown and have Codex execute in a phased manner. I usually specify that the plan should be phased.

I prefer out-of-CLI planning because frankly it doesn't matter how good Codex or Claude Code dive in, they always miss something unless they read every single file and config. And if they do that, they tip over. Doing it out of band with specialized tools, I can ensure they give me a high quality plan that aligns with the code and expectations, in a single shot (much faster).

Then Claude/Codex/Gemini implement the phased plan - either all at once - or stepwise with me testing the app at each stage.

But yeah, it's not a skill issue on your part if you're used to Plan -> Implement within Claude Code. The Experimental /collab feature does this but it's not supported and more experimental than even the experimental settings.

+1 to this. Been using Codex the last few months, and this morning I asked it to plan a change. It gave me generic instructions like 'Check if you're using X' or 'Determine if logic is doing Y' - I was like WTF.

The stages are modelled after a kanban board. So you can have whichever stages you think are important for your LLM development workflow. These are mine:

00: Iterate on requirements with ChatGPT outside of the IDE. Save as a markdown requirements doc in the repo

01: Inside the IDE; Analysis of current codebase based on the scope of the requirements

02: Based on 00 and 01, write the implementation plan. Implement the plan

03: Verification of implementation coverage and testing

04: Implementation summary

05: Manual QA based on generated doc

06: Update global STATE.md and DECISIONS.md that documents the app, and the what and why of every requirement

Every stage has a single .md as output and after the stage is finished the doc is locked. Every stage takes the previous stages' docs as input.

I have a half-finished draft with more details and a benchmark (need to re-run it since a missing dependency interrupted the runs)

https://dilemmaworks.com/implementing-recursive-language-mod...

How about, "tell the agent to write instructions for cloud deployment with a cost estimate"

I'm the same way but I've got the gloomy sense that folks like us are about to be swept aside by the flood if we don't "adapt."

I got invites to seven AI-centered meetings late last week.

Good luck.

There is little to no integration between deterministic IDE features(like refactorings) and LLMs. For example I don't want a statistical tool to rename a method by predicting tokens, I want it to use IDE features and not via another higher abstraction protocol like mpc, I want deeper integration. Sometimes I look at comments in code and think "why can't I have an agent checking if the content of a comment actually reflect the code below?" I feel like we're light years away from a killer integration

I am not sure how those TUI are going to fare against multi providers ones like opencode.

> If "just build it natively" were actually easier, faster, or cheaper at scale, everyone would do just that

Value prop of product quality aside, isn't the AI claim that it helps you be more productive? I would expect that OpenAI would run multiple frontends and that they'd use Codex to do it.

Ie are they using their own AI (I would assume it's semi-vibe-coded) to just get out a new product or using AI to create a new product using the productivity gains to let them produce higher quality?

It baffles me how much the discourse over native apps rarely takes this into consideration.

You reduce development effort by a third, it is ok to debate whether a company so big should invest into a better product anyway but it is pretty clear why they are doing this

I guess it shows how geriatric I am with desktop app development these days, but does no one use Qt anymore? Wasn't the dream for that to be a portable and native platform to write GUI apps? Presumably that could abstract away which bullshit Microsoft framework they came out with this week.

I haven't touched desktop application programming in a very long time and I have no desire to ever do so again after trying to learn raw GTK a million years ago, so I'm admittedly kind of speaking out of my ass here.

React Native is able to build abstractions on top of both Android and iOS that uses native UI. Microsoft even have a package for doing a "React Native" for Windows: https://github.com/microsoft/react-native-windows

It's weird that we don't have a unified "React Native Desktop" that would build upon the react-native-windows package and add similar backends for MacOS and Linux. That way we could be building native apps while keeping the stuff developers like from React.

I have been building Desktop apps with Go + Wails[1]. I happen to know Go, but if you are ai-coding even that is not necessary.

A full fledged app, that does everything I want, is ~ 10MB. I know Tauri+Rust can get it to probably 1 MB. But it is a far cry from these Electron based apps shipping 140MB+ . My app at 10MB does a lot more, has tons of screens.

Yes, it can be vibe coded and it is especially not an excuse these days.

[1] https://wails.io/

Microsoft Teams, Outlook, Slack, Spotify? Cursor? VsCode? I have like 10 copies of Chrome in my machine!

The gap here is that the company has the money and native apps are so clearly better. With an interactive app a company like OpenAI could really tweak the experience for Android and iOS which have different UX philosophies and featuresets in order to give the best experience possible. It's really a no brainer imho.

These companies have BILLIONS of dollars and some of the smartest people in the world and access to bleeding edge AI

There should be no excuses! Figure it out!

This is another common excuse.

You don't need to use microsoft's or apple's or google's shit UI frameworks. E.g. see https://filepilot.tech/

You can just write all the rendering yourself using metal/gl/dx. if you didn't want to write the rendering yourself there are plenty of libraries like skia, flutter's renderer, nanovg, etc

As I outlined in a sibling comment. You can still use React and your JS developers. Just don't ship a whole browser with your app.

May be an app that is as complex as Outlook needs the pixel-perfect tweaking of every little button that they need to ship their own browser for exact version match. But everything else can use *system native browser*. Use Tauri or Wails or many other solutions like these

That said, I do agree on the other comments about TUIs etc. Yes, nobody cares about the right abstractions, not even the companies that literally depend on automating these applications

"native" is used for different things, from "use the platform's default gui toolkit" to "compile to a machine code binary". the former is a bit of a mess, but the latter is strictly better than wrapping a web view and shipping an entire chrome fork to display and interpret it. just write something in qt and forget about native look and feel, and the performance gain will be enough to greatly improve the user experience.

Apple Music isn't native either.

It would be cool if I didn't have to worry about whether I was "in" or "out" of the AI TUI. Right now, I need at least two terminals open: One running my shell, that I use to issue shell commands, and one running Claude, where I can't. It would be nice if it could just be my shell, and when I wanted to invoke claude, I'd just type:

   c Do this programming task for me.

Right in the shell.

I've done way, way more than that, as I'm sure others have too.

This is just bad product management.

TUI is easy to train on, but hard to use for users. Part of the reason it’s easier to have LLMs use a bunch of Unix tools for us is that their text interface is tedious and hard to remember. If you’re a top 5% expert in those tools it doesn’t matter as much I guess but most people aren’t.

Even a full-featured TUI like Claude Code is highly limited compared to a visual UI. Conversation branching, selectively applying edits, flipping between files, all are things visual UI does fine that are extremely tedious in TUI.

Overall it comes down to the fact that people have to use TUI and that’s more important than it being easy to train, and there’s a reason we use websites and not terminals for rich applications these days.

Curios why electron not native?

Wouldn’t native give better performance and more system integration?

Really hoped you'd say Linux next.

While this may be true for casual users, for dev native products like Codex, the desktop experience actually matters a lot. When you are living in the tool for hours, latency, keyboard handling, file system access, and OS-level integration stop being “nice to have” and start affecting real productivity. web or Electron apps are fine for experimentation, but they hit a ceiling fast for serious workflows -- especially if the icp is mostly technical users

More adoption? I don't think so... It feels to me that these models && tools are getting more verbose/consuming more tokens to compensate for a decrease in usage. I know my usage of these tools has fallen off a cliff as it become glaringly obvious they're useful in very limited scopes.

I think most people start off overusing these tools, then they find the few small things that genuinely improve their workflows which tend to be isolated and small tasks.

Moltbot et al, to me, seems like a psyop by these companies to get token consumption back to levels that justify the investments they need. The clock is ticking, they need more money.

I'd put my money on token prices doubling to tripling over the next 12-24 months.

It's not irrelevant for developers neither for users. Tiktok has shown that users deeply care about the experience and they'll flock en-masse to something that has a good experience.

What does Sentry via MCP even mean? You want the LLM to call Sentry itself whenever it encounters an error?

This. Even Linux is nasty. Qt and GTK are both horrible messes to use.

It would be nice if someone made a way to write desktop apps in JavaScript with a consistent, cross-platform modern UI (i.e. swipe to refresh, tabs, beautiful toggle switches, not microscopic check boxes) but without resorting to rendering everything inside a bloated WebKit browser.

"most" people aren't even using AI yet

Of those that are, most are not vibe coding, so an editor is still required at many points

Link to the site?

It would be nice to have an integrated development environment.

I think that's the real enabler. Iterating on some polish details that we know the shape of but is hard to get the nuances right.

Google also has aistudio.google.com which is Lovable competitor and its free for unlimited use. That seems to work so much better than gemini CLI even on similar tasks

Deep integrations are hard and the AI companies are just winging it when it comes to eating their own dog food. Their apps are bare bones, somewhat flaky, and overall not that impressive from a UX point of view.

It's very obvious that while their AI teams are top notch, their product teams are very middle of the road. Including design. Even though they apparently engaged Jony Ive, I can't actually see his 'touch' on anything they have. You'd expect them to have a much higher level of ambition when it comes to their own products. But they seem stuck getting even the basics shipping. I use Chat GPT for Desktop. It's alright but it seems to have stagnated a bit and it has some annoying bugs and flakiness. Random shit seems to break regularly with releases as well.

Another good example of the lack of vision/product management is the #1 and oldest use case for LLMs since day 1: generating text. You'd expect somebody to maybe have come up with the genius idea of "eh, hmm, you know, I wonder if we can do better than pasting blobs of markdown rendered HTML to and/from a word processor from a f**ing sidebar".

Where's the ultimate agentic word processor? The ultimate writing experience? It's not there. Chat GPT is hopelessly clumsy doing even the most basic things in word processors. It can't restructure your document. It can't insert/delete bits of text. It can't use any of the formatting and styling controls. It can't do that in the UI. It can't do that at the file level. It's just not very good at doing anything more than generating bits of text with very basic markdown styling that you might copy paste to your word processor. It won't match the styling you have. Last time I checked Gemini in Google docs it was equally useless. I don't have MS Office but I haven't heard anything that suggests it is better.

For whatever reason, this has not been a priority (bad product management?) or they simply don't have the creativity to see the rather obvious integration issues in front of them.

Yes making those is a lot of work and requires a bit of planning. But wasn't the point of agentic coding that that's now easy? Apparently not.

I wouldn't get used to opencode personally. I can imagine OpenAI/Antropic explictly banning 3rd party clients from using their subscription plans. (I believe Antropic has already done this)

On a side note, the company I work for (RemObjects, not speaking on their behalf) has a value ethos specifically about using the native UI layers, and encouraging our customers to do the same. (We make dev tools, a compiler supporting six languages (C#, Java, Go, etc) plus IDEs.)

Our IDE does this: common code / logic, then a native macOS layer and a WPF layer. Yes, it takes a little more work (less than you'd think!) but we think it is the right way to do it.

And what I hope is that AI will let people do the same -- lower the cost and effort to do things like this. If Electron was used because it was a cheap way to get cross-platform apps out, AI should now be the same layer, the same intermediate 'get stuff done' layer, but done better. And I don't think this prevents doing things faster because AI can work in parallel. Instead of one agent to update the frontend, you have two to update both frontends, you know?

We're building an AI agent, btw. Initially targeting Delphi, which is a third party's product we try to support and provide modern solutions for. We'll be adding support for our own toolchains too.

What I fear is that people will apply AI at the wrong level. That they'll produce the same things, but faster: not the same things, but better (and faster.)

It's about consistency - you want to build an app that looks and functions the same on all platforms as much as possible. Regardless of if you are hand-coding or vibe-coding 3 entirely separate software stacks, getting everything consistent is going to be a challenge and subtle inconsistencies will sneak in.

It comes back to fundamental programming guidelines like DRY (Don't Repeat Yourself) - if you have three separate implementations in different languages for everything, changes will be come harder and you will move slower. These golden guidelines still stand in a vibe-code world.

> You reduce development effort by a third

Sorry to nitpick, but this should be "by three" or "by two thirds", right?

One reason why I personally never bothered is the licensing of some of its important parts, which is a choice of either GPL or commercial. Which is fair, but too bothersome for some use-cases (e.g. mobile apps which are inherently GPL-unfriendly). Electron and the likes are typically MIT/BSD/etc licensed.

I built my Block Editor (Notion-style) in Qt C++ and QML[1].

[1] https://get-notes.com

There are such implementations for React Native: https://reactnative.dev/docs/out-of-tree-platforms

Wails is pretty good. I wrote a couple of apps but since I'm on macOS I ended up rewriting them in SwiftUI and that's much lighter of course since it uses all native APIs.

I am in love with wails. having python and JS background with no go experience. I pm'ed Ai agents to create a fairly complex desktop app for my own use. it is day and night in terms of performance compared to lightest electron app.

Wow Wails looks interesting! Hadn't heard of it before.

it'll be the least important thing to do

That'll work great until your first customer from a CJK or RTL language writes in, "Hey, how come I can't type in your app?", or the blind user writes in "Hey how come your app is completely blank?" then you'll be right in the middle of the "Find Out" phase

These strategies are fine for toy apps but you cannot ship a production app to millions or even thousands of people without these basics.

“Render yourself with GPU APIs” has all the same problems with a11y, compatibility, inconsistent behaviour that electron has - the only one it might fix is performance and plenty of apps have messed that one up too

It's essentially asking application developers to wipe ass for OS developers like Microsoft. It's applaudible when you do it, understandable when you don't.

Even though OpenAI has a lot of cash to burn, they're not in a good position now and getting butchered by Anthropic and possibly Gemini later.

If any major player in this AI field has the power to do it's probably Google. But again, they've done the Flutter part, and the result is somewhat mixed.

At the end of the day, it's only HN people and a fraction of Redditors who care. Electron is tolerated by the silent majority. Nice native or local-first alternatives are often separate, niche value propositions when developers can squeeze themselves in over-saturated markets. There's a long way before the AI stuff loses novelty and becomes saturated.

They dont allocate thinking tokens but they do change model behavior.

Same. And indeed, it's here. The genie is not going back into the bottle, so we have to learn how to live in this new world.

Eric Schmidt has spoken a lot recently about how it's one of the biggest advances in human history and it's hard to disagree with him, even if some aspects make me anxious.

This might actually be another area language servers shine. As I understand it, the TS Language Server can do renames. Ergo, we ought to be able to have the LLM ask the lang server to do the rename instead of trying to do it itself. That'd be easier than trying to integrate with each IDE individually. (Whereby "IDE" seems to be synonymous with "VSCode" lately...)

There are cross platform GUI toolkits out there so while I am in team web for lots of reasons, generally it’s because web apps are faster and cheaper to iterate.

>You reduce development effort by a third

Done by the company which sells software which is supposed to reduce it tenfold?

That might be true (although you do add in the mess of web frameworks), but I strongly believe that resource usage must factor into these calculations too. It's a net negative to end users if you can develop an app a bit quicker but require the end users to have multiple more times RAM, CPU, etc.

Qt is still used, but I think part of the reason it is less used is that C++ isn't always the right language anymore for building GUI application.

That’s actually why we're working on Slint (https://slint.dev): It's a cross-platform native UI toolkit where the UI layer is decoupled from the application language, so you can use Rust, JavaScript, Python, etc. for the logic depending on what fits the project better.

And GTK4 is even very usable from Rust too. It’s not a bad development experience, but these companies probably find 100 webdevs for every system programmer.

The real question is how much better are native apps compared to Electron apps.

Yes that would take much disk space, but it takes 50Mb or 500Mb isn't noticeable for most users. Same goes for memory, there is a gain for sure but unless you open your system monitor you wouldn't know.

So even if it's something the company could afford, is it even worth it?

Also it's not just about cost but opportunity cost. If a feature takes longer to implement natively compared to Electron, that can cause costly delays.

Qt means C++. I'll take Typescript over C++ for a GUI task any day.

Qt is also pretty memory-hungry; maybe rich declarative (QML) skinnable adaptable UIs with full a11y support, etc just require some RAM no matter what. And it also looks a wee bit "non-native" to purists, except on Windows, where the art of uniform native look is lost.

Also, if you ever plan extensions / plugin support, you already basically have it built-in.

Yes, a Qt-based program may be wonderfully responsive. But an Electron-based app can be wonderfully responsive, too. And both can feel sluggish, even on great hardware. It all depends on a right architecture, on not doing any (not even "guaranteed fast") I/O in the GUI thread, mostly. This takes a bit of skill and, most importantly, consideration; both are in short supply, as usual.

The biggest problem with Electron apps is their size. Tauri, which relies on the system-provided web view component, is the reasonable way.

Qt is still pretty good, but it's dated in comparison to newer frameworks like Flutter and React Native. No hot reloading of changes, manual widget management vs. React where you just re-define the whole UI every frame and it handles changes magically, no single source of truth for state, etc.

I've looked into Tauri and Wails, but they don't seem realistic for a cross-platform app with wide distribution across multiple platforms and platform versions.

One of Electron's main selling points is that you control the browser version. Anything that relies on the system web view (like Tauri and Wails) will either force you to aggressively drop support for out-of-date OS versions, or constantly check caniuse.com and ship polyfills like you're writing a normal web app. It also forces you to test CSS that touches form controls or window chrome on every supported major version of every browser, which is just a huge pain. And you'll inevitably run into bugs with the native -> web glue that you wouldn't hit with Electron.

It is absolutely wasteful to ship a copy of Chrome with every desktop app, but Tauri/Wails don't seem like viable alternatives at the moment. As far as I can tell, there aren't really any popular commercial apps using them, so I imagine others have come to the same conclusion.

React Native desktop on Linux isn't a thing, the GTK backend is abandonned.

So if you want a multiplatform desktop app also supporting Linux, React Native isn't going to cut it.

Interesting. Does the Wails renderer support the full set of what Webkit/Chromium supports?

> the company has the money

It's not about money. It's not a tradeoff in cost vs quality - it's a tradeoff in development speed. Shipping N separate native versions requires more development time for any given change: you must implement everything (at least every UI) N times, which drastically increases the design & planning & coordination required vs just building and shipping one implementation.

Do you want to move slower to get "native feel", or do you want to ship fast and get N times as much feature dev done? In a competitive race while the new features are flowing, development speed always wins.

Once feature development settles down, polish starts to matter more and the slowdown becomes less important, and then you can refocus.

How is File Pilot for accessibility and for all of the little niceties like native scrolling, clipboard interaction, drag and drop, and so on? My impression is that the creator is has expertly focused on most/all of these details, but I don't have Windows to test.

I insist on good UI as well, and, as a web developer, have spent many hours hand rolling web components that use <canvas>. The most complicated one is a spreadsheet/data grid component that can handle millions of rows, basically a reproduction of Google Sheets tailored to my app's needs. I insist on not bloating the front-end package with a whole graph of dependencies. I enjoy my NIH syndrome. So I know quality when I see it (File Pilot). But I also know how tedious reinventing the wheel is, and there are certain corners that I regularly cut. For example there's no way a blind user could use my spreadsheet-based web app (https://github.com/glideapps/glide-data-grid is better than me in this aspect, but there's no way I'm bringing in a million dependencies just to use someone else's attempt to reinvent the wheel and get stuck with all of their compromises).

The answer to your original question about why these billion dollar companies don't create artisanal software is pretty straightforward and bleak, I imagine. But there are a few actually good reasons not to take the artisanal path.

Customers simply don't care. I don't recall a single complain about RAM or disk usage of my Electron-based app to be reported in the past 10 years.

You will be outcompeted if you waste your time reinventing the wheel and optimizing for stuff that doesn't matter. There is some market for highly optimized apps like e.g. Sublime Text, but you can clearly see that the companies behind them are struggling.

I'd love to see some opensource projects actually do a good job of this. Its a lot of work, especially if you want:

- Good cross platform support (missing in filepilot)

- Want applications to feel native everywhere. For example, all the obscure keyboard shortcuts for moving around a text input box on mac and windows should work. iOS and Android should use their native keyboards. IME needs to work. Etc

- Accessibility support for people who are blind and low vision. (Screen readers, font scaling, etc)

- Ergonomic language bindings

Hitting these features is more or less a requirement if you want to unseat electron.

I think this would be a wonderful project for a person or a small, dedicated team to take on. Its easier than it ever used to be thanks to improvements in font rendering, cross platform graphics libraries (like webgpu, vulcan, etc) and improvements in layout engines (Clay). And how much users have dropped their standards for UI consistency ever since electron got popular and microsoft gave up having a consistent UI toolkit in windows.

There are a few examples of teams doing this in house (eg Zed). But we need a good opensource project.

> You don't need to use microsoft's or apple's or google's shit UI frameworks. E.g. see https://filepilot.tech/

That's only for Windows though, it seems? Maybe the whole "just write all the rendering yourself using metal/gl/dx" is slightly harder than you think.

They’re all iterating products really fast. This Codex is already different than the last Codex app. This is all disposable software until the landscape settles.

Oh right, I forgot, "native" just means "good". So if an app is bad, it can't be native, and if an electron app is actually good its because they're doing crazy optimizations that aren't feasible for mortal souls so don't even think about it. This is the "Hackers News Law of Application Nativeness".

Most AI agents have a 'bash mode' and, you can use Warp terminal which is terminal first, but easy to activate the AI from the terminal. For example, if you mangle a jq command, it will use AI to suggest the right way to do it.

Given how much money they have, and the reach they're attempting to achieve, is it really asking too much that they hire native development teams? It's not like an application of this scale requires an army of engineers.

isn't that what Simon Willison's `llm` does?

edit: [link](https://github.com/simonw/llm)

all the examples for visual UI, are tasks which already are (or soon be) done by the agent, not human. hence not needed.

I suspect that final(*) UI is much more similar to TUI: being kind of conversational (human <> AI). Current GUIs provided by your bank/etc are much less effective/useful for us, comparing to conversation way: 'show/do me sth which I just need'. Not to mention (lack of) walled garden effect, and attention grabbing not in the user interest (popups, self-promo, nagging). Also if taking into account age factor. Also that we do not have to learn, yet another GUI (teach a new bank to your mom ;). So at least 4 distinct and important advantages for TUI.

My bet: TUI/conversation win (*).

*) there will be some UI where graphical information density is important (air controller?) especially in time critical environments. yet even there I suspect it's more like conversation with dynamic image/report/graph generated on the go. Not the UI per se.

We should be able to make it available for Linux very soon as well!

I use headless mode (-p) and keep my named shell histories as journals (so no curses/TUI or GUI). But session management or branching could improve at the tool level and allow seamless integration with completion tools, which could be a simple fast AI looking at recent sessions or even be visual, say for navigating and extending a particular complex branch of a past session. It is not too hard to work with such shell-based flows within Emacs for me, but it would be nice if there was some standardization effort on the tool fronts and some additional care for future automation. I dont want my AI clicking buttons if it can be precise instead. And I certainly want multithreading. I think of AI more as an OS; it needs a shell more than it needs windows at this point in time.

When you're a trillion dollar company that burns more coal than Bangladesh in order to harness a hyperintelligent Machine God to serve your whims, you don't have the resources to maintain native clients for three separate targets.

This is a really nice tool! (Also, I love the old school animated GIFs in the site's footer.)

Ty for the tip on context7 mcp btw

Ok. You do you. I'll stick with the models that understand what latest version of a framework means.

I find that the case too. For more complex things my future ask would be something that perhaps formalized verification/testing into the AI dev cycle? My confidence in not needing to see code is directly proportional in my level of comfort in test coverage (even if quite high level UI/integration mechanisms rather than 1 != 0 unit stuff)

How would a person interpret the latest version of flowbite?

I suspect making the models more verbose is also a source of inflation. You’d expect an advanced model to nail down the problem succinctly, rather than spawning a swarm of agents that brute force something resembling an answer. Biggest scam ever.

The experience in the claude app is fine.

That’s what React Native is. But JavaScript is the problem.

Qt is not a horrible mess to use, the problem is just people don't bother to learn any tech stack outside web. It's so obvious that this is the issue to anybody who actually does native development.

Can you explain why GTK is a mess?

I can't share it yet. It's cool but it's definitely not ready for prime time. Thank you for asking.

How dare you want your IDE to be integrated!

Absolutely. Things you would ask your designer if they weren't on the drip at $80/hr and maxed out with "other projects".

Should just use javafx or swing. Take a leaf out of intellij which while it as it's own performance problems (although not from the fact of the ui framework) has a fantastic ui across Mac / windows / nix

So where is all this amazing software that you and others built with AI?

All I see is hype blog posts and pre-IPO marketing by AI companies, not much being shipped though.

-p

Their goal is to ship as fast as possible b/c they don't care about what you care about. Their objective is to gather as much data as possible & electron is good enough for that.

He literally says why electron in his comment that you are replying to

VSCode is arguably one of the most if not the most popular code editor these days…

> Just tell it to use your gcp/aws account using the cli

Please don't.

People burning through their tokens allowance on Claude Code is one thing.

People having their agent unknowingly provisioning thousands of $ of cloud resources is something completely different.

Perhaps if he was able to get Claude Code to do what he wanted in less time, and with a better experience, then maybe that's not a skill he (or the rest of us) want to develop.

TBH, "use a package manager, don't specify versions manually unless necessary, don't edit package files manually" is an instructions that most agents still need to be given explicitly. They love manually editing package.json / cargo.toml / pyproject.toml / what have you, and using whatever version is given in their training data. They still don't have an intuition for which files should be manually written and which files should be generated by a command.

I am using GPT-5.2 Codex with reasoning set to high via OpenCode and Codex and when I ask it to fix an E2E test it tells me that it fixed it and prints a command I can run to test the changes, instead of checking whether it fixed the test and looping until it did. This is just one example of how lazy/stupid the model is. It _is_ a skill issue, on the model's part.

Really? I frankly don’t know anyone who’s not on Linux. If you do any AI/ML you basically find yourself on a Linux box eventually. Perhaps I live in a bubble.

Recursive Language Models by Alex Zhang/MIT

Meaning sentry exposes an MCP layer with a tool call layer and tool registry. In this case, the layer is provided by Sentry. Native would mean if calling specific Sentry APIs is provided as a specific integration path depending on the context. Atleast thats how I categorize.

> I'd put my money on token prices doubling to tripling over the next 12-24 months.

Chinese open weights models make this completely infeasible.

> multiple more times RAM, CPU, etc.

Part of this (especially the CPU) is teams under-optimizing their Electron apps. See the multi-X speedup examples when they look into it and move hot code to C et al.

How come if I download code from GitHub, rename some stuff, and republish it under another license I’m a bad guy, but if I ask ChatGFY to do it for me I’m a 10x Chad? … someone is gonna figure that part out in court. I remember what code SCO used to make hay, and I know what side the MPAA, RIAA, Google, and NVidia Are gonna be on at the end of the day.

Replacing workers with things you can’t beat, sue, intimidate, or cajole? Someone is gonna do something to make that not cool in MBA land. I think if one of my employees LL-MessedUp something, and I were upset, watching that same person stealing my money haplessly turn to an LLM for help might land me in jail.

I kinda love LLMs, I’ve always struggled to write emails without calling people names. There’s some clear coding tooling utility. But some of this current hype wave is insano-balls from a business perspective. Pets.com X here’s-my-ssh-keys. Just wild.

It might be a cynical take, but I don't think there is a single person in these companies that cares about end user resource usage. They might care if the target were less tech savvy people that are likely to have some laptop barely holding up with just Win11. But for a developer with a MacBook, what is one more electron window?

Come on GUI apps are not systems programming, what's with this title inflation.

I think the comparison between native apps and Electron apps is conflating two things:

- Native apps integrate well with the native OS look and feel and native OS features. I'd say it's nice to have, but not a must have, especially considering that the same app can run on multiple platforms.

- Native apps use much less RAM than Electron apps. I believe this one is a real issue for many users. Running Slack, Figma, Linear, Spotify, Discord, Obsidian, and others at the same time consumes a lot of memory for no good reason.

Which makes me wonder: Is there anything that could removed from Electron to make it lighter, similar to what Qt does?

Yes, but most people don’t do that. Companies are optimizing to ship features fast, not trying to min/max resource usage when majority don’t care.

This is a new era where “if it works more or less well, ux/dx is fine, let’s ship it” has more moat than ever. Everything else is really secondary.

Also, modern native UIs became looking garbage on desktops / laptops, where you usually want a high information density.

Just look at this TreeView in WinUI2 (w/ fluent design) vs a TreeView in the good old event viewer. It just wastes SO MUCH space!

https://f003.backblazeb2.com/file/sharexxx/ShareX/2026/02/mm...

And imo it's just so much easier to write a webapp, than fiddle with WinUI. Of course you can still build on MFC or Win32, but meh.

It just uses the system web view, so it depends on the user's platform/version.

If the web-interface of a website can serve same HTML to all browsers, these UI can as well. I don't think we have IE6 level incompatibility these days. I have no idea what specific incompatibility you are talking about. I am writing my 4th desktop app since early 2025.

But sure, you could have some specific need, but I find it hard to believe for these simple apps.

I was getting this in my Claude code app, it seems clear to me that they didn’t want users to do that anymore and it was deprecated. https://i.redd.it/jvemmk1wdndg1.jpeg

One of the biggest advances in human history, and yet the owners of the technology with access to an unlimited number of "agents" using frontier models still can't release a desktop chat application without using Electron to bring in several hundred mb of bloat for displaying text. Someone's going to have to explain this one to me because the math is not mathing.

> You don't casually give up massive abstraction wins

Value is value, and levers are levers, regardless of the resources you have or the difficulty of the problem you're solving.

If they can save effort with Electron and put that effort into things their research says users care about more, everyone wins.

Cross platform GUIs might does have the same of support and distributed knowledge as HTML/CSS/JS. If that vendor goes away or the oss maintainers go a different direction, now you have an unsupported GUI platform.

Agree, another improvement i'd like along the lines or renames is lsp suggestions for method names, enums, functions, etc The llm should be able to autocomplete given lsp available symbols, this way it would avoid far less hallucinated methods

Especially given how fast things progress, timeline and performance are a tradeoff where I'd say swaying things in favour of the latter is not per definition net positive.

It absolutely is noticeable the moment you have to run several of these electron “apps” at once.

I have a MacBook with 16GB of RAM and I routinely run out of memory from just having Slack, Discord, Cursor, Figma, Spotify and a couple of Firefox tabs open. I went back to listening to mp3s with a native app to have enough memory to run Docker containers for my dev server.

Come on, I could listen to music, program, chat on IRC or Skype, do graphic design, etc. with 512MB of DDR2 back in 2006, and now you couldn’t run a single one of those Electron apps with that amount of memory. How can a billion dollar corporation doing music streaming not have the resources to make a native app, but the Songbird team could do it for free back in 2006?

I’ve shipped cross platform native UIs by myself. It’s not that hard, and with skyrocketing RAM prices, users might be coming back to 8GB laptops. There’s no justification for a big corporation not to have a native app other than developer negligence.

I don't get this HN worship of Qt. Have you ever used Qt apps on macOS? They don't feel native at all. They feel sort-of native-emulating in the same way wxWidgets apps on macOS feel: they use native controls but all the little details including design language are off.

I'm not saying this is a huge problem for me even if it bothers me personally. But if you're here on HN advocating native over Electron, then it seems logical to me that you would care about being truly native instead of merely "using native controls while feeling off".

This is even before getting to the point that Qt isn't truly native. They just draw controls in a style that looks native, they don't actually use native controls. wxWidgets uses native controls but they don't behave better despite that.

That's false, see QML hot reload[1].

[1] https://www.qt.io/blog/speed-up-qt-development-with-qml-hot-...

How can C++ not be the "right" language? It seems to meet all the requirements for event-driven GUIs - event handlers are function callbacks after all...

We're actually working on a native open source cross-platform UI toolkit called Slint that’s trying to do exactly that. https://slint.dev

> Customers simply don't care. I don't recall a single complain about RAM or disk usage of my Electron-based app to be reported in the past 10 years.

Nothing is worse than reading something like this. A good software developer cares. It’s wrong to assume customers don't care simply because they don't know what's going on under the hood. Considering the downsides and the resulting side effects (latency, more CPU and RAM consumption, fans spinning etc.), they definitely do care. For example, Microsoft has been using React components in their UI, thinking customers wouldn’t care, but as we have been seeing lately, they do care.

I don’t complain about Electron because I didn’t install the app if I could avoid it.

Yeah that's why startups often pick iOS first, get product-market fit, and then do Android. The fallacy that abstractions tout is that Android and iOS are the same.

They are not.

A good iOS app is not 1:1 equivalent to what a good Android app would be for the same goal. Treating them as such just gives users a lowest common denominator product.

People absolutely care, but the issue is that no single company/app is really responsible. It's the tragedy of the commons, but for users RAM. No one electron app uses all the RAM, but just a couple are enough to make a common 16GB machine slow down massively.

That just means your feedback system is trash if it fails to surface such an obvious and common pain point in user experience. Tough that's an extremely common state of feedback systems. But also, the general computer knowledge isn't that high for every end user to connect some sluggishness in another app to your app wasting ram and causing disk swaps, that eliminates a lot of end user complaints

> reinventing the wheel

what exactly are you inventing by using a framework "invented" decades ago and used by countless apps in all those years?

They don’t care, or they don’t know? What they do know is their computer that’s only 5 years old goes to shit with only a few apps open. Time for a new laptop.

Thanks for contributing to the obsolescence cycle.

So, this certainly was a valid argument. But it seems to me that the whole value proposition behind these agentic AI coding tools is to be able to move beyond this. Are we very far from being able to define some Figmas and technical specs and have Codex generate the UIs in 5 different stacks? If that isn't a reality in the near future, then why should we buy AI Tools?

> I don't recall a single complain about RAM or disk usage of my Electron-based app to be reported in the past 10 years.

When was the last time complaining about this did anything?

File pilot is extremely good in my experience, literally the only issue is it doesn't display the sync status on icons in a Dropbox folder.

Not seeing complaints doesn't mean they don't exist. Not to mention ui latency that is common in electron apps that is just a low-level constant annoyance.

Non-native UI widgets, non-native runtime, non-native language

quality takes time. I'm still in stealth

And they're pretty much the only example of an embedded browser architecture actually performing tolerably and integrating well with the native environment.

Oh wow, nice. Does it remember context from run to run?

Agree, especially if they're not given access to the web, or if they're not strongly prompted to use the web to gather context. It's tough to judge models and harnesses by pure feel until you understand their proclivities.

Surely it varies a lot and everyone is in an industry bubble to some extent, but from my experience in some non-tech industries (healthcare, manufacturing), Linux workstations were nonexistent and working with the Linux servers was more a sign of an ops role. People who wrote code for a living didn't touch them directly. Last StackOverflow survey [1] puts it at something like 50% use Windows at work, 30% Mac, 20-40% Linux (breakdown of WSL and Ubuntu as categories seems confusing, maybe the raw data is better).

[1] https://survey.stackoverflow.co/2025/technology/#1-computer-...

still a skill issue, not a codex issue. sure, this line of critique is also one levied by tech bros who want to transfer your company's balance sheet from salaries to ai-SaaS(-ery), but in what world does that automatically make the tech fraudulent or even deficient? and since when is not wanting to develop a skill a reasonable substitute for anything? if my doctor decided they didn't want to keep up on medical advances, i would find a different doctor. but yet somehow finding fault with an ai because it can't read your mind and, in response to that adversity, refusing to introspect at all about why that might be and blaming it on the technology is a reasonable critique? somehow we have magically discovered a technology to manufacture cognition from nothing more than the intricate weaving of silicon, dopants, et al., and the takeaway is that it sucks because it is too slow, doesn't get everything exactly right, etc.? and the craziest part is that the more time you spend with it, the better intuition you get for getting whatever it is you want out of it. but, yeah... let's lend even more of an ear to the head-in-sand crowd-- that's where the real thought leaders are. you don't have to be an ai techno-utopian maximalist to see the profound worthiness and promise of the technology; these things are manifestly self-evident.

i refuse to defend the 5.2-codex models. They are awful.

This is also on the cloud providers for not giving us good tools to manage costs.

Yes, you live in a bubble.

Talking LLMs off a ledge is a skill we will all need going forward.

> it's a tradeoff in development speed

Doesn't this get thrown out the window now that everyone claims you can be 10x, 50x, 100x more productive with AI? Hell people were claiming you can ask a bunch of AI agents to build a browser from scratch, so surely the dev speed argument no longer applies.

https://reactnative.dev/docs/out-of-tree-platforms says otherwise

React Native Skia allegedly runs on Linux too

>Customers simply don't care. I don't recall a single complain about RAM or disk usage of my Electron-based app to be reported in the past 10 years.

I see complains about RAM and slugginess against Slack and countless others Electron apps every fucking day, same as with Adobe forcing web rendered UI parts in Photoshop, and other such cases. Forums are full of them, colleagues always complain about it.

I have complained about literally every Electron based app I have ever used. How would you know there are no complaints?

I mean, every cross-platform commercial DAW manages to do it? Bitwig, Renoise, Reaper, even VCV.

The proof that rendering is not _that_ hard because the flutter team did it when they switched off skia (although technically they still use skia for text rendering, I'll admit that text rendering and layout is hard)

But Electron doesn’t hit that bar even

Java swing is way underrated despite being very complex. It baffles me why this just sort of withered on the vine.

(I was a swing developer for several years)

Still good enough for the majority of the users.

Even with SublimeText, most popular IDE is VSCode, most popular interface design tool Figma, all popular chat platforms and so on are all electron based. If people were desperate for faster platforms they'll be migrating to them.

You won't see it because it's mostly personal software for personal computers.

I've got a medical doctor handwriting decipherer, a board game simulator that takes a PDF of the rulebooks as input and an accounting/budgeting software that can interface with my bank via email because my bank doesn't have an API.

None of that is of any use to you. If you happen to need a similar software, it will be easier for you to ask your own AI to make a custom one for you rather than adapt the ones I had my AI make for me.

Under the circumstances, I would feel bad shipping anything. My users would be legitimately better off just vibe coding their own versions.

I can’t tell if this word salad is sarcasm or genuine.

There is a guy on twitter documenting his progress with moltbot/openclaw: https://x.com/Austen/status/2018371289468072219. Apparently he has already registered his bot for an LLC so he can make money w/ it.

I work at OpenAI, and I get the concern. From our side, this was a careful tradeoff: Electron lets us iterate faster and makes it possible to bring the Codex app to Windows and Linux very soon. That doesn’t mean performance or UX don’t matter—we’re actively paying attention to both.

Would genuinely love your thoughts if you try it. Early users have been surprised by how native it feels!

Going cross platform doesn’t sound the main reason (or I hope not). For a company that size, is it really hard to hire specialised small team?! It would be a good show case for their Codex too

Sure, that's fine. I wrote my comment for the people who don't get angry at an AI agents after using them for the first time within five hours of their release. For those who aren't interested in portending doom for OpenAI. (I have elaborate setups for Codex/Claude btw, there's no fanboying in this space.)

Some things aren't common sense yet so I'm trying my part to make them so.

Codex runs in a stupidly tight sandbox and because of that it refuses to run anything.

But using the same model through pi, for example, it's super smart because pi just doesn't have ANY safeguards :D

@dworks: Good insights. Thanks!

If you add a dialectic between Opus 4.5 and GPT 5.2 (not the Codex variant), your workflow - which I use as well, albeit slightly differently [1] - may work even better.

This dialectic also has the happy side-effect of being fairly token efficient.

IME, Claude Code employs much better CLI tooling+sandboxing when implementing while GPT 5.2 does excellent multifaceted critique even in complex situations.

[1]

- spec requirement / iterate spec until dialectic is exhausted, then markdown

- plan / iterate plan until dialectic is exhausted, then markdown

- implement / curl-test + manual test / code review until dialectic is exhausted

- update previous repo context checkpoint (plus README.md and AGENTS.md) in markdown

Non codex gpt 5.2 is much better than codex gpt 5.2 for me. It does everything better.

What do weights have to do with how much it costs to run inference? Inference is heavily subsidized, the economics of it don't make any sense.

Anthropic and OpenAI could open source their models and it wouldn't make it any cheaper to run those models.. You still need $500k in GPUs and a boatload of electricity to serve like 3 concurrent sessions at a decent tok/ps.

There are no open source models, Chinese or otherwise that are going to be able to be run profitably and give you productivity gains comparable to a foundation model. No matter what, running LLMs is expensive and the capex required per tok/ps is only increasing, and the models are only getting more compute intensive.

The hardware market literally has to crash for this to make any sense from a profitability standpoint, and I don't see that happening, therefor prices have to go up. You can't just lose billions year after year forever. None of this makes sense to me. This is simple math but everyone is literally delusional atm.

I'm so confused. Sentry is a native client crash reporting tool. What does this have to do with MCP or the LLM itself? Do you mean when interpreting the crash data?

That's like a luxury lumber company stuffing its showrooms full of ikea furniture.

After every time I read "save effort with Electron", I go back to Win2K VM and poke around things and realize how faster everything is than M4 Max, just because value is value, and Electron saves some effort.

Claude, at least, already supports LSP servers though. https://code.claude.com/docs/en/plugins-reference#lsp-server...

Exactly. If AI really worked, they would've released a native app. And it wouldn't take much to also get a Windows and a Linux native app, wouldn't it?

Apparently, the Codex app itself is proof that AI is not that good at doing what people think it does.

Thx for the correction. Changed a couple weeks ago. https://decodeclaude.com/ultrathink-deprecated/

There's another benefit - you don't have to keep refactoring to keep up with "progress"!

I mean the initial release of Qt predates JavaScript by a few months and CSS by more than a year. GTK is only younger by a few years and both remain actively maintained.

Argument feels more like FUD than something rooted in factual reality.

On that note, I could also comfortably fit a couple of chat windows (skype) on a 17'' CRT (1024x768) back in those days. It's not just the "browser-based resource hog" bit that sucks - non-touch UIs have generally become way less space-efficient.

That's a third party paid addon. Hardly a fair comparison.

They don’t look native on Windows, either.

This is not because of Qt - it is due to some (most) Qt developers not caring enough. I created my Qt app feel native both on macOS and Windows[1]. It did require a lot of tuning - but those are things I'll reuse across other apps.

[1] https://get-notes.com/

C++ works, but compared to other languages it's often no longer the most productive choice for UI work. Modern UI code is mostly glue and state management, where fast iteration matters more than squeezing out maximum performance. And when performance does matter, there are also newer, safer languages.

For teams comfortable with C++ or with existing C++ libraries to integrate, it can of course still be a strong choice, just not the preferred one for most current teams.

React Native Skia seems abandoned. But maybe this will make React Native on Linux viable

https://github.com/gtkx-org/gtkx

Of course they complain about them, but those are the users, not the purchasers.

How is a fact that someone did something proof that it isn’t hard?

React Native Skia last commit is three years ago.

yep, you're right to call that.

[delayed]

There are complaints and then users keep using these super popular and bloated apps. Techies make it seem like bloat is a capital sin but it isn't.

It gets pretty close.

Which parts in particular do you think electron misses from this list?

Fair, I think I'm certainly in the minority. Especially now more then ever with an increasing amount of non-technical people exploring vibe coding, 'good enough' really is good enough for most users

> Even with SublimeText, most popular IDE is VSCode

What a weird comparison, one is free, another one is a premium app, of course a lot of people prefer some suffering over paying money

How are Adobe and Slack/Salesforce doing?

Are they hurting for customers?

Even if we assume a developer is actually 10x more productive with AI, if you triple their workload by having them build 3 native apps now you're only 3.33x more productive.

Some guy on Twitter selling an AI coding boot camp is an interesting example. Also it's literally just a post of him looking for a real developer to review his vibe coded bot???

Your mistaking supply-side path dependent outcomes that produce a lack of consumer choice with consumer preference. No consumer prefers slow, bloated, non-native software, but they're stuck with what they can get.

I disagree. There is a tier of people who can't vibe code what you've vibe coded, but also might not trust your app (especially the bank one). There is still a real gap here to be filled by professional work or fakers.

The web sucked all the oxygen out of the room.

From the suggestions it looks like sarcasm, but you never can tell these days

the problem is that getting this out in this shape the week after Cursor made $100M ARR would have made sense

getting it out now suggests there are structural problems about how decisions get made and code gets shipped—and the "iterate faster" line feels misplaced

adding another external model/agent is exactly what I have been planning as the next step. in fact i already paste the implementation and test summaries into chatgpt, and it is extremely helpful in hardening requirements, making them more extensible, or picking up gaps between the implementations and the initial specs. it would be very useful to have this in the workflow itself, rather than the coding agent reviewing its own work - there is a sense that it is getting tunnel visioned.

i agree that CC seems like a better harness, but I think GPT is a better model. So I will keep it all inside the Codex VSCode plugin workflow.

Your AI can’t make a UI for 3 platforms? Seems pretty worthless.

common sense has the misfortune of being less "common" than we would all like it to be. because some breathless hucksters are overpromising and underdelivering in the present, we may as well throw out the baby, the bath water, and the bath tub itself! who even wants computers to think like humans and automate jobs that no human would want to do? don't you appreciate the self-worth that comes from menial labor? i don't even get why we use tractors to farm when we have perfectly good beasts of burden to do the same labor!

Sentry provides a MCP server where your LLM can call the Sentry MCP and answer questions like number of crashes in the last X days etc.

The LLM gets the data from Sentry using Sentry MCP.

They presumably use codex to build this. LLMs output is non-deterministic. Harder to keep the same logic across.

Would I love to see swiftui on macos, wpf/winui om windows, whatever qt hell it is on linux? Sure. But it is what it is.

I am glad the codex-cli is rust and native. Because claude code and opencode are not: react, solidjs and what have you for a tree layer.

—

Then again, if codex builds codex, let it cook and port if AI is great. Otherwise, it’s claim chowder

Yup, I find it very counter-intuitive that this would be the case, but I switched today and I can already see a massive difference.

Could you please pass on feedback to the team that the git diff view is very hard to read for red/green colourblind users like myself? Colour scheme like GitUp.co is very readable for me.

After using CC in VSCode a bit, I find it makes liberal use of Pylance, both proactively (in-thread) as well as during the lifecycle (guessing via hooks). It’s almost annoying how, and I’d like to figure out how to get it to use repos lint rules.

Of course you do!

Microsoft makes a new UI framework every couple of years, liquid glass from apple and gnome has a new gtk version every so often.

god damn, I've never though Qt app could be this smooth and looking nice.

Open weights means that the current prices for inference of Chinese models are indicative of their cost to run because.

https://openrouter.ai/moonshotai/kimi-k2.5

It's a fantasy to believe that every single one of these 8 providers is serving at incredibly subsidized dumping prices 50% below cost and once that runs out suddenly you'll pay double for 1M of tokens for this model. It's incredibly competitive with Sonnet 4.5 for coding at 20% of the token price.

I encourage you to become more familiar with the market and stop overextrapolating purely based on rumored OpenAI numbers.

It is hard because this product will likely be obsolete next year based on how quickly AI is changing and evolving. Speed is king when you're on the frontier

Feelings are information with just as much, or more, value as biased intellectualizing.

Ask Linus Torvalds.

I use Google's antigravity so I personally have no problem w/ electron applications. At the end of the day UI performance is not a bottleneck for me.

I'll take this as my sign to give Pi a shot then :D Edit: I don't want to speak too son, but this Pi thing is really growing on me so far… Thank you!

Nice blog, this post is interesting: https://decodeclaude.com/compaction-deep-dive/ Didn't know about Microcompaction!

But desktop C++ isn't difficult or slow to write...

It seems odd to me that the software world has gone in the direction of "quick to write - slow to run". It should be the other way around. Things of quality (eg. paintings by Renaissance masters) took time to create, despite being quick to observe.

It also seems proven that releasing software quickly ("fast iteration") doesn't lead to quality - see how many releases of the YouTube app or Netflix there are on iOS or Android; if speedy releases are important, it is valuing rush to production over quality, much like a processed food version of edible content.

In a world that is also facing energy issues, sluggish and inefficient performance should be shunned, not welcomed?

I suppose this mentality is endemic, and why we see a raft of cruddy slow software these days, where upcoming developers ("current teams") no longer value performance over ease of their job. It can only get worse if the "it's good enough" mentality persists. It's quite sad.

No, you would be ten times as productive. You would ship three different apps 3,3 times faster than you previously only shipped one.

The productivity comparison must be made between how long it takes to ship a certain amount of stuff.

It really was Oracle’s fault – they neglected deployment for too long. Deploying Java applications was simply too painful, and neither JLink nor JPackage existed.

McDonald’s isn’t hurting for customers either. Doesn’t mean their food is anything a chef ought to aspire to.

the people that USE the software the most are not the people BUYING the software. it’s why all enterprise software has trash UX.

do you think i as a software engineer like using Jira? Outlook? etc? Heck even the trendy stuff is broken. Anthropic took took 6 months to fix a flickering claude code. -_-

There is competition for Figma. Sketch.

There's plenty of competition for VSCode too.

Don't forget that these Electron apps outcompeted native apps. Figma and VSCode were underdogs to native apps at one point. This is why your supply side argument doesn't make any sense.

What does the bootcamp have to do w/ anything? He is using AI slop to make money, that's all that matters in a socio-economic system wherein everyone & everything must make profits to persist. Edit: found another example from coinbase: https://x.com/0xEricBrown/status/2018082458143699035.

Edit: I'm not going to keep addressing your comment if you keep editing it. You asked for an example & I found two very easily. I am certain there are many others so at this point the onus is on you to figure out what exactly it is you are actually arguing.

Professionals are doing what I am doing, only inside companies. They make custom software that solves ultra-specific problems of that one company.

I don't quite understand the obsession with shipping fancy enterprise b2b saas solutions. That was the correct paradigm for back when developing custom code was expensive. Now it is cheap.

Why pay for Salesforce when you only use 1% of Salesforce's features? Just vibe code the 1% of features that you actually need, plus some custom parts to handle some cursed bespoke business logic that would be a pain in the ass to do in Salesforce anyway.

Yes, exactly. "Just hire a small team and build native apps for another OS" is the recipe for taking a year to deliver instead of a month

i have absolutely no idea whatsoever what this means

I'm not making any guesses, I happen to know for a fact what it costs. Please go try to sell inference and compete on price. You actually have no clue what you're talking about. I knew when I sent that response I was going to get "but Kimi!"

Wait until you figure out you can just say "create a skill to do..." and it'll just do it, write it in the right place and tell you to /reload

Or "create an extension to..." and it'll write the whole-ass extension and install it :D

If you're a big context/compaction fan and want another fun fact, did you know that instead of doing regular compaction (prompting the agent to summarize the conversation in a particular way and starting the new conversation with that), Codex passes around a compressed, encrypted object that supposedly preserves the latent space of the previous conversation in the new conversation.

https://openai.com/index/unrolling-the-codex-agent-loop/ https://platform.openai.com/docs/guides/conversation-state#c...

Context management is the new frontier for these labs.

Aaaaand that is why we, as end users get machines which are sluggish, because literally every. Single. Application is taking this attitude.

Shock horror, the waste adds up, and it adds up extremely quickly.

I'm loving it

Let me know when Stacy from HR vibe codes her own salesforce alternative, sounds very cool!

The part that takes time in UI isn’t wiring up components, it’s the small changes like something is a pixel to the right or that gap is two pixels wide. Changing those in a C++ project means recompiling and that adds up to significant overhead over a day of polishing the UI. If C++ was able to get builds out in less than a second, this wouldn’t be an issue. People value performance in their own tools more than the tools of their customer.

McDonald's is renown for speed of service, a bit ironic to compare that to slow apps

Neither it means that McDonald's should aspire to be a chef

Yes that was my point.

> There's plenty of competition for VSCode too.

But there isn't, not if you include all the extensions and remember the price

Your first example is just a twitter post of a guy asking for a developer to review his vibe coded bot. Nothing shipped.

The second example is twitter post of a crypto bro asking people to build something using his crypto API. Nothing shipped.

Literally nothing shipped, just twitter posts of people selling a coding bootcamp and crypto.

It really is insane how far it's gone. All of the subsidization and free usage is deeply anticompetitive, and it is only a profitable decision if they can recoup all the losses. It's either a bubble and everything will crash, or within a few years once the supplier market settles, they will eventually start engaging in cartel-like behavior and ratchet up the price level to turn on the profits.

The numbers you stated sound off ($500k capex + electricity per 3 concurrent requests?). Especially now that the frontier has moved to ultra sparse MoE architectures. I’ve also read a couple of commodity inference providers claiming that their unit economics are profitable.

Okay, so you are claiming "every single one of those 8 providers, along with all others who don't serve openrouter but are at similar price points, are subsidizing by more than 50%".

That's an incredibly bold claim that would need quite a bit of evidence, and just waving "$500k in gpus" isn't it. Especially when individuals are reporting more than enough tps at native int4 with <$80k setups, without any of the scaling benefits that commercial inference providers have.

I don't really care about memory or how much of it is taken up by the editor. I have enough memory for the work that I do & UI performance would make no difference to my workflow.

In modern Qt you don't write UI in C++ anymore - you do that in QML. It is far simpler to create amazing pixel perfect UIs with drooling-inducing animations in QML. I wrote a blog post that talks a bit about this[1].

[1] https://rubymamistvalove.com/block-editor

Maybe 40 years ago.

Sure, aspiring to mediocrity at a cost to others is a choice.

Not relevant point though. I was answering to this "I don't recall a single complain about RAM or disk usage of my Electron-based app to be reported in the past 10 years", I wasn't arguing that such apps don't make money.

You should make a note & revisit this in a few days to figure out whether your assessment was correct or not. I've already wasted enough time here so good luck.

So an Electron app won. Seems like Electron wasn't a hinderance.

You're delusional, I didn't even include the labor the install and run the damn thing. More than 500k

Imagine thinking that $80k setups to run Kimi and serve a single user session is evidence that inference providers are running at cost, or even close to it. Or that this fact is some sort of proof that token pricing will come down. All you one-shotted llm dependents said the same thing about Deepseek.

I know you need to cope because your competency is 1:1 correlated to the quality and quantity of tokens you can afford, so have fun with your Think for me SaaS while you can afford it. You have no clue the amount of engineering that goes into provide inference at scale. I wasn't even including the cost of labor.

Sure, you can ignore that it was a hindrance just like you ignored ignored the previous point.

It directly disproves this wild claim

> You still need $500k in GPUs and a boatload of electricity to serve like 3 concurrent sessions at a decent tok/ps.

as being patent bullshit, after which the burden is squarely on you to back up the remainder of your claims.

Like how you ignored my point too?

If it was a hindrance, why did it win?

Seems clear to me that Electron's higher RAM usage did not affect adoption. Instead, Electron's ability to write once and ship in any platform is what allowed VSCode to win.

> Like how you ignored my point too?

No, differently

> If it was a hindrance, why did it win?

Because reality is not as primitive as you portray it to be, you can have hindrances and boosts with the overall positive even winning effect? That shouldn't be that hard!

> Seems clear to me that Electron's higher RAM usage did not affect adoption.

Again, it only seems clear because you ignore all the dirt, including basic things (like here, it's not just ram, is disk use, startup speed, but also like before with competition) and strangely don't consider many factors.

> Instead, Electron's ability to write once and ship in any platform is what allowed VSCode to win.

So nothing to do with it using the most popular web stack, meaning the largest pool of potential contributors to the editor or extensions??? What about other cross platform frameworks that also allowed that??? (and of course it's not any platform, just 3 desktop ones where VSc runs)

  So nothing to do with it using the most popular web stack, meaning the largest pool of potential contributors to the editor or extensions??? What about other cross platform frameworks that also allowed that??? (and of course it's not any platform, just 3 desktop ones where VSc runs)

I'm not even sure what you're arguing at this point.

Are you arguing that Electron helped VSCode win or what? Because Electron being able to use a popular web stack is also a benefit.

What is your point?