The best way to think of the inxi weather feature is this: you are a sys admin, you want to check the weather at a remote server, so you do. One time. Then maybe at another remote system. That's really who it is made for, the fact of people instantly starting to abuse it massively by setting up rapid repeat cycles of requests by running inxi on an automated timer like a desktop widget caught me completely off guard when I first realized it was happening.
That's also a silly thing to do, because executing inxi takes a LOT of resources, on an old pentium MMX 200mhz laptop, it takes something like 12 seconds just to compile inxi's Perl to run it, then more seconds to actually execute the data operation requested. You can see how long it takes your system to parse inxi to run it by roughly the time it takes between you hitting enter and the time the first output appears on screen, -s or -M are both very fast to run internally so give a good idea of compilation time vs execution time since almost all the required time was compilation.
For example:
inxi -M;
Machine:
Type: Desktop System: Gigabyte product: X470 AORUS ULTRA GAMING v: N/A
serial: <superuser required>
Mobo: Gigabyte model: X470 AORUS ULTRA GAMING-CF
serial: <superuser required> BIOS: American Megatrends LLC. v: F62d
date: 10/13/2021
real 0m0.194s
user 0m0.153s
sys 0m0.040s
In this case, almost no time is used to generate the data itself, so the user/sys time are probably fairly indicative of the compile time for the Perl, yielding 0.04 seconds to actually get the data,r oughly, maybe 0.06, hard to say. This would probably be spiking at least one and maybe more cores close to 100% as well. inxi prioritizes speed over system resource use since the idea is someone is running it for a reason, to get data, so it doesn't matter how many resources it uses while it's compiling and running. In fact, I'm now dropping more and more data straight into RAM as quicikly as possible, because accessing that is far faster than reading it from the system again, or generating that data repeatedly internally.
The way to think of how not to use inxi weather is if you want to see the weather on your desktop as a widget, then you want a plugin, something like wttr.
In all cases, you do NOT want to run whatever is supplying you with weather more than every 30-60 minutes for the very simple reason that weather APIs do not update their weather data that often, so that's just a total waste of requests, which is one reason the weather apis are starting to slash access numbers per allowed time period, and/or remove access completely as they are bought out and integrated into things like apple or commercial weather entities. I don't know how wttr does it, it looks like it's similar to what inxi does, send the request to the server which then returns the data, so I don't know how the wttr people do it, I guess the code might show it.