---
title: "The weekly limit alert that fired twice at 3:40 AM"
canonical: https://dxdev.com/blog/venture-boundary-keeps-infra-separate/
datePublished: 2026-09-11
---
The alert said "You've hit your weekly limit, resets 4am." It showed up twice at 3:40 in the morning, six minutes apart.

It was the second night in a row. Quota burn that day had run about double normal, mostly long subagent sessions doing verification work. You dispatch a review, it comes back "not approved" four or five times, and then a fix finally clears. By 8:43 PM we sat down to figure out what to do. Running dry in the middle of the night means hours of dead air on a system meant to run unattended.

## The login that was sitting right there

The platform's Discord bot and JIRA bot run on a droplet under a shared Claude account. It's on the Pro plan, already authenticated and already paid for. We could have pointed our own terminal session at those same credentials and kept working. Nobody would have noticed for a night.

We ruled it out. The reason took longer to write down than the decision did.

That account is not ours to borrow. It's tied to a bot that answers real people in a real Discord server and files real tickets against production issues. Suppose we log into it from our own machine for a personal coding session and something goes sideways. A rate limit trips, a session token gets invalidated, two concurrent logins interact strangely. We've then put a live customer-facing service at risk to save ourselves an inconvenient night. The account boundary is the line between "our side work stalled" and "the platform's support bot went down and nobody knows why."

## What we used instead

We looked at what was actually available. Codex CLI was already authenticated on the same machine through a separate ChatGPT subscription, and it worked as a standalone fallback. None of our existing setup carried over, though. No custom skills, no voice-trigger workflow, none of the shortcuts we'd built around the Claude side. We were dropping into a bare terminal and starting over on process. We used it that morning anyway. A slower tool that's fully ours beats a faster one that isn't.

By evening we'd written down the fix. We'll set up a [second Claude account](/blog/failover-tested-incomplete/) on the higher usage tier rather than the base plan, specifically so a quota crunch never again puts the shared production account within reach as an option.

We also caught and corrected a note in our own internal docs that had pointed at a different tool as a quota workaround. That note was wrong for the same reason the droplet account was wrong. It solved the number problem without asking whether the account behind the number was ours to spend.

## What the customers saw

Nothing. The Discord bot answered messages that night exactly like every other night. The boundary held because we treated "which account" as a real question with a real wrong answer. It was not just a login screen to click through in the small hours when the alternative was going back to sleep.

The fifteen minutes it takes to open a second account is cheap. Explaining to a partner why the production bot hiccuped because we were using it to debug our own side project is not. So the accounts behind customer-facing bots stay off limits for other work, even when they're already authenticated and paid for. Development gets its own account on a higher tier.