grace_daily_limit_reached triggers inconsistently for claude --print, independent of account usage % shown in UI

I'm hitting error_type: grace_daily_limit_reached when invoking claude --print non-interactively (spawned as a child process from a Node.js server, with ANTHROPIC_API_KEY deliberately deleted from the child env to force the OAuth/subscription session, per the documented pattern for using Claude Code as a local automation backend).

Error: {"data":{"modal_data":{"elapsed_days":1},"type":"unlock_full_access_notice"},"error_type":"grace_daily_limit_reached"}

What doesn't add up: the account's own usage indicator shows only ~22% of its normal usage window consumed. Despite that, repeated claude --print calls today intermittently fail with this grace-limit error — sometimes back-to-back isolated test calls with near-identical prompts succeed, and then the next one (or the same call from within a Next.js API route child process) fails with the same error, with no clear pattern.

Reproduction context:

• Windows 11, Claude Code CLI v2.1.200
• Invoked via child_process.spawn(claudeExePath, ["--print"], { env }) (env has ANTHROPIC_API_KEY deleted so the OAuth session is used instead of an API key)
• Prompt piped via stdin, --print for non-interactive output
• Same exact invocation pattern succeeds and fails intermittently within the same few minutes, both when called from an isolated Node script and from a Next.js dev server's API route

Questions:

1. Is grace_daily_limit_reached a separate quota from the interactive usage % shown in the product UI — e.g., specifically throttling non-interactive/--print/automated invocations?
2. If so, is there a way to see remaining "print mode" / automation quota, distinct from the general usage percentage?
3. Is this expected behavior for using claude --print as a backend automation call (per patterns documented for building local tools on top of Claude Code), or is intermittent failure here a bug?

Happy to provide more repro details if useful.