Canister computing its cycle consumption

Can a canister compute the number of cycles it has consumed over its lifetime (or since some other time)? It appears not. A canister can inspect its cycle balance at the current time and then again in the future and calculate the difference. It also knows how many cycles it has accepted from calls. But it cannot know how many cycles got deposited directly into its canister id, for example from a cycles wallet with dfx canister deposit-cycles. So I guess the answer is no?


Correct, there is no way to know for sure. Regular monitoring would probably help you calculate an approximate value, but no precise values.

Ok. Too bad, it would be nice if the canister had a way to compute its average historical cycle consumption per day/week/etc. Even from outside that does not seem possible because there is no history of direct cycle deposits.


A cycle ledger would be an important feature if we ever did want to really use cycles as a kind of stable coin once the IC gets to scale. It seems like the replica could report additions/consumption to a canister on the IC at regular intervals out of band of the actual processing.

Unless you have a canister that frequently gets cycles transfers (as in “almost every call”), you can probably get a pretty good estimate of cycle usage if you periodically query your cycle balance. add up all decreases and ignore all increases. That is (roughly) the approach that metric based monitoring systems (e.g. Prometheus) take with counters.

The cycles that come in calls are not the problem. The canister can track those. The problem are the direct cycle deposits that don’t come through calls.

Regardless, if you only count decreases in cycle balance (and you don’t get a lot of increases from whatever source), then you should get a pretty good estimate of cycle consumption.

1 Like

We discussed this idea, in the previous week’s Execution team meeting, and we touch on it again today. We are thinking about introducing a breakdown of the canister’s cycle consumptions by the types, e.g. cycles spend on memory, cycles spend on instructions, HTTP outcalls, ECDSA outcalls, etc, but the set of types is still the subject of discussion. We have this on our list, but there are other projects that are higher priority and we cannot give an ETA on when this one will be done.