Open Hands (https://openhands.dev/) looks like it’s similar to what you want.

Is for me in Claude Code

What’s the plan for this? Sharing with a specific group (DM, group chat, feeds from people you follow) are critical to social media.

See https://www.pfrazee.com/leaflets/3lzhui2zbxk2b for some recent thoughts from a team member.

Bnewbold's comment on GitHub is still the best resource. It's far more specific in scope and details. Paul's note is more theoretical / philosophical

https://github.com/bluesky-social/atproto/discussions/3363 - maybe this one?

yes, that is the one everyone is using as a guiding light for where we think Bsky is headed for their private data needs, which is group-shared / not e2ee because key mgmt is an unsolved problem at scale. They need to support creators with subscriber only content. E2EE will emerge from the messaging space first, i.e. Signal / MLS like

Bsky is likely to put out a short-term gap filler this year for personal-private data, which kind of already exists today for Bsky only. This work would make that same feature in the per-user repo available to all apps. Right now it's hard coded to a specific NSID and single db row

Yes - hard to see e.g. city labels on the map under all the pie charts.

LLMs can handle Google drive perfectly well with a service account, including the Google drive specific quirks through the API. It could be helpful to expose via a file system rather than a custom API if you wanted a different interface than Google already provides, but this wouldn’t be driven by the limitations of the LLM.

In terms of ergonomics, I’d say a filesystem is more intuitive for an agent than the Google Drive API even if it can handle both. Hard to argue without building an eval set and evaluating both, though.

I’ve been doing this recently and for the basics agents had no problem with the API apart from the weird behaviour of shared drives needing a special flag to handle them. This could probably be mapped to a file system in a way that wouldn’t trip up an agent, but at the expense of losing the Google drive specific functionality. A trade off, not much better or worse per se, but with the added complexity of the FUSE layer.

The less juggling of concepts thr more effective any problem solver cam be.

I complained about the communications around this issue a few weeks ago, and bcherny popped up in the comments with an explanation of what they were doing. Now there’s a fix with a great explanation of the background to this bug and future directions from chrislloyd.

I use bun in a project but Claude Code always uses node to run throwaway scripts. Maybe they can persuade it to use bun as part of this acquisition?

I bet CC will become a binary with bun included and it'll use it's internal JS engine to run most scripts.

Oddly I saw it try to use bun the other day, and was confused because everything in the project is in node.

I always tell it to use Bun and it works? Am I misunderstanding?

It seems the default is node (despite the project docs saying to use bun and all example script documentation using bun). It will use bun if told, but there’s definitely nothing saying to use node and it uses that anyway.

With less token usage, cheaper pricing, and enhanced usage limits for Opus, Anthropic are taking the fight to Gemini and OpenAI Codex. Coding agent performance leads to better general work and personal task performance, so if Anthropic continue to execute well on ergonomics they have a chance to overcome their distribution disadvantages versus the other top players.

Thank you Claude.

It’s a pretty arbitrary y axis - arguably the only thing that matters is the differences.

Compare https://odyssey.ml/ another text conditioned world generator

Personally, I think diffusion model world gens like Odyssey are the future, and not polygon-gen tools like TFA.