HN user
alex.jacobs08@gmail.com
it does seem to be moving in that direction. There were really specific things (large, complex json outputs) that gemini-2.5 flash was basically the only model that seemed capable of reliably for a long period. gpt-5+ has covered the usecase for us now pretty well but still evals slightly below what 2.5 could do
they say the model(s) found and exploited a zero day
its not always that simple. dropping in a new model is trivial, but highly specific workflows may rely on specific _invisible_ aspects of a model. when that model gets deprecated, the workflow needs to be rebuilt/re-tuned to work with a different model.
google's inability or unwillingness to provide stable timelines for model deprecation makes it risky to build complex workflows using their models
you'll need the Max Plus plan for that, buddy
Yes I understand airports are complex. So you have a computer and a human, and they work together.
how do you think it works today? some guy with binoculars?
pydantic-ai
whats wrong with .env files?
same--this is exactly why I built this
LLMs absolutely do not have access to the same tools unless they're explicitly given access to them. Running on a computer means nothing.
It sounds like you don't like LLMs! In that case, you may be more interested in our REST Api. All the same functions, but designed for edge computing, where dependency bloat is a real issue https://tinyfn.io/edge
Humans are also bad at math! So we created calculators. LLMs should have the same access to tools to give them the best opportunity to succeed
They're building a moat with data. They're building their own datasets of trusted sources, using their own teams of physicians and researchers. They've got hundreds of thousands of physicians asking millions of questions everyday. None of the labs have this sort of data coming in or this sort of focus on such a valuable niche
saying they aren't pioneering is very different than saying they aren't a major player in the space. There're only like 5-7 players with a foundational model that they can serve at scale. xAI is one of them
This is an interesting read, and while I support being nice to every_thing_ in principle. Most of the research into this actually shows that being mean yeilds better results
This looks pretty cool. I keep seeing people (an am myself) using claude code for more an more _non-dev_ work. Managing different aspects of life, work, etc. Anthropic has built the best harness right now. Building out the UI makes sense to get genpop adoption
fizsh sounds really cool, but the last commit was 7+ years ago. do you run into any issues? https://github.com/zsh-users/fizsh
not sure there are any models yet that you can get the quality out you need to do this and run on your mbp
This is a wildly out of touch thing to say
correct afaik :(
the main issue with pgvectorscale is that it's not available in RDS :(
This probably doesn't count as an "app" in terms of what you're looking for, but was a fun little project
https://alexjacobs08.github.io/lobsters-graph/
(i built this in search of a lobste.rs invite if anyone willing and able sees this--email in my bio :)
This looks awesome. ai-sdk is an excellent library. excited to see it proliferating
Standard benchmarks (like BEIR/MS MARCO) are great, but they are likely already in distribution for foundation models training sets, and crucially, they lack the complex, structured metadata needed to test real-world filtering scenarios (e.g., "Find docs from region X, between dates Y and Z, with tag A").
datasetFactory is an orchestrated LLM pipeline that turns a single natural language prompt into a (potentially) massive, structured evaluation dataset.
it's an odd choice. I'd be curious why they picked that. it's not the cheapest, most expensive, best, or worst.
It does have a relatively large context window, and ime is very good at format adherence
well said! we demo'd milvus (or zilliz i should say,) and while we didn't ultimately go with it--it seems like a great option
Author is a human :). Performance and semantic accuracy are both important. The point about pre-filtering _youre still searching millions of vectors_ is important because once you apply a filter you can no longer use your vector index. And doing a full scan on millions of vectors is quite expensive
pgvectorscale is not available in RDS so this wasnt a great solution for us! but it does likely solve many of the problems with vanilla pgvector (what this post was about)
this is at the expense of precision/recall though isn't it?
i discuss that specifically!
The problem is that index builds are memory-intensive operations, and Postgres doesn’t have a great way to throttle them. You’re essentially asking your production database to allocate multiple (possibly dozens) gigabytes of RAM for an operation that might take hours, while continuing to serve queries.
You end up with strategies like:
Write to a staging table, build the index offline, then swap it in (but now you have a window where searches miss new data)
Maintain two indexes and write to both (double the memory, double the update cost)
Build indexes on replicas and promote them
Accept eventual consistency (users upload documents that aren’t searchable for N minutes)
Provision significantly more RAM than your “working set” would suggest
short answer--maybe not that _hard_, but it adds a lot of complexity to manage when you're trying to offer real-time search. most vector DB solutions offer this ootb. This post is meant to just point out the tradeoffs with pgvector (that most posts seem to skip over)
guess it depends on your scale? for some, 10+ GB of RAM being consumed on an index build is > 25% of the DB's RAM. apply that same proportion to your setup and maybe it'll make more sense