I pretty much only use o1 for more rigorous tasks (coding/math). Eg the other day I gave it the tax rates for my area and used it to explore different tax scenarios
That's true, but I'd assume the server would like to double-check that the hashes are valid (for robustness / consistency)... That's something my little experiment doesn't do, obviously.
Great writeup. To add an example, I personally use JSON for most of my work, but have found myself using XML for certain AI use cases that require annotating an original text.
For example, if I wanted an AI to help me highlight to the user where in a body of text I mentioned AI, I might have it return something like:
<text>Great writeup. To add an example, I personally use JSON for most of my work, but have found myself using XML for certain <ai-mention>AI</ai-mention> use cases that require annotating an original text with segments.</text>
SelectIQ works with clinical trial sites and their referring physicians to automate the patient referral process, massively speeding up enrollment.
Bringing new drugs to market is primarily rate limited on the speed of clinical trials, which are themselves bottlenecked by patient recruitment. 80% of clinical trials don’t meet their recruitment timeline, and being behind on recruitment can cost pharma companies millions of dollars per day.
I recently evaluated Dagster, Prefect, and Flyte for a data pipeliney workflow and ended up going with Temporal.
The shared feature between Temporal and those three is the workflow orchestration piece. All 3 can manage a dependency graph of jobs, handle retries, start from checkpoints, etc.
At a high level the big reason they’re different is Temporal is entirely focused on the orchestration piece, and the others are much more focused on the data piece, which comes out in a lot of the different features. Temporal has SDKs in most languages, and has a queuing system that allows you to run different workflows or even activities (tasks within a workflow) in different workers, manage concurrency, etc. You can write a parent workflow that orchestrates sub-workflows that could live in 5 other services. It’s just really composable and fits much more nicely into the critical path of your app.
Prefect is probably the closest of your list to temporal, in that it’s less opinionated than others about the workflows being “data oriented”, but it’s still only in python, and it deosn't have queueing. In short this means that your workflows are kinda supposed to run in one box running python somewhere. Temporal will let you define a 10 part workflow where two parts run on a python service running with a GPU, and the remaining parts are running in the same node.js process as your main server.
Dagster’s feature set is even more focused on data-workflows, as your workflows are meant to produce data “assets” which can be materialized/cached, etc.
They’re pretty much all designed for a data engineering team to manage many individual pipelines that are external from your application code, whereas temporal is designed to be a system that manages workflow complexity for code that (more often) runs in your application.
This is a pretty good way to go bankrupt when you have a real health emergency
EDIT: I doubt OP is reading this but I would highly recommend they get insurance before giving birth...sure, they won't cover your at home birth, but they will cover your hospital stay if you end up having potentially fatal complications
I didn't say faster build times weren't faster. I said people whose entire focus is on speed will speed-read the cliff notes instead of fully reading the original Shakespeare. There's a difference.
Congrats on the launch, looks like a great product.
Out of curiosity - the demo on the site suggests the local first latency is like 10-40 ms. I would think reading/writing to SQLite locally would be on the order of 1ms or less. Why is that?
Quite right, the latency should be low single figure ms. There is actually a slight bug in how that latency is calculated on the demo and includes an extra render tick, I was digging into it earlier but didn't get a chance to push a fix yet.
Just merged my first simple PR with sweep. This is going to be so useful for the kind of things that would take 5 minutes to do but get procrastinated for weeks because you just can't find the time to context switch for it.
I just had it fix some outdated copy in a part of the UI. The nice thing is I didn't have to find the file myself, I just described what was wrong like I would a junior eng and let it find and fix it. Worked on the first try!
That's exactly the use case we want. We also let you specify the file path (ex: "main.py").
We noticed that Sweep's search works way better if there are comments, because the comments match up really well with the search queries (language <-> language is easier than language <-> code)
We do end up doing a GPT based rewrite. The initial description is really valuable too though, and we want to keep that throughout the workflow. It's kind of similar to a spelling correction or query intent system. If it's high confidence you can override their query, but ideally you use the original one too.
I didn't mention this point, but we actually do that during the modification. We ask the LLM to extract the necessary subcontext from the main context. It doesn't increase the costs much, but it does help performance because the unnecessary context is stripped away.
