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

1Password rate‑limiting is the kind of "enterprise security feature" that makes you want to take your laptop, walk into the sea, and let the tide solve your problems

You buy the secrets management control plane (the thing that's supposed to be the adult supervision for autonomous agents) and it turns into a bouncer at your own front door going:

 

"Whoa, whoa, mate, too many requests… come back later." 

Congratulations -- your "secure mediation layer" just turned into a chaos generator that makes your agent look incompetent and your infrastructure tool

The one job is: **be boring under pressure**.Not "be a surprise traffic cop when the user is already dealing with rate limits somewhere else." 

When you rate-limit the credential plane, you're not protecting me -- you're stranding me mid‑operation with a half‑built robot and a pile of broken glass.

Rate limits are fine. But if you're going to throttle, at least

• give a real retry-after
• make failures explicit and atomic
• don't turn normal automation into an improv comedy about authorization headers.

Right now it's less "security" and more "a seatbelt that randomly punches you in the throat.

Look at what Doppler offers

Action                                  Doppler                                                       1Password 

Read Requests               240 to 480 per minute                       1,000 per hour
Write Requests              60 to 120 per minute                           100 per hour

Daily Hard Cap             None (Usage-based)                        1,000 requests per 24 hoursScopePer                                                                                                                         Project/EnvironmentPer 1Password                                                                                                                               Account

I hate to say it but I might have to unlearn all my op command line knowledge and move to Doppler