LeetCode submission judge enforces stricter resource limits than custom test runs

LeetCode's online judge evaluates submissions in a language-specific sandbox, yet problem statements typically express constraints as input-size bounds and target complexity rather than explicit wall-clock or memory budgets. The custom-test / Run Code path and the Submit path are not guaranteed to behave identically; hidden cases and stricter resource enforcement apply during submission. This leaves an unresolved boundary for solutions that pass custom validation but may encounter different limits under final judging.

The uncertainty centers on whether the submission environment enforces additional undocumented ceilings—such as tighter timeouts, lower memory caps, or stricter recursion-depth thresholds—that are not observable during custom testing. Because exact limits vary by problem and can change without notice, assuming parity between the two evaluation paths is unreliable.

For a specific language runtime, what is the practical boundary between the custom-test sandbox and the submission sandbox? Are the additional submission limits uniform across all supported languages, or do they scale with interpreter overhead and memory accounting differences? How can a developer determine whether a given algorithm sits within the submission judge's implicit resource envelope without relying on trial-and-error submissions?