clav88

Thanks very much! There is some rate limiting being applied so that costs don’t explode. If people are willing to pay for it, the rate limiting can of course be reduced a lot.

I was thinking that sharing and monitoring progress is more useful for longer processes where an update every 10 or 30 seconds could be enough in most cases. What’s your use case?

Alternatively, I’ll clean up and open source the code soon. Then you can run the service yourself without rate limiting if you like.

Thanks very much! A minimal approach is indeed one of the goals.

I agree, many of the monitoring tools are much more powerful than this, but also a lot harder to set up. The goal was to build something with as little friction as possible that you can set up in under a minute, which makes it viable for any one-off script you might be running.

No plans at this point, but I'm planning to open source it soon, so you can add the MCP API if you like and start building the "social layer for progress bars" ;)

Interesting! I agree that nested / hierarchical progress is not straightforward. Even if all child problems are known, the weighting between their individual progress to compute the overall, aggregated parent progress is not easy to determine as it depends on the relative complexity of the child tasks. Perhaps an LLM could help here, but it would have to know the detailed scope of each task it is tracking. Alternatively, pbar could allow users to set their own weights for each sub-bar, so they could integrate their own logic or an LLM to do that. I didn’t want this to become complex in any way though. I therefore opted to do the same as tqdm. A parent progress bar simply counts how many of its children bars are fully completed. It will show 90% progress if 9 out of 10 child tasks are done, even if the last task takes much longer than the others. You can try it e.g. by making nested loops using the tqdm wrapper.

Yes, definitely. The service could easily be scaled and rate limits can be increased if users are willing to pay for. Self-hosting is a good alternative, as you already suggested.

I'll work on cleaning up the code, adding some dev documentation and releasing it on GitHub when I find some time. Perhaps this weekend already!

It's a Next.js app currently deployed on vercel with a Postgres DB running on supabase. Both are fairly scalable, but not in an optimal way in terms of costs. I'd either have to introduce a Pro pricing plan or get some donations from sponsors. The simple nature of the API would allow to heavily distribute this though, i.e. one could simply shard by progress bar.

Regarding the tight loops: Currently there is just basic rate limiting in place and the Python client batches updates by default. The app is not intended for short-lived progress bars with fast updates. These usually also don't have a good reason to be shared and live on the web. It's really much more useful for slowly updating, long running processes.

Thanks for trying it! The link works for me. The progress bar shows 1% now that there's 1 comment and should update to 2% after my reply ;)

I'm happy to clean up the source a bit and put it on GitHub if people like it and prefer to host it themselves. I thought I'd host it myself under a short, memorable domain, so people can easily try it out and share short links to their progress bars.