Overview. The standard advice is to use a unique CSRF token that is unique for each request. Why? Because a per-request token is a bit more resilient to certain kinds of resilient to certain kinds of implementation errors than a per-session token. This makes per-request tokens arguably the best choice for new web application development. Also, no security auditor is going to hassle you about using a per-request CSRF token.
If you're a web application developer, this is all you need to know, and you can stop reading here. But if you're a security expert wondering about the detailed rationale behind this advice, or wondering about just how great the risk is if you do use a per-session token, read on....
Digging in a bit deeper.
The truth is that, if you don't have any other vulnerabilities in your web site, a single CSRF token per session is OK. There's no reason why you necessarily have to generate a fresh CSRF token per request.
Overall, it can't hurt to generate a new CSRF token for every request. And maybe it's better to do it that way, just to get security auditors off your back. But if you already have a legacy application that uses a single CSRF token for the entire session, spending the money to convert it to generate a new CSRF token for each request probably wouldn't be super-high on my priority list: I bet I could find some other uses for that money and developer energy that would improve security even more.