Hacker Newsnew | past | comments | ask | show | jobs | submit | pheewma's commentslogin

They have this already. Both cmux and supacode use libghostty in the backend.


It depends on the subject. For classes/subjects that are very terminology-heavy, with a lot of dependencies between topics, memorizing things is a pre-requisite to the "deeper" understanding, especially under time-constraint of a semester or whatever. I think most people would agree that it's ideal to "naturally" explore a subject in order to get a deeper understanding of it, but one can't always be expected to 1. Be able to deploy that "curiosity" for all subjects at any time and 2. Be able to adequately achieve competence in a subject within the given timeframe


Codex was running a 2x usage promotion from around the time when Claude introduced rate limiting during peak hours, until May 31st. The various relevant subreddits were (more) insufferable: just 1000 posts per day to the tune of "Just switched the codex! So much more usage!" only to have that tone flip immediately after the promo ran out.


Just to add to this: Marimo notebooks are set up in a way that ends up being easier/more-token-efficient for agents to work in. They're just python files with some custom formatting to be read by their front-end UI, sort of like cell notation in (# %%) but with a lot of QoL bells and whistles built in. Jupyter notebooks in comparison, are mostly json and are pretty messy to work with as far as git diffs goes, which is annoying. VS-Code's Github Copilot actually had pretty good Jupyter integration, letting you refer to specific cells, and allowed the agent to run individual cells and read their output before writing subsequent cells etc etc. I suspect there are vs-code specific tool calls for jupyter notebooks being used that I haven't bothered trying to replicate with claude.

A month or two ago, Marimo released Marimo Pair, which works about as well as that. It appears to be a skill that just points claude code (perhaps other harnesses, haven't tried) at whatever localhost the Marimo UI is worked off of, and tells it the structure of a Marimo notebook (very necessary since I imagine there isn't as much training data on them compared to Jupyter etc). https://marimo.io/blog/marimo-pair


Not to mention the fact that marimo-pair also supports non-Claude models.


Craig mentioned near the end of the keynote that compute intensive things (like image generation) will have rate limits that can be increased bundled with their iCloud + plans. I imagine any request that gets routed to their cloud compute will be subject to limits as well. He positioned it as a value-add to their existing subscription but I suppose that can change.


There are also downstream consequences of ordering tests aside from cost; not all tests are harmless. As an example, regular screening for prostate cancer isn't recommended as much. Partially because it is often so slow-growing that people often die of other causes before the cancer even begins to cancer, and because the definitive test is a biopsy which is somewhat invasive. Rates of complications are relatively low, but it becomes a cost-benefit consideration (again, irrespective of cost) of if those risks are worth catching something that you may not even want to bother treating.


Sure, of course you would make practical decisions about what kinds of tests to administer, and not proactively administer the tests that have significant negative side effects.

For the other point, personally I don’t really buy the argument of “it’s better not to know you have cancer X, because it might end up being low impact.” If we had excellent regular screening, yes detection of low impact cancers would become a lot more common, but I think people’s perception of them would change too. If it became a common thing for cancers to be detected, but the detection could reliably say “this is likely low impact, we should just keep an eye on it but not treat it”, this would be a lot less scary. It would become normalized IMO. Cancer diagnoses are partly so scary right now because we’re often mostly catching cancers that have progressed and are causing symptoms, so the public perception is rightly “cancer diagnosis = very scary.”


> Sure, of course you would make practical decisions about what kinds of tests to administer, and not proactively administer the tests that have significant negative side effects.

The harm is from investigating the screening test result and not the test itself.

> If it became a common thing for cancers to be detected, but the detection could reliably say “this is likely low impact, we should just keep an eye on it but not treat it”, this would be a lot less scary

This is already the case for some like prostate cancer and certain lymphomas.

> Cancer diagnoses are partly so scary right now because we’re often mostly catching cancers that have progressed and are causing symptoms

The most aggressive cancers are also the least likely ones to be diagnosed by screening due to growth rates, screening intervals and diagnostic test limitations.


The harm can be from the initial screening too. The lifetime risk for complications from routine colonoscopy is around 1.6%. The lifetime risk of colo-rectal cancer is 4-5%.

So already before investigating the result, there's a very real consideration whether increasing the number of colonoscopies is likely to be a net benefit.


Colonoscopy is confusing because it is both screening and diagnostic/investigating.

Most if not all of the complication/risk (perforation and major bleeding being the ones of note) is from the polypectomy / biopsy part of the colonoscopy.


The path to being able to say "low impact, don't worry" will be quite rocky and possibly involve a lot of painful treatment for patients. If you have a very different detection surface, you would not initially know what is all low impact, for example.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: