ThibWeb

for me it’s more an environmental consideration than financial? Passivhaus Standard for houses is about 50kWh/m²/year, so 30kWh is getting close to 10% of total

(OP) yes all energy / carbon footprint numbers are from Neuralwatt. ty for your work! Switched from Standard to Pro last week, it’s great

ah my bad, I’ve switched the visual to A index by cost per task. Note the blog post’s plot is filtered further than AA’s, based on what models are available with inference providers we can actually work with (Europe only). Vibe-coded filtering is here (very rough): https://pareto-eco-sum.netlify.app/

Might do more of that next time! Inference was with TensorX and Neuralwatt.

The high usage was due to omp in vibe mode overnight, probably working way too hard through things. The high cost, yes we’d rather pay extra to work with providers that provide other benefits than just lowest cost possible (open models, no training, EU DC, etc)

No those numbers are GPU only. See https://cleerdash.sustainableaigroup.com/ for a fuller model

For what it’s worth the energy numbers I get from Neuralwatt are within the ballpark of what is available elsewhere like https://cleerdash.sustainableaigroup.com/. What’s your source that there is profit / capex in there? Their published methodology seems pretty transparent

I agree but it does worry me how fast my usage is increasing. Two months ago I was using 10x less tokens and probably not much more than 5kWh on inference. This month about 30kWh on inference. If it becomes more affordable, is there going to be another jump? Not quite sure

Yep, I think next month will be on that. It feels slightly better from a few days of use, and in our WIP benchmarking it scores way higher

I have a hard time justifying GLM 5.3 these days. It’s slightly better than Flash but rarely enough to justify the much steeper price. We chose to use usage-based billing only so are very sensitive to model price.

Yes, all from Neuralwatt, GPU energy use only. Makes models’ “efficiency” much more visible than tokens.

Hmm I might need to rephrase. Initial challenge was to use GLM 5.3 Flash and I was on the non-Flash version for the whole vibe coded build. Just wasn’t paying attention and I didn’t realize that one session was a quarter of the month’s spend and 150% of the budget (big price difference between models)

It was a bit of a silly challenge, wasn’t sure how workable, learned a lot in the process about what actually drives usage / costs, and how to keep both under control

done, added three options to the blog post! ty for the feeback

Good point, i’ll fix that. Instructions are here: https://github.com/wagtail/bakerydemo#api-demo

Let us know how it goes! This is very new for us so feedback is key

Data on the number of releases comes from ecosyste.ms which was very convenient to do this while comparing with other packages outside PyPI. For what it’s worth, Rails is at 510 on there, which I believe is all releases since 2004. And Laravel is at 247 but there’s 2-3 years missing

it’s my 1st attempt at reporting on CI downloads specifically. Interpreting this is more of an art than a science, I’d love to hear if others have ideas on what to do with this data!

for me the surprise is the pace? I’d expect people to be more set in their tools that it takes longer than a few months for a new tool, no matter how good, to become the majority use one. Though perhaps people adopt new tools more easily in CI where install times matter more

Between this and the relative color syntax, looks like much cleverer theming options are on the way, yay for more control for end users. For anyone discovering APCA, aside from it giving better results, I’ve also found it super interesting to read about the logic behind the algorithm. The Easy Intro mentioned in the article (https://git.apcacontrast.com/documentation/APCAeasyIntro) is well worth the time and it has all the relevant follow-up resources.

ty! We have no plans to rewrite Wagtail in Rust but I hope there’s ways in which we can make the developer experience better, particularly around dependencies management

yep, I really appreciate their current efforts, but still think it’s a point of concern. Feels risky to have so much of an ecosystem resting on so few people (bus factor, governance, etc). Hopefully with Astral being a for-profit business they’ll find ways for their work to be more sustainable than other package managers’ maintainers.

A lot of Wagtail usage is with Poetry. Tends to be projects with 30-50 dependencies. It "just works" but we see a lot of people struggle with common tasks ("how do I upgrade this package"), and complain about how slow it is. I don’t have big insights outside of Wagtail users but I don’t think it’s too different.

With the caveat I only have the package installers usage data for Wagtail downloads – pdm usage has fallen off a cliff, from 0.2% of downloads in January 2024, to 0.01% in January 2025. Roughly matches the uptake of uv.

Doesn’t make pdm bad in itself but that means there’ll be fewer pdm users around to report bugs, potentially fewer contributors to it too, fewer resources, etc.

Sure – and I think it’s certainly proving to be a good thing so far! My concerns are more longer-term. I see two primarily:

(1) As uv’s governance is driven by a for-profit company, I see incentives that will eventually compromise on its benefits.

(2) Python packaging has historically been very fragmented, and more recently there’s been lots of work on standardization. That work will be impacted when users massively shift to one package installer.

Neither of those things are clear negatives, but they’re worth being aware of.

Well, seems like 100% what’s going to happen (for the majority of Wagtail users at least) if the current trend continues. I’m not sure if that’s a good thing to be frank. But we’ll have to adjust regardless.

See the proposed moveBefore API [1] which is meant to solve those issues at the platform level. In the meantime, htmx has their morphdom extension, which I’d say is a must when replacing any page content with interactive elements within. Aside from that one major gotcha, the main issues with htmx are the poor accessibility of the examples in the docs [2]. In particular seeing so much ARIA without the corresponding keyboard support.

[1] https://htmx.org/examples/move-before/ [2] https://github.com/bigskysoftware/htmx/issues/1431

Gotcha, thank you. The reasons you mentioned are excellent, definitely a pattern that’s best avoided unless there are no other alternatives.

Thanks for chiming in! Do you think it’s desirable for it to stay "ugly" then if it’s for "internal use"?

I can understand the admin isn’t meant to have a "consumer" UI but it still feels like there are lots of user experience & accessibility improvements needed to bring it in line with modern standards (WCAG for example).

I see three quotes from past contributors in the article, that seems like valuable knowledge to me? Anecdotally as someone who contributes to the Django admin I see the interest is there. I’d say it being clunky is for other reasons (for example there being more back-end developers contributing to the project than other skillsets).