o(1) in time complexity of number field sieve It is well known that the time complexity of the number field sieve can be calculated by the formula 
$$\exp\big((C+o(1)) (\log n)^{1/3}(\log \log n)^{2/3}\big)$$

The constant C is known for the special and general number field sieve variants.
My question is, how can the value $o(1)$ be approximated for cryptographic reasonable values of n (e.g. $2^{1024} \le n \le 2^{4096}$)?
Do there exist known upper and lower bounds?

The reason for this question is as follows. By the definition of o(1) one can only conclude that asymptotically this value vanishes. But for any bounded value of n, the value can be anything. Therefore, in a strong mathematical sense, this formula is useless to conclude anything about real-size factorization problems.
Summary: it is common, and arguably safe, to assume that the $o(1)$ term is positive, and take it at zero, in circumstances where the formula is then used to estimate a lower bound of the ratio of work for larger value of $n$ to that for smaller values of $n$.



The formula given, with $o(1)$ term, gives the complexity of NFS. If modified by assigning a real value (say, zero) to the $o(1)$ term, it yields a function of $n$ without unit, thus insufficient to calculate the time (or effort, or cost) needed to run the algorithm for a given $n$. The $o(1)$ term happens to encompass the very order of magnitude of the cost (as a consequence of the outer exponential and the positive exponent to the $\log n$ term).

However, a common and legitimate use of that formula is to evaluate how the effort to run the NFS scales with $n$, by computing the ratio of what the formula gives for different values of $n$ (and taking the base-2 log for a security variation in bits). In that sense, it makes sense to ask which value of $o(1)$ should be used for a given $n$.

I don't know, and likely that depends on the variant of NFS (which also has a huge influence on $C$), and the hardware at hand.

However, a common approach is to hypothesize that this $o(1)$ term is positive, and take it as zero when extrapolating how larger $n$ needs to be, thus (if the hypothesis is correct) erring on the safe side from a key-holder's point of view.



Addition commenting the self-answer: an example of the practice in the previous paragraph is the formula given by the NIST in Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program (updated August 1, 2016), computing the conventional bit strength $x$ of an RSA public modulus of $L$ bits as
$$x\;=\;{1.923\times\sqrt[3]{L\log(2)}\times\sqrt[3]{(\log(L\log (2)))^2}-4.69\over\log(2)}$$
which is obtained by


straightforward transformation of the GNFS complexity formula using $C=\sqrt[3]{64\over9}$ rounded to 4 significant digits;
ignoring the $o(1)$ term, thus obtaining an $x$ such that $2^x$ is an estimation of work in unknown unit;
solving the above issue by introducing the additive constant $-4.69$ (which really is a multiplicative constant of $2^{-4.69/\log(2)}$ on the involved work $2^x$), determined so that when $L=1024=2^{10}$, the result obtained is $x=80.000\dots$, because that fits the FIPS 140-2 normative context, and anecdotal evidence suggests that the cost of breaking common 80-bit symmetric cryptography would be smaller than the cost of factoring a properly generated 1024-bit RSA modulus.


That formula thus arguably errs on the safe side from the key-holder's point of view if used to estimate the security given by an RSA modulus of $L\ge1024$ bits properly generated from true randomness, under the assumption that GNFS roughly as practiced now remains the best factoring algorithm.