Add Replicate provider for current-month spend - #2869
Conversation
Lock the cookie-authenticated JSON URLs before implementing the provider fetch pipeline. Co-authored-by: Cursor <cursoragent@cursor.com>
Map current-month spend into providerCost and card detail without inventing quota windows. Co-authored-by: Cursor <cursoragent@cursor.com>
Authenticate dashboard JSON with browser cookies and map HTTP failures to clear errors. Co-authored-by: Cursor <cursoragent@cursor.com>
Wire cookie-based web fetch strategy and spend-oriented menu metadata. Co-authored-by: Cursor <cursoragent@cursor.com>
Expose billing-session cookie configuration without requiring an API token. Co-authored-by: Cursor <cursoragent@cursor.com>
Use explicit self for static helper calls and demote bootstrap notes to line comments. Co-authored-by: Cursor <cursoragent@cursor.com>
Clarify that spend comes from the web billing session, not API tokens. Co-authored-by: Cursor <cursoragent@cursor.com>
|
🦞👀 Pull request received. I will update this pull request when review starts. |
clawsweeper
Bot
added
merge-risk: 🚨 security-boundary
|
Codex review: needs maintainer review before merge. Reviewed August 11, 2026, 4:39 PM ET / 20:39 UTC. ClawSweeper reviewWhat this changesThis PR adds an opt-in Replicate provider that reads browser or manually supplied session cookies to show current-month spend and prepaid credit in CodexBar. Merge readinessThe PR is a coherent, default-disabled provider addition with focused tests and redacted live manual-cookie proof. It should remain open for owner sign-off because it adds a cookie-authenticated provider based on dashboard endpoints, a category VISION.md reserves for review. Priority: P3 Review scores
Verification
How this fits togetherCodexBar provider descriptors connect settings and credential sources to fetch strategies, which normalize provider data into snapshots for the menu bar, provider card, and CLI. This change adds Replicate’s billing-session flow to that shared pipeline. flowchart LR
A[Provider settings] --> B[Cookie source]
B --> C[Replicate billing session]
C --> D[Billing dashboard APIs]
D --> E[Usage snapshot]
E --> F[Menu bar and provider card]
Decision needed
Why: VISION.md requires sign-off for provider additions that affect authentication, user privacy, or data storage; this is a product and maintenance choice rather than a mechanical patch defect. Before merge
Agent review detailsSecurityNone. Review metrics
Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: If sponsored, land the default-disabled descriptor-based integration with its fixed HTTPS origin, Chrome-only automatic import, manual-cookie fallback, and existing focused regression coverage. Do we have a high-confidence way to reproduce the issue? Not applicable: this PR adds a new provider rather than repairing a reported failure; its redacted live CLI transcript does demonstrate the manual-cookie path after the change. Is this the best way to solve the issue? Unclear pending owner sign-off: the descriptor-based implementation follows current provider patterns, but VISION.md requires approval for provider additions that affect authentication or privacy. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 4befde4bbdf0. LabelsLabel changes:
Label justifications:
EvidenceWhat I checked:
Likely related people:
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (4 earlier review cycles)
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d98c576ea2
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| cookieHeader: session.cookieHeader, | ||
| timeout: context.webTimeout) | ||
| return self.makeResult(usage: usage, sourceLabel: "web") | ||
| } catch ReplicateUsageError.invalidCredentials where cookieSource != .manual { |
There was a problem hiding this comment.
When an automatic/cached Replicate session expires, the billing URL redirects to the same-origin sign-in page and returns HTTP 200, so resolveAccount throws parseFailed rather than invalidCredentials. Because this retry path only clears and re-imports cookies for invalidCredentials, automatic users can stay stuck on a stale cached header with a parse error until they manually clear the cache; treat the missing account props/sign-in page as an auth failure or refresh the cache for that parse failure too.
Useful? React with 👍 / 👎.
| /// Preserve Chrome-first behavior, then Firefox and Safari; other Chromium forks remain manual-only. | ||
| private static var browserCookieOrder: BrowserCookieImportOrder? { | ||
| #if os(macOS) | ||
| [.chrome, .firefox, .safari] |
There was a problem hiding this comment.
With Automatic selected, this default import order falls through to Firefox and Safari whenever Chrome has no usable Replicate session, which can trigger extra browser/Full Disk/Keychain prompts during a normal refresh. The repo guidance is to default browser-cookie imports to Chrome only when possible and let users opt into broader browser lists when needed, so this new provider should not widen automatic import by default.
Useful? React with 👍 / 👎.
| cli: ProviderCLIConfig( | ||
| name: "replicate", | ||
| aliases: ["r8"], | ||
| versionDetector: nil)) |
There was a problem hiding this comment.
On non-macOS, CLIUsageCommand.sourceModeRequiresWebSupport rejects .auto for any provider whose fetch plan includes .web unless the descriptor's CLI config declares a browser-support exemption. Replicate can fetch with a manual cookie without any macOS browser import, but this CLI config does not exempt settings.replicate.cookieSource == .manual, so Linux CLI users with a pasted Cookie header get the web-source-unsupported response instead of a fetch.
Useful? React with 👍 / 👎.
Do not fail spend when unused_credit JSON decode or parsing fails; leave creditBalance nil instead. Co-authored-by: Cursor <cursoragent@cursor.com>
clawsweeper
Bot
added
the
merge-risk: 🚨 auth-provider
Thread account kind so personal users are not labeled as organizations, default automatic import to Chrome only, refresh stale sessions after sign-in HTML, and exempt manual cookies on Linux CLI.
clawsweeper
Bot
added
proof: sufficient
1 participant
Summary
Live proof (redacted)
Built and ran the local PR branch (not Homebrew). Session came from Arc via Manual Cookie (Automatic is Chrome-only by design).
Commands used
Before Manual cookie (Automatic / no Chrome session)
After Manual cookie from Arc (success)
Amounts matched Replicate Billing for the current calendar month. No cookies, session IDs, or account identifiers included here.
Focused tests already run on the branch
swift test --filter ReplicateTest plan
$1.25month spend)$36.71 credit)$0):No Replicate session cookies found in browsers.CodexBarCLI usage --provider replicate --verbosesucceedsmake check/ full suite on maintainer CI@clawsweeper re-review