19 karma · joined November 27, 2023
I think in the end it all boils down to a trust issue on the big labs
The problem with this argument is that assumes the world is static. When trains were invented, they polluted a LOT. Technology evolved. Looking backwards, the amount of value unlocked by them outweighed by order of magnitude the short term pollution they generated. Inefficient in the short term. Generation changing over the longer horizon. Extend the timeframe of your argument. Do you think it holds 20 years from now when we have more efficient algorithms and energy generation technologies? I don’t think so.
Our goal with UltraContext is to build the best open source context infrastructure so you and your team can ship at inference speed. Whether your teammates are human or not.
Happy to answer any questions!
Not trying to lock you in, I just wanna make it useful
This is my personal go-to transcriber, and btw it works very well inside Clawdbot/Moltbot
Let me know if you guys like it and/or have any ideas on how can it be improved.
For sensitive use cases, I'm exploring a few options: client-side encryption, data anonymization, or a local-first deployment where context never leaves your infra. Not there yet, but it's on the roadmap.
What's your use case? Happy to chat about what privacy guarantees you'd need.
On scaling: appends don't create versions, only updates and deletes do. So for your 10k message conversations, uc.get() is O(n) reads. Standard database scaling. The versioning overhead only kicks in when you're actually mutating context, and even then we handle the optimization so you don't have to think about it.
On version history: each agent run doesn't create a version. Versions are created when you update or delete a message. So if your agent appends 1000 messages across 1000 runs, that's just 1000 appends. No version explosion.
Time travel (rewinding to a specific point) is also O(n). This was my personal main bottleneck when deploying B2C agents, so the API is heavily optimized for it.
For your 5 accounts x 5 conversations setup: you'd have 25 separate contexts. Each scales independently. Parse through them however you want, filter by metadata, retrieve by timestamp or index.
For single-agent flows, parallel works fine.
The goal is to focus on the core building blocks that enable more sophisticated use cases. Compression, compaction, and offloading strategies should be straightforward to build on top of UC rather than baked in at the core layer.
On UltraContext, you'll do it like this:
// Shared context all agents read/write to
await uc.append(sharedCtx, { agent: 'planner', content: '...' })
await uc.append(sharedCtx, { agent: 'researcher', content: '...' })
// Or fork into separate branches per agent
const branch = await uc.create({ from: sharedCtx, at: 5 })
Schema-free, so you can tag messages by agent, track provenance in metadata, and branch/merge however you want. Full history on everything.