[talos_]

That makes sense. I'll look into it more!

One project was to create a layer between external APIs (OpenAI, Gemini, Claude) and our team. This way we can manage the cost of API calls, try different providers, and log API usage to find out what works / what doesn't.

How does burr scale with an application and support multiple users?

[elijahbenizzy]

Cool! Yeah I think that would pair nicely. You can have the abstraction at the action level, or push it down into the stack (as it seems you're doing). Have also seen some startups building proxy layers for OpenAI/GPT.

It's just a library so it depends on what could be the bottlenecks. Standard ones are: 1. Compute -- just scale horizontally 2. DB -- scale horizontally (and vertically), use intelligent partitioning

(1) is generally easy with autoscaling, (2) is where your queries/data modeling matter, and this is why we made persistence entirely pluggable, figuring we wouldn't know the best usage patterns yet. More reading: https://burr.dagworks.io/concepts/state-persistence/.

One more thing to think about -- Burr isn't opinionated about how you build your app -- E.G. up to you to think about what happens if you have your webapp open in, say, two tabs. You'll need to manage situations like this, but Burr's plugin capabilities should make that easier to iterate on. We're looking to add more examples on this -- also reach out if you have any specific questions/find anything missing/have suggestions.