The answer depends on the "speed" of the target hash:
If it's a fast hash (like MD5), Daisetsu is roughly correct - that it's not worth the trouble to worry about it (though it can vary based on attack and targets);
If it's a slow hash (like bcrypt), the GPUs won't be starved for candidate passwords, so you have the luxury of generating candidates externally (off-GPU) without slowing down your attack.
A common technique for the latter is to combine hashcat's
--stdout option with your attack to generate your candidates, and then pipe that hashcat to another instance of hashcat (which does the actual cracking).
To inject length requirements into that pipeline, the hashcat-utils len utility works this very efficiently. If there are complexity requirements, the req utilities from hashcat-utils is also very efficient.
So you could do something like this to generate the candidates:
$ hashcat rockyou.txt -r rules/best64.rule --stdout
... and then pipe that to another hashcat (for example, assuming a requirement of length minimum of 8, and maximum of 11):
hashcat rockyou.txt -r rules/best64.rule --stdout | len 8 11 | hashcat -a 3200 targets.hashes
... but keep in mind that this is useful only for slower hashes.
Note that if the hash is slow enough, you can use anything (Perl, shell scripts, crunch, etc.) to do whatever fancy candidate generating and sifting that you want. As the speed of the hash starts to increase, you'll want to benchmark your pipeline to make sure that you're not starving the GPUs (they should usually show 100% in hashcat's status output). hashcat and
len are very fast, as are the other tools in hashcat-utils, so I usually point people there.