mac 上为什么添加了2 个及以上的供应商以后就很卡呀

[qzxwj]

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 9, 2026, 9:14 PM ET / 01:14 UTC.

Summary
Keep open: this is a new, sparse performance report and current main has multi-provider refresh safeguards, but there is no provider list, version, settings, log, or profiling sample proving the lag is already fixed or identifying a narrow source-level repair.

Reproducibility: no. The issue has no body and does not name the provider combination, version, refresh settings, storage setting, logs, sample trace, or steps needed to reproduce the lag on current main.

Ways to help us reproduce this

• Add expected vs actual behavior.

Next step
A maintainer or reporter needs to provide the slow provider combination and profiling evidence before this can become a focused fix PR.

Review details

Best possible solution:

Ask for a focused reproduction and profiling sample first; then fix the identified slow path in the provider refresh, token-cost, storage-scan, or menu-rendering code with focused tests and no live-account probe requirement.

Do we have a high-confidence way to reproduce the issue?

No. The issue has no body and does not name the provider combination, version, refresh settings, storage setting, logs, sample trace, or steps needed to reproduce the lag on current main.

Is this the best way to solve the issue?

Unclear. A refresh, token-cost, storage-scan, or menu-rendering performance fix may be the right solution, but the narrow maintainable fix cannot be selected until the slow path is identified.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The report may describe a real multi-provider responsiveness regression, but the empty body gives no provider combination, CodexBar version, refresh frequency, storage-footprint setting, Activity Monitor sample, logs, or screen recording.
• Current main has several performance safeguards, so changing refresh cadence, provider availability, menu rendering, or storage scanning without a concrete slow path could regress working multi-provider setups.

Codex review notes: model gpt-5.5, reasoning high; reviewed against a4f278d91fe4.

Label changes

Label changes:

• add P2: The issue describes a possible user-visible app responsiveness problem after enabling multiple providers, but it lacks enough detail for urgent regression handling.
• add impact:other: The concrete impact area is macOS app performance/responsiveness, which is meaningful but outside the specific owned impact categories.
• add issue-rating: 🦪 silver shellfish: Current issue advisory state selects this label.
• add clawsweeper:needs-info: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.

Label justifications:

• P2: The issue describes a possible user-visible app responsiveness problem after enabling multiple providers, but it lacks enough detail for urgent regression handling.
• impact:other: The concrete impact area is macOS app performance/responsiveness, which is meaningful but outside the specific owned impact categories.

Evidence reviewed

Acceptance criteria:

• After a reproduction is known, prefer focused XCTest coverage around the implicated store/model path rather than live provider probes.
• For storage-scan changes, run swift test --filter ProviderStorageFootprintTests.
• For refresh/menu model changes, run the narrow affected UsageStore* or StatusItemController* tests plus make check before handoff.

What I checked:

• Issue context: The GitHub context shows an open issue with the Chinese title reporting lag after adding two or more providers, an empty body, zero comments, and no reproduction details.
• Repository policy shaped reproduction: AGENTS.md says live provider probes, browser-cookie imports, real account usage checks, and real SecItem reads must not be run unless explicitly requested, so this review did not attempt a live multi-provider probe. (AGENTS.md:24, a4f278d91fe4)
• Current refresh behavior: Current main guards against overlapping refreshes, gathers enabled providers, and runs provider usage/status work through a task group; token-cost work is scheduled outside the regular refresh path because it can be slow. (Sources/CodexBar/UsageStore.swift:555, a4f278d91fe4)
• Provider fetches are intended to avoid UI stalls: The provider fetch path explicitly moves fetch work off MainActor so slow keychain or process reads do not stall menu/UI responsiveness. (Sources/CodexBar/UsageStore+Refresh.swift:67, a4f278d91fe4)
• Optional storage scan behavior: Optional provider-storage scans are gated behind the provider storage setting, coalesced, throttled to a five-minute automatic interval, and run on detached utility work before applying results on MainActor. (Sources/CodexBar/UsageStore+ProviderStorage.swift:82, a4f278d91fe4)
• Refresh-loop docs: The refresh-loop docs describe background refresh as off-main and storage scans as optional, backgrounded, coalesced/throttled, and not blocking the usage refresh path. (docs/refresh-loop.md:15, a4f278d91fe4)

Likely related people:

• Peter Steinberger: Current refresh/menu/storage lines blame to the v0.32.5 release commit, and recent history includes menu refresh and token scanning performance work in the central files. (role: recent area contributor; confidence: high; commits: 920997c6a365, 07ed3facdd4e, d7db9922b5fb; files: Sources/CodexBar/UsageStore.swift, Sources/CodexBar/StatusItemController+MenuRefreshScheduling.swift)
• Ratul Sarna: Commit 48cd466 moved provider fetches off MainActor, directly matching the responsiveness area implicated by multi-provider lag. (role: introduced relevant refresh behavior; confidence: medium; commits: 48cd466452ad, 468950d5b8f8; files: Sources/CodexBar/UsageStore+Refresh.swift)
• Perry Story: Commit c2b63a0 moved regular credits and dashboard fetches into background behavior in UsageStore, an adjacent refresh-performance path. (role: adjacent performance contributor; confidence: medium; commits: c2b63a01bae4; files: Sources/CodexBar/UsageStore.swift)
• Fatih Emin Oge: Commit 5252068 added provider storage usage, which is optional but relevant because storage scans scale with enabled providers and could be involved in lag reports. (role: introduced provider storage scanning; confidence: medium; commits: 5252068a1e1a; files: Sources/CodexBar/UsageStore+ProviderStorage.swift, Sources/CodexBarCore/ProviderStorageFootprint.swift)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[sweetcard]

Downgrade to 0.25.1 and everything is ok😄