chrismccord

We use dns_cluster, which ships with all phoenix apps. libcluster achieves the same, so whatever works. Ultimately dist erl just needs a way to reach the nodes and you call Node.connect/1 on a hostname and off to the races. It's similar to FLAME, in that the erlang VM allows sending functions over the wire as a regular transparently encoded/decoded datastructure, but in this case it's just simple built-in erlang erpc, ie `:erpc.call` underneath rather than FLAME where we are managing a pool of elastic nodes, then rpc'ing them.

We had a bug where some sprites would fail to properly suspend while entering their suspended state. You're not eating into credits so no worries there. We've been rolling out a fix across the fleet today so you should be seeing proper status soon.

I've been working on the orchestrator side with Elixir and Phoenix, so happy to continue the discussion for curious minds. One of the coolest things we can do is things like this in Elixir - from any node we can reach out to a sqlite db across the planet:

OrgTracker.with_repo(org_id, fn ->

  repo.all(from sprite in "sprites", select: ...)

That will find or place an Elixir process on the cluster and rpc the target node with our code. Placements can be sticky so they pin to a machine so we don't have to suck down the db every start, but we also balance out the load and handle failover of durable processes automatically. Combined with litestream, the result is distributed sqlite with failover while treating it essentially like a locally reachable sqlite db. Yes there is the speed of light to contend with, but by sending the execution across the wire rather than individual queries, we only ever pay a single hop to reach the process/sqlite.

I've been having so much fun working on sprites (and working with sprites) the last the several months. There's some neat parts of the Elixir side of this we're going to open source soon.

Also check out the 5 min demo we put out where I walk thru some sprite basics: https://www.youtube.com/watch?v=7BfTLlwO4hw

I'm really bummed out by this release. I expected this to best sonnet, or at least match, given all the hype. But it has drastically under performed on agent based work for me so far, even underperforming gpt-4.1. It struggles with basic instruction following. Basic things like:

  - "don't nest modules'–nests 4 mods in 1 file
  - "don't write typespecs"–writes typespecs
  - "Always give the user design choices"– skips design choices.

token auth and re-handshake. Agent is respawned if it's no longer alive, and project index is resynced

You would need to add a fly volume ($0.15/GB per month of provisioned capacity ), also check out https://fly.io/blog/litestream-revamped/

Currently claude 4 sonnet as the main driver, with a combination of smaller models for certain scenarios

as an avid vim user who moved to emacs evil-mode for a better vim than vim, and now who uses vscode with vscode-vim, it pains me to admit a web browser based editor is a better vim than vim. Somehow starts faster and is less kludgey and more scriptable. You can install extensions on phoenix.new, so vim is not a blocker for you. I drive vim emulation in it every day both on desktop app and within phoenix.new. Couldn't use it without it :)

Yes, elixir app deployed across the planet as a single elixir cluster. We spawn the agents (GenServer's), globally register them, and then the end-user LiveView chat communicates with the agent with regular elixir messages, and the IDE is a phoenix channels client that communicates with and is driven by the agent.

This is amazing on multiple fronts! I reset your usage, so the next round is on us! We shipped credits the day before launch, so usage UI is still TBD, but should be out next week. Thanks for the sharing your experience!

claude 4 sonnet as the main driver atm, and a mix of smaller models depending on the scenario

Not using FLAME in this case. The agent runs entirely separately from your apps/IDE/compute. It communicates with and drives your runtime over phoenix channels

Thanks for the feedback! Send your fly email to chris@fly.io and I'll get things sorted out. We'll throw you some credits for the trouble :)

Everything starts as a stock phx.new app which use sqlite by default. Nothing is specific to fly. You should be able to copy the git clone url, paste, cd && mix deps.get && mix phx.server locally and the app will just work.

They run on separate machines and your agent just controls the remote runtime when it needs to interact with the system/write/read/etc

The agent runs outside your IDE instance and controls/communicates with it over Phoenix channels

1.8rc, which is going 1.8.0 momentarily

Meanwhile I am a happy user of :ex_aws or :req_s3 which has done everything I need it to do. Object ops, iam policies, etc. A dependable S3 client has been there for years. The elixir core team doesn't need to maintain it. ReqS3 is one of my favorite things to use: https://hexdocs.pm/req_s3/readme.html

confirm

Req.post to /chat/completions, streaming the tokens through a parser and doing regular elixir messages. It's really not more complicated than that :)

1 week of work to go from local-only to fly provisioned IDE machines with all the proxying. fly-replay is the unsung hero in this case, that's how we can route the *.phx.run urls to your running dev servers, how we proxy `git push` to phoenix.new to your IDE's git server, and how we frame your app preview within the IDE in a way that works with Safari (cross origin websocket iframes are a no go). We're also doing a bunch of other neat tricks involving object storage, which we'll write about at some point. Feel free to reach out in slack/email if you want to chat more.

Yes all 3. It has been weird trying to position/brand this as we started out just going for full-stack Elixir/Phoenix and it became very clear this is already much bigger than a single stack. That said, we wanted to nail a single stack super well to start and the agent is tailored for vibe'd apps atm. I want to introduce a pair mode next for more leveled assistance without having to nag it.

You could absolutely treat phoenix.new as your full dev IDE environment, but I think about it less an IDE, and more a remote runtime where agents get work done that you pop into as needed. Or another way to think about it, the agent doesn't care or need the vscode IDE or xterm. They are purely conveniences for us meaty humans.

For me, something like this is the future of programming. Agents fiddling away and we pop in to see what's going on or work on things they aren't well suited for.

Tidewave is focused on improving your local dev experience while we sit on the infra/remote agent/codex/devin/jules side of the fence. Tidewave also has a MCP server which Phoenix.new could integrate with that runs inside your app itself.

Thanks! Everything is overly complicated in this space. It's probably far easier than you think. The open secret is it's just a loop that POST [provider]/chat/completions.

Elixir is particularly well suited here. In Elixir this is a genserver doing http posts and reacting to the token stream. The LiveView chat gets messages from the genserver agent regardless of where it is on the planet, and the agent also communicates with the phoenix channel websocket talking to the IDE machines with regular messages, again anywhere they are on the planet.

I talk about this quite a bit in my ElixirConfEU talk and distill things down: https://youtu.be/ojL_VHc4gLk?si=MzQmz-vofWxWDrmo&t=1040

"15-minute rails blog" changed the game so I definitely resonate with this. My videos are pretty raw, so happy to hear it works for some folks.

You can push and pull code to and from local desktop already: hamburger menu => copy git clone/copy git push.

You could also have it use GitHub and do PRs for a codex/devin style workflows. Running phoenix.new itself locally isn't something we're planning, but opening the runtime for SSH access is high on our list. Then you could do remote ssh access with local vscode or whatever.

Phoenix creator here. I'm happy to answer any questions about this! Also worth noting that phoenix.new is a global Elixir cluster that spans the planet. If you sign up in Australia, you get an IDE and agent placed in Sydney.

yes large parts of it were built with itself, including non elixir/phoenix things. The entire headless browser (node playwright script) for example was made inside phoenix.new and it iterated on itself. More to come soon!

Done! https://phoenixframework.org/feed

You can thank Steffen from the Phoenix team :)

I will see if we can do something about fedora, but we now convert hyphens to underscores because I'm sure that will trip more folks up – thanks!

For fedora, Elixir has instructions on their site:

    sudo dnf install elixir erlang

I'd love to make it work for elixir install if we can though :)