News for hackers. Stuff that matters.

dchu17

Sorry, I may be misunderstanding the question.

The way this works is that it stores workstreams and session state in a local SQLite DB, and links each ctx session to the exact local Claude Code and/or Codex raw session log it came from (also stored locally).

What do you mean by prompt caching?

that's interesting, I hadn't at this point but this sounds potentially useful

Show HN: Ctx – a /resume that works across Claude Code and Codex

https://github.com/dchu917/ctx

ctx is a local SQLite-backed skill for Claude Code and Codex that stores context as a persistent workstream that can be continued across agent sessions. Each workstream can contain multiple sessions, notes, decisions, todos, and resume packs. It essentially functions as a /resume that can work across coding agents.Here is a video of how it works:...

( Read More... | 28 comments | 3 points | on HN )
Gave this a run and it was pretty intuitive. Good work!
Yes this is a major problem I thought about. The makeshift solution here was to redact the “identifying information” on the press release. Even then, I benchmarked that GPT-5 could still match it back to the right TIKR around 53% of the time. It does not seem to be able to recall the price of the stock in my benchmark, but to be honest I’m not entirely sure how trustworthy this benchmark is and I may need to come up with a few more clever solutions to validate.

One solution could be to get experts to write similar press releases so that the text itself is out of distribution or if an actual quant firm has internal models, they can just make sure that there is a cutoff date to the pre-training data.

I'm curious, when you ran a quant fund, what was your approach?

Yes we know of a few. Honestly, it was pretty hard to even find a good catalyst calendar for this space.

I'll give it a read to learn more. Thanks for the note!

That's interesting. I am curious, what kind of analyses did you work with on the molecule and drug itself? Was it like mostly reading papers/patents or did your team do anything experimental?
Our initial goal with this project actually wasn't trying to get an edge in terms of better evaluating information, but rather, we wanted to see if an LLM can perform similarly to a human analyst at a lower latency. The latency for the market to react to catalysts is actually surprisingly high in biotech (at least in some cases) compared to other domains so there may be some edge there.

Appreciate the comment though! I generally agree with your sentiment!

Show HN: BioTradingArena – Benchmark for LLMs to predict biotech stock movements

https://www.biotradingarena.com/hn

Hi HN,My friend and I have been experimenting with using LLMs to reason about biotech stocks. Unlike many other sectors, Biotech trading is largely event-driven: FDA decisions, clinical trial readouts, safety updates, or changes in trial design can cause a stock to 3x in a single day (https://www.biotradingarena.com/cases/MDGL_2023-12-14_Resmet...).Interpreting these ‘catalysts,’ which comes in...

( Read More... | 15 comments | on HN )
Hi, thanks for the comment! Just wanted to respond to some of comments here:

>> First, your business model isn't really clear, as what you've described so far sounds more like a research project than a go-to-market premise.

This is not really a core component of our business but more so was just something cool that I built and wanted to share!

>> Computational pathology is a crowded market, and the main players all have two things in common: access to huge numbers of labeled whole-slide images, and workflows designed to handle such images. Without the former, your project sounds like a non-starter, and given the latter, the idea you've pitched doesn't seem like an advantage. Notably, some of the existing models even have open weights (e.g. Prov-GigaPath, CTransPath).

We have partnerships with a few labs to get access to a large amount of WSIs, both H&E and IHC, but our core business really isn't building workflow tools for pathologists at the moment.

>> Second, you've talked about using this approach to make diagnoses, but it's not clear exactly how this would be pitched as a market solution. The range of possible diagnoses is almost unlimited, so a useful model would need training data for everything (not possible). My understanding is that foundation models solve this problem by focusing on one or a few diagnoses in a restricted scope, e.g. prostate cancer in prostate core biopsies.

I agree with you in that I don’t necessarily think this is really a market solution at the current state (it isn't even close to accurate enough), but I think that the beauty of this solution is the general-purpose nature of it in that it can work not only across tissue types, but also different pathology tasks like IHC scoring along with cancer sub typing. The value of foundation models is in the fact that tasks can generalize. For example, part of what made this super interesting to me was the fact that the general purpose foundation models like GPT 5 are able to even perform this super niche task! Obviously there are path-specific foundation models too that have their own ViT backbones, but it is pretty incredible that GPT 5 and Claude 4.5 can perform at this level already.

Yes to the best of my knowledge, most FDA-approved solutions are point solutions, but I am not yet convinced this is the best way to deploy solutions in the long-term. For example, there will always be rare diseases where there isn't enough of a market for there to be a specialized solution for and in those cases, general-purpose models that can generalize to some degree may be crucial.

Yeah I think one of the things that would be interesting is to see how well it generalizes across tasks. It seems like the existence of pathology foundation models means there is certainly a degree of generalizability (at least across tissues) but I am not too sure yet about generalizability across different modalities (there are some cool biomarker-prediction models though)
Thought about this too. I think there are two broad LLM capabilities here that are kind of currently tangled up in this eval:

1. Can an LLM navigate a slide effectively (i.e find all relevant regions of interest)? 2. Given a region of interest, can an LLM make the correct assessment?

I need to come up with a better test here in general but yep I'm thinking about this

I've been thinking a bit more about better ways to build the tooling around it, I don't know much about video compression to be fully transparent but will read up on it.

I have been running into some problems with memory management here as each later frame needs to have a degree of context of the previous frames... (currently I just do something simple like pass in the previous frame and the first reference frame into context) maybe I can look into video compression and see if there is any inspiration there

Nope I haven't, I can take a look and see if I can fit it in
I think so. It feels like there is more to be squeezed from just better prompts but was going to play around with fine-tuning Qwen3
Nope, I just did some prompt engineering on ootb models. I thought about doing some fine-tuning on like Qwen but think that there is still more performance to be squeezed out with just prompts here.
> What's the performance of the models trained specifically on this task, and random guessing, compared to the expert pathologist?

I should probably first clarify here, the disease classification tasks are about subtyping the type of cancer (i.e classifying a case as invasive ductal carcinoma of the breast) rather than just binary malignant/benign classification so random guessing is much more difficult and makes this model performance more impressive.

> Would also be curious how the LLM compares to this and other approaches.

There aren't a lot of public general purpose pathology benchmarks. There are some like (https://github.com/sinai-computational-pathology/SSL_tile_be...) but focus on just binary benign/malignant classification tasks and binary biomarker detection tasks.

I am currently working on self-hosting the available open-source models.

> this seems like the sort of task where being right 90% of the time is not good enough, so even if the LLM beats other approaches, it still needs to close the gap to human performance

Yep, your intuition is right here, and actually the expectation is probably closer to mid-high 90%, especially for FDA approval (and most AI tools position as co-pilots at the moment). There is obviously a long way to go, but what I find about interesting about this approach is that it allows LLMs to generalize across (1) a variety of tissue types and (2) pathology tasks such as IHC H-score scoring.

Show HN: Cancer diagnosis makes for an interesting RL environment for LLMs

Hey HN, this is David from Aluna (S24). We work with diagnostic labs to build datasets and evals for oncology tasks.I wanted to share a simple RL environment I built that gave frontier LLMs a set of tools that lets it zoom and pan across a digitized pathology slide to find the relevant regions to make a diagnosis. Here are some videos of the LLM performing diagnosis on a few...

( Read More... | 20 comments | on HN )

Show HN: Postgres Platform for Global Replication and Sharding

https://fortress.build

Hi HN! This is David and Will from Fortress. Last month, we launched Fortress as a Postgres platform targeted at multi-tenant SaaS companies (https://news.ycombinator.com/item?id=41426998). Since then, we’ve pivoted our messaging to focus more on ‘globally distributed’ Postgres for developers.Over the past month, we learned that for us, the multi-tenant messaging didn’t resonate as much as we...

( Read More... | no comments | 2 points | on HN )
Yep! Just felt it wasn't for us. We originally built it for e-commerce as just a better way to get product data than through affiliate APIs but felt like most of the market pull weren't in things we were interested in.
We really like Nile and it is definitely a company we look towards for inspiration!

While we hope to share similar DXs, our fundamental difference is that we are focused on a BYOC-first platform instead of a serverless Postgres platform. We realized that developers who were doing strict tenant-isolation were only doing it as a means to meet their customer's demands to close deals. Often, database isolation is not the only requirement; there are requirements on which cloud a database can be hosted on, or even asks to host the database on a private cloud. For these reasons, we thought that the BYOC angle gave us more flexibility to solve these problems as well as providing a easy-to-use interface.

Thanks for the criticism!

We still definitely need to work on our language to best communicate this; we'll work on keeping it more concise and straightforward to best highlight what we offer.

This is a great question :)

We initially targeted startups at the moment that they are moving from a 3rd party DBaaS to databases on their own cloud. However, we just realized this was super tough to time. We experimented a bit with enterprise actually too but many of them already have huge systems in place.

We are shifting our focus to SaaS developers. We know that often, thinking about data isolation is a factor on SaaS developers' minds. We want to build a platform where they can have an incredibly simple DX while also trusting that their customer data will be isolated.

This looks super interesting! Will check it out. Thanks for letting us know!
Thanks for the feedback!

We've seen most SaaS companies use some sort of tenant_id column and this is definitely the most popular method that developers currently use.

We want to provide a few things for SaaS developers. For one, many SaaS companies will face the need to create a completely new isolated database instance and may need to deploy this instance on a specific cloud (we know that Azure is really popular for healthcare).

Further, we want to spare the dev-experience of using WHERE clauses and/or setting up RLS. We aim to provide a seamless DX that abstracts over where the tenant data actually is and provide a unified platform that developers can trust to provide native isolation. We are pretty early but want to hear whether these resonate with you!

Thanks for letting us know, fixing it now!

Launch HN: Fortress (YC S24) – Database platform for multi-tenant SaaS

Hi HN! We're Will, John, and David from Fortress (https://fortress.build). We're building a Bring Your Own Cloud (BYOC) backend as a service for multi-tenant SaaS apps, simplifying tenant data isolation across both shared and dedicated database instances.There’s a demo here: https://www.loom.com/share/761cac3090ba4db8b2ce9d713873333a?..., as well as a walkthrough of our Python SDK:...

( Read More... | 82 comments | 58 points | on HN )