[Bug]: Usage counts one host Cursor CLI login and omits the accounts that Cursor instances bill #15906

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Summary

Usage reads Cursor account history from one Cursor CLI login, which it finds through the host environment. Since orchestration V2, Cursor threads do not bill that login. Each Cursor provider instance bills the account of its own T3 sign-in or its own CURSOR_API_KEY. The Usage page does not count those accounts, and it shows no notice.

Code facts (main @ 37de6cbde65c7cf9ba90a2557c232e63b7e16988):

• The Cursor part of the Usage scan finds auth.json from hostEnvironment (HOME, XDG_CONFIG_HOME, USERPROFILE, APPDATA, or the macOS Keychain). It does not read settings.providerInstances for the cursor driver. It calls readCursorAccountUsage one time and returns at most one cursor-account:<accountKey> source.
  

  t3code/apps/server/src/usage/UsageService.ts

  Lines 676 to 754 in 37de6cb

  	const cursorUserHome =
  	(platform === "win32" ? hostEnvironment["USERPROFILE"] : hostEnvironment["HOME"]) || home;
  	const configHome = hostEnvironment["XDG_CONFIG_HOME"]?.trim();
  	const cursorHome =
  	platform === "darwin"
  	? path.join(cursorUserHome, "Library", "Application Support")
  	: platform === "win32"
  	? hostEnvironment["APPDATA"] || path.join(cursorUserHome, "AppData", "Roaming")
  	: configHome && path.isAbsolute(configHome)
  	? configHome
  	: path.join(cursorUserHome, ".config");
  	const cursorAuthPath =
  	platform === "darwin"
  	? path.join(cursorUserHome, ".cursor", "auth.json")
  	: path.join(cursorHome, platform === "win32" ? "Cursor" : "cursor", "auth.json");
  	const credentialStore = hostEnvironment["AGENT_CLI_CREDENTIAL_STORE"];
  	const loginUnavailable =
  	Boolean(hostEnvironment["CURSOR_AUTH_TOKEN"]?.trim()) ||
  	Boolean(hostEnvironment["CURSOR_API_KEY"]?.trim()) ||
  	credentialStore === "memory";
  	if (
  	platform === "darwin" &&
  	credentialStore !== "file" &&
  	!loginUnavailable &&
  	!settings.cursorKeychainUsageEnabled
  	) {
  	scanned.push({
  	provider: "cursor",
  	dir: cursorAuthPath,
  	volumeId: "",
  	files: null,
  	message: "Cursor account usage is off on this environment.",
  	action: "enableCursorKeychain",
  	});
  	return scanned;
  	}
  	const cursorUntilMs = yield* Clock.currentTimeMillis;
  	const account = loginUnavailable
  	? {
  	accountKey: null,
  	records: [],
  	missing: true,
  	error: "Cursor account history needs a Cursor CLI login on this server.",
  	}
  	: yield* Effect.promise(() =>
  	readCursorAccountUsage(
  	platform === "darwin" && credentialStore !== "file"
  	? { kind: "keychain" }
  	: cursorAuthPath,
  	windowStartMs,
  	cursorUntilMs,
  	),
  	);
  	// No saved login means there is no account source to report, not a setup error.
  	if (account.missing && account.error === null) return scanned;
  	if (account.accountKey !== null && account.error === null && !account.missing) {
  	// The same account includes CLI and desktop history from every machine.
  	// A stable remote fingerprint prevents connected environments counting it twice.
  	const source = `cursor-account:${account.accountKey}`;
  	scanned.push({
  	provider: "cursor",
  	dir: source,
  	hostId: "cursor.com",
  	volumeId: account.accountKey,
  	files: [{ path: source, records: account.records }],
  	status: "ok",
  	});
  	return scanned;
  	}
  	scanned.push({
  	provider: "cursor",
  	dir: cursorAuthPath,
  	volumeId: yield* Effect.promise(() => readDirectoryVolumeId(cursorAuthPath)),
  	// Never combine a local fallback with another server's account-wide history.
  	files: null,
  	message:
  	account.error ?? "Cursor account history needs a Cursor CLI login saved on this server.",
  	});
  	return scanned;

• The Claude, Codex, and Grok scans go per instance. They merge each instance environment with mergeProviderInstanceEnvironment and add the default instance when providerInstances has no key for that driver.
  

  t3code/apps/server/src/usage/UsageService.ts

  Lines 306 to 321 in 37de6cb

  	for (const driver of ["claudeAgent", "codex", "grok"] as const) {
  	// Disabled accounts still have history. Explicit default slots replace
  	// the legacy settings, just as they do in the provider registry.
  	const instances: Array<
  	Pick<ProviderInstanceConfig, "config" | "environment"> & { instanceId: ProviderInstanceId }
  	> = Object.entries(settings.providerInstances)
  	.filter(([, instance]) => instance.driver === driver)
  	.map(([id, instance]) => ({ ...instance, instanceId: ProviderInstanceId.make(id) }));
  	if (!Object.hasOwn(settings.providerInstances, driver)) {
  	instances.push({
  	config: settings.providers[driver],
  	instanceId: ProviderInstanceId.make(driver),
  	});
  	}
  	for (const instance of instances) {
  	const environment = mergeProviderInstanceEnvironment(instance.environment, hostEnvironment);

• Each Cursor instance gets its key from CURSOR_API_KEY in the merged instance environment or from a T3 sign-in that T3 stores per instance (cursor:<instanceId>). Every SDK session requires that key.
  

  t3code/apps/server/src/provider/Drivers/CursorDriver.ts

  Lines 86 to 123 in 37de6cb

  	const processEnv = mergeProviderInstanceEnvironment(environment);
  	const continuationIdentity = defaultProviderContinuationIdentity({
  	driverKind: DRIVER_KIND,
  	instanceId,
  	});
  	const stampIdentity = withInstanceIdentity({
  	instanceId,
  	driverKind: DRIVER_KIND,
  	displayName: displayName ?? "Cursor",
  	accentColor,
  	continuationGroupKey: continuationIdentity.continuationKey,
  	});
  	const effectiveConfig = { ...config, enabled } satisfies CursorSettings;
  	const credentials = yield* CursorCredentialStore.makeCursorCredentialStore(
  	instanceId,
  	path.join(
  	(yield* ServerConfig.ServerConfig).stateDir,
  	"provider-auth",
  	encodeURIComponent(instanceId),
  	"cursor.json",
  	),
  	).pipe(
  	Effect.mapError(
  	(cause) =>
  	new ProviderDriverError({
  	driver: DRIVER_KIND,
  	instanceId,
  	detail: "Could not open the Cursor credential store.",
  	cause,
  	}),
  	),
  	);
  	const auth = yield* makeCursorAuth({
  	instanceId,
  	displayName: displayName ?? "Cursor",
  	enabled,
  	...(processEnv.CURSOR_API_KEY ? { apiKey: processEnv.CURSOR_API_KEY } : {}),
  	store: credentials.store,

  
  

  t3code/apps/server/src/provider/Drivers/CursorDriver.ts

  Lines 158 to 163 in 37de6cb

  	Effect.provideService(CursorAgentSdk.CursorAgentSdkRunner, {
  	...sdkRunner,
  	open: (input) =>
  	auth.requireApiKey.pipe(
  	Effect.flatMap((apiKey) =>
  	Effect.acquireRelease(

  
  

  t3code/apps/server/src/provider/CursorAuth.ts

  Lines 76 to 92 in 37de6cb

  	const readApiKey = Effect.gen(function* () {
  	if (configuredKey) return configuredKey;
  	const credentials = yield* Effect.tryPromise({
  	try: () => options.store.load(),
  	catch: (cause) =>
  	new ProviderSetupError({
  	instanceId: options.instanceId,
  	operation: "credentials",
  	detail: "Could not read the Cursor sign-in. Try signing in again.",
  	cause,
  	}),
  	});
  	const now = yield* Clock.currentTimeMillis;
  	return credentials &&
  	(credentials.apiKeyExpiresAtMs === undefined || credentials.apiKeyExpiresAtMs > now)
  	? credentials.apiKey
  	: undefined;

So the account that Usage reads and the accounts that threads bill are not the same. This is true for a second instance, and it can also be true for the default instance.

What T3 stores for a sign-in: the stored credential has version, backendUrl, apiKey, createdAtMs, and optional apiKeyExpiresAtMs and email. It has no session access token and no user ID.

readCursorAccountUsage calls the dashboard endpoint with a session cookie. It builds the cookie and the account key from the sub claim of a CLI access token (a JWT). An SDK API key is not that token. So with what T3 stores today, Usage cannot reach the instance account through this endpoint. I do not know whether Cursor has a usage-history endpoint that accepts an SDK API key.

The Limits reader has the same gap. It accepts CURSOR_AUTH_TOKEN, then the macOS Keychain CLI login (when account usage is on), then the CLI auth.json access token. When CURSOR_API_KEY is set and CURSOR_AUTH_TOKEN is not, it returns unsupported. The driver passes the instance API key as CURSOR_API_KEY, so an instance with a T3 sign-in or an API key gets no limits unless CURSOR_AUTH_TOKEN is also set.

Observed on one host: the turn count of a second Cursor instance matched the event count of a different Cursor account, not the account that Usage reads.

Related: #15781 (Cursor V2 ignores the existing CLI login for auth). This issue is about Usage, not about sign-in.

Steps to reproduce

1. Sign in to the Cursor CLI on the server with account A, so ~/.config/cursor/auth.json (or the macOS Keychain) holds account A.
2. In T3 Code, add a Cursor provider instance. Sign it in through T3 with account B, or set CURSOR_API_KEY for account B in the instance environment.
3. Run a thread on that instance.
4. Open Usage > Cost or Usage > Tokens and select Cursor.

Expected behavior

The Cursor total includes the usage of every account that Cursor instances bill, with one count per account. If Usage cannot read an instance account, the page shows a notice for that instance and does not present the partial total as the full Cursor total.

Actual behavior

Usage shows only account A as the full Cursor total. It omits the cost and tokens of account B and shows no notice.

Possible directions

• Read history for each instance account, if Cursor has an endpoint that accepts the credential that T3 stores for that instance (the SDK API key). Count each account one time.
• If no such endpoint exists, show a notice per Cursor instance that the Usage scan cannot read.

Impact

Minor bug or occasional failure

Version or commit

0.0.46-nightly.20261004.2648; main @ 37de6cb

Environment

Linux, t3 serve --mode web, Cursor provider (V2 SDK) with more than one Cursor instance.