Claude's 5-hour usage window drains faster for T3 Code than for the interactive CLI (#24649, anthropics/claude-code#97074). T3 Code runs claude -p, which labels its requests sdk-cli (or sdk-ts through the SDK), and requests with those labels appear to be counted more heavily against the window. Weekly limits are unaffected.
makeClaudeEnvironment sets CLAUDE_CODE_ENTRYPOINT=t3-code for the Claude process it spawns, so requests are labeled as T3 Code. An existing CLAUDE_CODE_ENTRYPOINT is kept, so users can still override it. Custom home paths behave as before.
This is a one-line change to one function, with no new setting. I have no maintainer approval to point to; the linked issues describe the problem.
I measured it on one Claude Max account (claude-opus-5-5, Claude Code 2.1.310) in two rounds that alternated the labels so ordering could not explain the result. Calls stayed on the normal /v1/messages endpoint with no prompt cache and no extra-usage billing, and matching calls used identical tokens.
| Round | Label | Calls per 1% of the 5-hour window | Work per 1% vs sdk-ts |
|---|---|---|---|
| 1 | sdk-ts | 14, 14 | baseline |
| 1 | t3-code | 26, 27 | 1.90x |
| 2 | sdk-ts | 14, 15 | baseline |
| 2 | t3-code | 25 | 1.73x |
| 2 | local-probe-97074 (arbitrary name) | 27 | 1.87x |
Together that is about 1.83x more work per point, or roughly 45% less quota for the same work. The arbitrary name behaved like t3-code, so the gain comes from leaving the sdk-* labels, not from the string itself. @frostfire575 measured the same effect independently below with claude -p (about 2.2x).
What this does not show: the usage meter moves in 1% steps, and this is one account, model and version. I did not measure the interactive CLI directly, and I can't see the server rule behind the difference.
Known gap: claude -p rewrites cli to sdk-cli, so the label must be a custom name. Because this PR keeps an existing value, an inherited sdk-cli or sdk-ts (for example when T3 Code is started from inside a Claude Code session) defeats the default. Overwriting values that start with sdk- would close it; happy to add that if maintainers prefer.
Tests: ClaudeHome.test.ts and ClaudeTextGeneration.test.ts pass (20 tests), including new cases for the default, a preserved override, and custom home paths. Format and tsc --noEmit pass; vp run check:changed can't run as a whole on Windows (it spawns vp without a shell), so I ran those steps by hand.
Model/harness: Claude Sonnet 5.5 via Claude Code (T3 Code).
Added 1 commit
Verdict: Needs Human Approval
Macroscope's review found this PR requires human approval — This PR changes the default environment attribution for Claude processes across several existing production execution paths, potentially affecting upstream usage accounting. The implementation is small and preserves explicit overrides, but the product-default change warrants human review.
You can add or adjust custom eligibility rules. Learn more.
No actionable comments were generated in the recent review.
c22f4aa7-a8fa-4502-9265-cfeee573287bReviewing files that changed from the base of the PR and between 4e42eaf4293c51c5b9eac601b7ab346aa19d08af and c9df56fe2e88d4ec38c095b39916b458dddfd000.
apps/server/src/provider/Drivers/ClaudeHome.test.tsapps/server/src/provider/Drivers/ClaudeHome.tsIncluded review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.
makeClaudeEnvironment now defaults CLAUDE_CODE_ENTRYPOINT to t3-code when it is unset. It preserves inherited values and copies the inherited environment. Tests cover empty and configured home paths.
Changes: Claude environment setup
| Layer / File(s) | Summary |
|---|---|
Entrypoint default and validation apps/server/src/provider/Drivers/ClaudeHome.ts, apps/server/src/provider/Drivers/ClaudeHome.test.ts | The environment builder defaults CLAUDE_CODE_ENTRYPOINT to t3-code only when unset. Tests verify inherited values, PATH preservation, distinct environment objects, and input immutability across empty and configured home paths. |
Priority: External image Low
Estimated code review effort: 2 (Simple) | ~10 minutes
Change: Bug fix
Possibly related issues
pingdotgg/t3code#24649: The issue describes faster usage-window depletion than in the interactive CLI. This change sets the entrypoint value used to identify T3 Code requests.Suggested labels: bugfix, size:XS
Suggested reviewers: macroscopeapp, maria-rcks
c9df5The change is mergeable; it adds the requested default while preserving existing environment overrides.
| Check name | Status | Explanation |
|---|---|---|
| Linked Issues check | Passed | Check skipped because no linked issues were found for this pull request. |
| Out of Scope Changes check | Passed | Check skipped because no linked issues were found for this pull request. |
| Title check | Passed | The title refers to the PR's intended goal of addressing Claude five-hour usage limits. The changes implement request attribution as T3 Code rather than directly changing limits, but the title remains… |
| Description check | Passed | The description includes all required sections. It clearly states the problem, change, scope rationale, verification steps, test results, limitations, and agent details. The scope section does not pro… |
Explanation
The title refers to the PR's intended goal of addressing Claude five-hour usage limits. The changes implement request attribution as T3 Code rather than directly changing limits, but the title remains related to the stated objective.
Explanation
The description includes all required sections. It clearly states the problem, change, scope rationale, verification steps, test results, limitations, and agent details. The scope section does not provide a direct issue link or maintainer approval, but it explains that this is a small, focused change with no new setting, which is sufficient for a PASS.
Comment @coderabbitai help to get the list of available commands.
I measured whether a custom CLAUDE_CODE_ENTRYPOINT value changes the 5-hour accounting, since the PR notes that this wasn't checked. It does.
Setup: Windows 11, Claude Code 2.1.310, claude-opus-5-5 at --effort low, DISABLE_PROMPT_CACHING=1, run on 2026-10-27 between 19:29 and 19:35 UTC. Both arms ran claude -p 4 times with the same prompt: read the same 10 source files (about 300K tokens) and reply "read". The only difference was the environment. One arm set CLAUDE_CODE_ENTRYPOINT to a custom name, not one of the built-in labels. The other left it unset, so the CLI labelled itself sdk-cli. The transcripts confirm both labels. I read utilization with a Haiku -p probe two minutes after each arm, and no other Claude activity was recorded on the account during the test.
| Arm | Entrypoint | Requests | Weighted tokens | five_hour | Tokens per 1% |
|---|---|---|---|---|---|
| Custom label | custom | 8 | 1.43M | 1% to 5% | ~357K |
| Unset | sdk-cli | 8 | 1.32M | 5% to 13% | ~165K |
sdk-cli used the window about 2.2× as fast per token (1.8× to 2.6× within the 1% steps). The custom-label rate is in line with what I measured for the interactive TUI (cli) the day before. That comparison is in anthropics/claude-code#97074.
One thing to consider: this PR keeps an existing CLAUDE_CODE_ENTRYPOINT. If T3 Code is started from a shell that is itself inside a Claude Code or SDK session, that variable is already sdk-cli or sdk-ts and gets passed through, so the fix silently doesn't apply. I hit exactly that during testing. Overwriting it, or only keeping values that aren't sdk-*, would avoid it.
Oh, thanks! I had my agent write the PR, but apparently he forgot about the check I had done. It's fixed now.
Fortunately, this works for other users too great!
If I understand correctly, this is only a T3 Code server change so all that is required is to update the T3 server on my Ubuntu machine and I can continue to use the existing builds of the macOS and iOS clients?
Yes, the change is only the server side!
Yes, the change is only the server side!
Perfect! Thank you for fixing this!
Hopefully @t3dotgg will merge this soon and get us a nightly build.
Been having a blast using T3 Code orchestration v2 with Claude, Codex, and Opencode Go that I added a second claude pro account today because the 5 hour just seemed to evaporate and then I stumble across this... Waiting with bated breath for this to arrive on nightly.
At this point I'd recommend to make your own fork and ask Claude to merge this PR, I am trying to contact any maintainers but it's really hard not going to lie.
Pointed codex to this thread and 2-3 minutes later we were up and running on a patched version. Probably won't bother updating until this gets merged.
I figured out you can actually just set
| 1 | "env": { |
| 2 | "CLAUDE_CODE_ENTRYPOINT": "t3-code" |
| 3 | }, |
in your .claude/settings.json and continue to use the the current version of T3 Code. Although, now I'm that I'm typing this, I'm not sure if it works for sub agents that are spun up in T3 Code or delegated tasks.
Yes, you can also do that!
Note
🤖 Opus 5.5 responding on behalf of Luke Bouch
I'm not sure if it works for sub agents that are spun up in T3 Code or delegated tasks.
Confirmed: it works for both. With CLAUDE_CODE_ENTRYPOINT=t3-code set in ~/.claude/settings.json, I ran a test from a T3 Code thread:
subagents/agent-*.jsonl transcript has "entrypoint":"t3-code".delegate_task): the child runs as its own Claude session, and every entry in its transcript has "entrypoint":"t3-code".Simply adding a new env var CLAUDE_CODE_ENTRYPOINT as anything (t3-code) works!
Oh, that's perfect!!
Note
Written by gpt-6.1-sol on behalf of Maria
the prior-approval rule applies to intentional default changes regardless of diff size. this sets a new default provider entrypoint label to change quota accounting. the account measurements support the reported difference, but do not establish approval to change attribution for every Claude session; the description explicitly claims none.
the discussion also confirms that users can already configure CLAUDE_CODE_ENTRYPOINT through existing environment settings. preserve the quota-accounting report and that workaround, then obtain maintainer approval of the default attribution direction and inherited-override behavior in an Ideas discussion. link the approval here before reconsideration.
this is an unexecuted dry-run draft.
