Hacker News: chrismccord

New comment by chrismccord in "Design and Implementation of Sprites"

chrismccord — Fri, 16 Jan 2026 03:43:39 +0000

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.

New comment by chrismccord in "Design and Implementation of Sprites"

chrismccord — Thu, 15 Jan 2026 18:15:35 +0000

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.

New comment by chrismccord in "Design and Implementation of Sprites"

chrismccord — Thu, 15 Jan 2026 18:05:40 +0000

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: ...)

end)

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.

New comment by chrismccord in "Code and Let Live"

chrismccord — Sun, 11 Jan 2026 04:33:45 +0000

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

New comment by chrismccord in "GPT-5 for Developers"

chrismccord — Fri, 08 Aug 2025 00:47:42 +0000

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.

gpt-4.1 way outperforms w/ same instructions. And sonnet is a whole different league (remains my goto). gpt-5 elixir code is syntactically correct, but weird in a lot of ways, junior-esque inefficient, and just odd. e.g function arguments that aren't used, yet passed in from callers, dup if checks, dup queries in same function. I imagine their chat and multimodal stuff strikes a nice balance with leaps in some areas, but for coding agents this is way behind any other SOTA model I've tried. Seems like this release was more about striking a capability balance b/w roflscale and costs than a gpt3-4 leap.

New comment by chrismccord in "Phoenix.new – Remote AI Runtime for Phoenix"

chrismccord — Sun, 22 Jun 2025 15:44:29 +0000

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

New comment by chrismccord in "Phoenix.new – Remote AI Runtime for Phoenix"

chrismccord — Sun, 22 Jun 2025 15:43:30 +0000

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/

New comment by chrismccord in "Phoenix.new – Remote AI Runtime for Phoenix"

chrismccord — Sun, 22 Jun 2025 15:41:30 +0000

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

New comment by chrismccord in "Phoenix.new – Remote AI Runtime for Phoenix"

chrismccord — Sun, 22 Jun 2025 15:30:39 +0000

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 :)

New comment by chrismccord in "Phoenix.new – Remote AI Runtime for Phoenix"

chrismccord — Sun, 22 Jun 2025 15:22:51 +0000

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.

New comment by chrismccord in "Phoenix.new – Remote AI Runtime for Phoenix"

chrismccord — Sun, 22 Jun 2025 01:17:00 +0000

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!

New comment by chrismccord in "Phoenix.new – Remote AI Runtime for Phoenix"

chrismccord — Fri, 20 Jun 2025 20:41:25 +0000

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

New comment by chrismccord in "Phoenix.new – Remote AI Runtime for Phoenix"

chrismccord — Fri, 20 Jun 2025 20:39:13 +0000

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

New comment by chrismccord in "Phoenix.new – Remote AI Runtime for Phoenix"

chrismccord — Fri, 20 Jun 2025 18:55:29 +0000

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 :)

New comment by chrismccord in "Phoenix.new – Remote AI Runtime for Phoenix"

chrismccord — Fri, 20 Jun 2025 17:45:32 +0000

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.

New comment by chrismccord in "Phoenix.new – Remote AI Runtime for Phoenix"

chrismccord — Fri, 20 Jun 2025 17:43:51 +0000

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

New comment by chrismccord in "Phoenix.new – Remote AI Runtime for Phoenix"

chrismccord — Fri, 20 Jun 2025 17:43:02 +0000

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

New comment by chrismccord in "Phoenix.new – Remote AI Runtime for Phoenix"

chrismccord — Fri, 20 Jun 2025 17:16:35 +0000

1.8rc, which is going 1.8.0 momentarily

New comment by chrismccord in "Phoenix.new – Remote AI Runtime for Phoenix"

chrismccord — Fri, 20 Jun 2025 17:16:07 +0000

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

New comment by chrismccord in "Phoenix.new – Remote AI Runtime for Phoenix"

chrismccord — Fri, 20 Jun 2025 17:09:56 +0000

confirm