Carmine is cooking. His work on RubyLLM has been incredible, even going as far as upstreaming important work about fiber usage into Rails Solid Queue so that we reap the Async benefits, which are essential in this LLM age.
Fiber mode isn’t universally better. CPU-bound jobs get nothing from it, and blocking libraries or C extensions that do not cooperate with Ruby’s fiber scheduler stall the reactor. And that’s fine – you don’t have to pick one.
As Trevor Turk pointed out in the PR discussion, that’s the whole point: separately configured worker pools. Here’s what Chat with Work actually runs in production:
Carmine (which coded this Fibers update) wrote about this in his blog. See the section 'The database connection math'. And no, you won't have one connection per fiber.
The difference is staggering when you compare to threaded mode: it requires 1,320 database connections to run the same benchmark that the fiber mode runs with 60.
Pretty sure that is entirely an unfair comparison. You don't need a connection per thread either. It is common to have web servers handles thousands of requests per second with a connection pool size of 20. As long as the handler threads borrow a connection for only a little time and block waiting for a connection while other threads are doing their thing, it works out fine.
There is absolutely no logical reason why database pool sizing could be a reason for preferring fibers over threads.
- We have 2 sources of data that we must backup to continue existing as a business; our postgres and binary files in S3. Everything else is derivable (elasticsearch, so on).
- For postgres, we use barman. With the help of opus/fable, you can get a streaming replication backup working in no time. We have one into another server in the same datacenter (we use baremetal) and another one in another server in a different datacenter.
- We then have a last resort barman backup with bi-weekly base backups + WAL streaming to S3 (both the base backup and WALs). It sends these backups + wal segments into an specific S3 bucket that has object lock in compliance mode. This is a feature from AWS S3 that even the most privileged account credentials (super admin) can't turn off nor delete the files before the object lock, which is 10 days in our case. Object lock compliance mode can only be extended, never shortened.
- For S3, we store them into another versioned bucket, with lifecycle rules to also expire non current versions (== deleted objects) after 10 days. No point in object lock compliance here because it would only protect objects for the most recent 10 days, and you gain nothing. What we do instead: the app servers only have access to these bucket tru an IAM credential that can't delete old versions (so deleted objects have to expire manually via the lifecycle rule) AND this IAM credentials also can't change the object policy.
IMHO, this protects us enough so that even in the worst case scenario (ransomware) we have 10 days to sort everything out and recover our AWS access.
And yes, we test the S3 barman restoration and it works fine. Data loss is at max 5 minutes due to the archive_timeout=300s on the primary.
For the streaming replications in the two servers I mentioned, it's less <1ms, but those wouldn't protect us much in the case of the ransomware - even tough we use tailscale and one compromised server can't ssh into the other.
i have daily backup instances to cold standby qemu-kvm VMs with snapshots of qcow2 storage which are kept for 10 days and i skip deleting every weekly Monday backup until space becomes a problem (usually months). sometimes the qcow2 storage backend becomes too slow with so many snapshots and that's when i qemu-img convert it which basically fixes it but removes the snapshots, so i keep both of them for a while.
I’m using Claude code dynamic workflow like this. I tell Fable to use a workflow. He is the planner, orchestrator and reviewer. Opus agents are implementers. Works unbelievably well.
I do the same, but delegate to codex instead via the /smux skill. It's expensive, but I get one long-running Claude context window and one frequently compacting codex, and this saves me from needing to re-gather context all the time.
Per the OP's technique, I'll use Fable for intensive planning moments, then switch back to opus when things are going well.
It's literally all there is to it. Write your prompt normally. then, at the last paragraph, you write:
Use a workflow to implement this. You (Fable) are the orchestrator, planner and reviewer. Opus agents are implementers.
That's all there's to it. it will create the dynamic workflow - has a nice interface native to Claude Code - and do all the coordination to deliver what you asked.
In many languages that’s the only way to express that since there is no “it”. It doesn’t mean speakers of such languages anthropofy everything and I think that’s the case here.
reply