No, and restic doesn’t do incremental backups in the sense that that term historically applies (master backup plus deltas based on either the master or the last delta).
To simplify, when you perform a backup you create a file list (snapshot) of all files that exist at the time of the backup. Each file in that list is checked to see if it has already been backed up before; if not it is uploaded. When you do a forget you are getting rid of a list or lists (snapshots). When you do a purge you are checking for which files are no longer referenced in any remaining lists (snapshots) and they are deleted. As I said, this is a simplified description of what happens.
The operation that can impact ingress/egress from the cloud the most (after the first backup), is the purge, as files are not stored individually, especially if a number of files have been deleted.
If you go through the last month or two of posts you will come across a number of good discussions that explain things in more detail, and you will see that it is easy do get a listing the “incremental” change between two snapshots (I do this on every backup, more to see what has disappeared than has been added).
Re the cache, that speeds up determining what files already exist in the repo, and can be bypassed with a force option on a backup. It slows things down, but the data pulled from the repo is not the backed up files, so data usage is minimal.
Hope this helps.