It is literally “per interpreter” meaning all threads in your interpreter. 
(which should mean sub-interpreters get their own limit… if this causes more use of sub-interpreters, that’ll be an interesting consequence)
Why did we feel we had to do that? The CPython internals do not currently have a fully fleshed out concept of an execution context within which interpreter internals settings can be carried around.
Otherwise we’d very much like this to be something that a context could disable without impacting the broader application. Unfortunately that level of feature extending development is too large for a security fix. It makes for a possible 3.12+ feature request though. I imagine an API resembling this:
with sys.int_max_str_digits_context(allowed_digits_at_least=9_999_999): # >= N or 0
... # something you know may intentionally involve huge base conversions.
Where that would only apply to the current linear code flow execution context inside that with statement block, not other threads or other async context switches (including gc).
Though even that may not be enough because it really comes down to some specific types like Fraction just naturally dealing with unruly integer sizes where you’d like to just label all use of that type as “may consume oodles of CPU” and have calculations related to it always be immune. That’s beyond a mere execution context and is more tied to specific data (an int attribute perhaps?)