You're also not getting the free cooling capacity of the water which makes the panels more efficient - though that probably only drops the total cost 5% or so, but how much extra the heavier supports cost may not be much more...
The Cayenne seems to need about 315Wh / mile. I assume a substantial number of them are sold in California, where rates are often above $0.50/kw. I think $1.50 would get you about 9 miles.
I drive a more efficient PHEV and spend much more than $1.50/day.
I'm finding the bottleneck writing Rust code to be that compiling and running tests is too slow compared to TypeScript - which is unfortunate, because I want all of the guarantees of Rust - I just don't particularly care if it runs at the fastest speed possible - at least not at the prototype stage, or ever for a lot of what I'm doing (though I do want the guarantees regardless).
I wish it could run interpreted to massively speed up development, and that it had a Mull-like mutant testing framework so that mutants didn't take hours and tens-to-hundreds of gigabytes of space.
I ran into this exact issue and had Claude write a test run scheduler to avoid cargo process contention and migrated to nextest within it. I have --release build cycles on my local machine down to about three seconds from what was for the same project 60+ seconds before investing in the changes.
The UI/UX seems impressively bad. DeepSWE's cost curve has a better, more obvious way to sort by only the top level of reasoning to avoid 80% of the graph just being the same 3-5 models at their 8 different reasoning levels...
It's also less clear what a lot of their metrics mean. Does Cost per Task include only things that can be verified to work and passed? As best I can tell, it does not.
I'm less concerned if one model's cost per task is $0.10 and another model's cost is $1.50 if the $0.10 task got it right 1% of the time and the $1.50 model got it right 66% of the time.
An equalized / weighted cost/time per task is much more valuable - being massively penalized for taking a lot of time and ultimately not passing when OTHER models did pass.
A lot of what I'm doing has pretty expensive build/testing processes between iterations - even on a 40 core machine - so I'm not burning tokens 24/7 like some people may.
I'd guess I'm probably spending >50% of the time running tests & build processes & tooling and the remainder is purely burning tokens.
I also have some internal tooling (that I will hopefully open source soon) that makes LLMs substantially more correct (thus more efficient) - so there's that, too.
Yes, but specifically compress the concepts, not necessarily the text encoding. "100 commas" and ",,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,," may be different amounts of ascii data, but they both represent the same concept that's worth around 20-30 bits of semantic information.
reply