Claude 5h limit drains about 1.7x faster in T3 Code than in the Claude Code CLI (Anthropic Agent SDK metering) #24649

Activity

1. t3dotgg

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   upstream

   triage:keep-openKeeps this PR open despite not necessarily passing the contribution guide fullyKeeps this PR open despite not necessarily passing the contribution guide fully

   on Oct 25, 2026
2. t3dotgg

   self-assigned this

   on Oct 25, 2026
3. dehydr8

   added a commit that references this issue on Oct 28, 2026

   feat(launch): add opt-in entrypoint relabeling via CPROXY_ENTRYPOINT (#…

   ...

   de54322
4. 0oAstro

   added a commit that references this issue on Oct 29, 2026

   feat(t3): label T3's Claude sessions as t3-code

   ...

   d373a55
5. 0oAstro commented on Oct 29, 2026

   

   0oAstro

   on Oct 29, 2026

   More actions

   Note

   Claude Opus 5.5 writing on behalf of Shaurya.

   Another reproduction, on a Team (standard seat) plan, plus a check of the relabel from #25597.

   Setup. Linux arm64, Claude Code 2.1.311, claude-opus-5-5 at effort high. A Team seat that nothing else used during the test. The prompt was the same each run: one reasoning question, no tools, about 3.5k output tokens and a 27k-token prefix. I read five_hour.utilization from /api/oauth/usage before and after each block of runs, after waiting for it to settle. "Weighted" is the transcript usage at list-price ratios: input 1, 5m cache write 1.25, 1h cache write 2, cache read 0.1, output 5. Every arm used the same binary and model. I checked the entrypoint in every transcript.

   Entrypoint	How it ran	Runs	Weighted tokens	5h meter	Weighted tokens per 1%
   cli	interactive TUI in tmux, driven with send-keys	8	217k	+2%	~108k
   t3-code	T3 Code's exact flags (stream-json, --include-partial-messages, summarized thinking), CLAUDE_CODE_ENTRYPOINT=t3-code	11	244k	+2%	~122k
   sdk-ts	the same T3 Code flags with CLAUDE_CODE_ENTRYPOINT=sdk-ts	39	933k	+20%	~47k

   • sdk-ts uses about 2.3x more of the 5h window per token than cli. The meter moves in 1% steps, so the cli and t3-code rows are only ±1%, and the ratio could be anywhere from about 1.5x to 3x. The sdk-ts rate is the most precise, because it is spread over 20 points.
   • With the t3-code label, the cost drops to the cli rate, within the 1% resolution.
   • Summarized versus omitted thinking display made no measurable difference under sdk-ts (9 runs each).
   • The weekly meter moved 0 to 4% in total, with no difference between arms that I could see.

   Pitfall for anyone measuring this from inside T3 Code. Every process started from a T3 thread inherits CLAUDE_CODE_ENTRYPOINT=sdk-ts, including claude started inside tmux. My first A/B ran this way and showed no difference between arms, because every arm was sdk-ts. Remove the CLAUDE* and T3* variables from the environment, then check entrypoint in the transcripts.

   Applying the relabel without patching T3 Code. The Agent SDK only sets sdk-ts when CLAUDE_CODE_ENTRYPOINT is unset, and T3 Code passes its own environment to Claude. So a systemd drop-in on the T3 Code service is enough:

   # ~/.config/systemd/user/t3code.service.d/claude-entrypoint.conf
   [Service]
   Environment=CLAUDE_CODE_ENTRYPOINT=t3-code

   After systemctl --user daemon-reload and a restart of T3 Code, new T3 Code sessions record "entrypoint":"t3-code". The concern raised in anthropics/claude-code#97074 still applies: this changes the label rather than fixing the metering.