cmsparks

7 ms·

1.
by cmsparks 4mo ago
538 was actually pretty accurate! They had a good article about how their predictions were much better than you'd expect, but obviously I can't link it anymore because ABC removed it.
2.
by cmsparks 4mo ago
No idea. ABC bought it and slowly has been shutting down the parts of it. They got rid of the projects page, then laid off all the folks working on it after the election, and now have gotten rid of all of the articles. Fortunately the Githu
3.
ABC News has taken all FiveThirtyEight articles offline(twitter.com)
390 points by cmsparks 4mo ago|171 comments
4.
by cmsparks 4mo ago
If my read of this is correct, this means that Agent SDK orchestrator tools don't get subsidized usage. This seems to intentionally be trying to kill the other (much better IMO) interactive Claude Code desktop apps...
5.
Portability Problems: Syncing Coding Agent State Across Machines(omnara.com)
1 points by cmsparks 5mo ago|0 comments
6.
by cmsparks 6mo ago
That would prolly work for simple sites, but you still need the dedicated scraping service with a browser to render sites that are more complex (i.e. SPAs)
7.
We cut Node.js' memory in half (so you don't have to)(blog.platformatic.dev)
1 points by cmsparks 7mo ago|0 comments
8.
by cmsparks 7mo ago
Sandboxing, which is an optional, opt-in feature, requires persistent access to the code via our github integration + us syncing certain refs to our backend. However, even if you don't opt into syncing, tool calls will end up sending p
9.
by cmsparks 7mo ago
Reposting part of what Ishaan said elsewhere: > We don't have E2EE yet (it's on the roadmap), so some level of trust in Omnara is required today. All repo operations happen locally on your machine. For messages/chat histor
10.
by cmsparks 7mo ago
Yeah, we have parallel agent functionality, sort of like conductor. This allows you to create worktrees for your repo and run any number of chats per worktree. On your local machine, we don't have any unique sandboxing capabilities, bu
11.
by cmsparks 7mo ago
When I say harness agnostic, I more mean we're agnostic to what harness is running, sort of like Zed with ACP: https://agentclientprotocol.com/overview/introduction . It still necessitates bringing the SDK and us w
12.
by cmsparks 7mo ago
We're not a fork, and from what I've heard from users our architecture is more reliable
13.
by cmsparks 7mo ago
they're free up to a limit, just like us!
14.
by cmsparks 7mo ago
We've seen a decent amount of comparisons to Happy, but anecdotally from some Omnara users who have used both, I've heard that reliability and latency when sending messaages is much better in Omnara We try to provide more features
15.
by cmsparks 7mo ago
Thanks, we try to make it much easier than self hosting and managing your own tunnels! Let us know how it goes.
16.
by cmsparks 7mo ago
Our goal is building infrastructure around the agent tools, which I think is how we'll build up a moat and provide automation value. I agree that competing with the labs on general tools is probably a bad business decision, but I'
17.
by cmsparks 7mo ago
When we started out, people were asking "Why would you want to continue coding on your phone". There's obviously a ton of competition now, but I think it's also validation for us. Even though this might be "the obvi
18.
by cmsparks 7mo ago
> branching not from main This is actually a PR that I have open right now, it'll be out soon! > automatic capitalization We'll get this fixed > automatic worktree names definitely on our roadmap, probably will do that th
19.
by cmsparks 7mo ago
Yeah we've definitely taken some inspiration from everyone who building an agent orchestrator/delegation app right now!
20.
by cmsparks 7mo ago
Anecdotally from some Omnara users who have used both, I've heard that reliability and latency when sending messaages is better in Omnara We try to provide a decent chunk of features on top as well, including (but not limited to): * we
21.
by cmsparks 7mo ago
FWIW, we'll definitely add OpenCode support soon!
22.
by cmsparks 7mo ago
OpenCode is great and `opencode serve` in particular is very cool. Though I think the main thing is that you need to manage the OpenCode server yourself and expose it via tailscale or something like that. Our goal is to provide managed infr
23.
Components will kill pages(bitsandbytes.dev)
63 points by cmsparks 7mo ago|48 comments
24.
by cmsparks 7mo ago
IMO feels sorta like Simon Willison's definition of agents. "LLMs in a loop with a goal" feels super obvious, but not sure if I would have described it that way in hindsight
25.
by cmsparks 8mo ago
"How many times does 'r' appear in the word strawberry?"
26.
by cmsparks 9mo ago
> It has some support, but it got merged into A2A, which I don't hear anyone talking about, so it seems like it's going to die on the vine. I'm not sure this is true, do you have a source? Maybe conflating this with the re
27.
Eliminating Cold Starts 2: shard and conquer(blog.cloudflare.com)
62 points by cmsparks 1y ago|18 comments
28.
by cmsparks 1y ago
Frankly, it's pretty difficult. Though, I've found that the actor model maps really well onto building agents. An instance of an actor = an instance of an agent. Agent to agent communication is just tool calling (via MCP or some o
29.
by cmsparks 1y ago
>There when would one update the tools? You can’t “trigger” an event which causes a tool change without some hacky workarounds Tool calls can trigger tool changes. Consider an MCP server exposes a list of accounts and tools to manage res
30.
by cmsparks 1y ago
MCP isn't static. It explicitly includes support for dynamically modifying tools, resources, etc via it's client notifications[0]. Sure, context is usually opaque to the server itself (unless you use the sampling feature[1]), but

More ›