Live data from Hacker News

The Codex App

openai.com

401–410 of 671 posts

Re: The Codex App

#401

Earlier quoted context omitted.

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.

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…

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.

Re: The Codex App

#402

Earlier quoted context omitted.

What features are they missing that a native app would allow for? No-one outside of a small sliver of the tech community cares if an app is built with web tech Electron also opens up easier porting to Linux which almost certainly wouldn't happen if companies insist on native only

Users care about performance and jank, it’s just that they’ve been successfully forced to shut-up-and-deal-with-it. They’re not involved in purchasing or feedback, and the people that are don’t use it enough to care, or just don’t care. Users who complain about it may as well shout into the void for how much companies take note, but hey, at least we got an ai button now! Atlassian products are a great example of this…

I find outside of specific use cases the performance and jank are down to the developers and not whether it's native or not

Obsidian is an Electron app which is pretty much universally loved. We can both give single examples

Re: The Codex App

#403
post #321

Somewhat underwhelmed. I consider agents to be a sidetrack. The key insight from the Recursive Language Models paper is that requirements, implementation plans, and other types of core information should not be part of context but exist as immutable objects that can be referenced as a source of truth. In practice this just means creating an .md file per stage (spec, analysis, implementation plan, implementation summa…

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 it…

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...

Re: The Codex App

#404
post #366
post #321

Somewhat underwhelmed. I consider agents to be a sidetrack. The key insight from the Recursive Language Models paper is that requirements, implementation plans, and other types of core information should not be part of context but exist as immutable objects that can be referenced as a source of truth. In practice this just means creating an .md file per stage (spec, analysis, implementation plan, implementation summa…

Which paper?

Recursive Language Models by Alex Zhang/MIT

Re: The Codex App

#405
post #284

People's mileage may vary, but in my instance, this was so bad that I actually got angry while trying to use it. It's slow and stupid. It does not do proper research. It does not follow instructions. It randomly decides to stop being agentic, and instead just dumps the code for me to paste. It has the extremely annoying habit of just doing stuff without understanding what I meant, making a mess, then claiming everyth…

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

Re: The Codex App

#406
post #398

Earlier quoted context omitted.

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…

> 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.

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.

Re: The Codex App

#407
post #398

Earlier quoted context omitted.

> 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.

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 otherwis…

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.

Re: The Codex App

#408

Earlier quoted context omitted.

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.

> 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.

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

Re: The Codex App

#409

Earlier quoted context omitted.

Is the integration with Sentry native or via MCP ?

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

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.

Re: The Codex App

#410
post #407

Earlier quoted context omitted.

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 otherwis…

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…

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!"
Post reply on HN