Service Account Rate Limits: 15+ Minutes Block, No Backoff Duration Shown

UPDATE: Root Cause Identified

Thanks to op service-account ratelimit (which I didn't know existed until I dug through the docs), I found the actual issue:

TYPE ACTION LIMIT USED REMAINING RESET

token write 100 0 100 N/A

token read 1000 0 1000 N/A

account read_write 1000 1000 0 6 hours from now

I hit the account-wide daily limit of 1,000 requests — not the per-token hourly limit.

What Happened

I had op read commands in my .bashrc to set environment variables. Every time a shell spawned (including subshells from scripts and tools), it tried to fetch secrets. This burned through 1,000 requests without me realizing it. The Error Message Problem

The error "Your client has been rate-limited. Try again in seconds" is misleading:

1. Blank duration — the number of seconds is literally missing from the output

2. No indication of which limit — hourly token limit? Daily account limit? No way to know from the error

3. "Seconds" implies short wait — actual reset was 6 hours

The only way to diagnose this was op service-account ratelimit, which isn't mentioned in the error message.

Suggestions for 1Password

1. Fix the error message — include the actual wait time and specify which limit was hit:

Account daily limit exceeded (1000/1000). Resets in 6 hours.

2. Warn before blocking — at 80% usage, log a warning so users can catch runaway scripts

3. Consider higher limits for Families/Personal — 1,000 requests/day is tight for power users with automation

Lesson Learned

Never put op read in .bashrc. Use .bash_profile with an interactive guard:

if [[ $- == *i* ]]; then

export MY_SECRET=$(op read "op://vault/item/field" 2>/dev/null)

fi