Add LithosAI as a provider

[movinimage]

I use LithosAI as my provider. Any chance you'd consider adding it? Thanks!

https://www.lithosai.com

[clawsweeper]

Codex review: this still needs some work. Reviewed September 22, 2026, 12:51 PM ET / 16:51 UTC.

Summary
Keep open: provider additions fit CodexBar’s stated direction, and LithosAI is not registered on current main or in v0.64.1. Implementation needs a verified usage-data and authentication contract; repository policy also prohibits automatic closure.

Reproducibility: not applicable. this requests a new provider rather than reporting a failure of existing behavior.

Next step
Obtain usage or balance API documentation and redacted response examples with authentication requirements before scoping implementation; the current evidence is insufficient for autonomous repair.

Review details

Best possible solution:

Implement LithosAI through the existing provider pipeline, using the plugin host where its verified data and authentication contract fit, while preserving provider-specific identity isolation.

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

Not applicable: this requests a new provider rather than reporting a failure of existing behavior.

Is this the best way to solve the issue?

Unclear until the service contract is verified; existing provider and plugin APIs offer a maintainable starting point without assuming inference API compatibility implies usage API compatibility.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• LithosAI’s usage or balance endpoint, response semantics, and required authentication have not been verified, so a bounded implementation cannot yet be specified.

Codex review notes: model internal, reasoning medium; reviewed against 3205b4bdc9f3.

Label changes

Label changes:

• add P3: This requests optional provider coverage without reporting broken existing functionality or a blocked setup.
• add issue-rating: 🌊 off-meta tidepool: 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:

• P3: This requests optional provider coverage without reporting broken existing functionality or a blocked setup.

Evidence reviewed

What I checked:

• Provider additions are explicitly supported: VISION.md welcomes new providers following existing descriptor, strategy, settings, and test patterns; additions requiring new host APIs or unclear authentication/privacy behavior need sign-off. (VISION.md:9, 3205b4bdc9f3)
• Current implementation does not register LithosAI: The complete provider enum contains no LithosAI entry, and searches across Sources, Tests, TestsPlugin, docs, README.md, and CHANGELOG.md returned no Lithos matches. (Sources/CodexBarCore/Providers/Providers.swift:21, 3205b4bdc9f3)
• Latest release registry checked: GitHub identifies v0.64.1 as the latest release, published September 22, 2026. Its provider enum also contains no LithosAI entry. (Sources/CodexBarCore/Providers/Providers.swift:21, dd71934ffc30)
• Existing extension path: Local provider plugins declare endpoints and authentication and return shared usage snapshots. This is a possible implementation path if LithosAI’s data source fits the existing HTTP host contract; it does not itself provide LithosAI support. (docs/plugins.md:11, 3205b4bdc9f3)
• External service contract remains unverified: The linked LithosAI website advertises hosted inference with API-key access. That page does not establish an account usage or balance endpoint. The documentation link could not be opened by the review tool, so its contents remain unknown.
• Discussion and canonical search: The supplied discussion contains the provider request and no substantive human follow-up. GitHub search returned no indexed Lithos matches, including this newly created issue, so the search does not conclusively establish that no related work exists.

Likely related people:

• Peter Steinberger: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

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.

[steipete]

LithosAI’s public billing documentation describes prepaid balances and dashboard reporting, but I could not find a documented API-key endpoint for balance or account usage. The published OpenAPI covers models and chat completions. Keeping this open pending a public reporting endpoint and response contract: https://docs.lithosai.com/billing.md

[apoorvdarshan]

Verified reporting endpoints and response contract

@steipete — following up on your note that this was blocked on a public reporting endpoint and response contract. The console does expose one; it just isn't in the published OpenAPI (which, as you found, only covers models and chat completions). I reverse-engineered it from the console bundle and have it working end to end in a small macOS menu bar app, so the contract below is verified against a live account rather than inferred.

Reference implementation: https://github.com/apoorvdarshan/lithosai-bar

Auth model

The session is browser-session based, not API-key based. The inference key (lith_sk_…) is rejected by every console endpoint. Auth needs the pair of cookies set by signing in at console.lithosai.cloud:

Cookie	Role
__Host-console_session	the session itself
__Host-console_csrf	must also be echoed as the X-Console-Csrf request header

Both are __Host- cookies on console.lithosai.cloud, so this fits the browser-cookies path with cookieDomains: ["console.lithosai.cloud"].

Endpoints

All GET, JSON, all under https://console.lithosai.cloud:

Endpoint	Returns
/api/me	account and active organization
/api/billing	balanceNanos, card state, reload config
/api/billing/spend?start=YYYY-MM-DD&end=YYYY-MM-DD	daily rows, per model, with token counts

start and end are both required; any other spelling (?days=, ?range=, ?from=) returns 400 {"error":"param_unknown"} / param_invalid. Rows are returned only for days that had activity, so the series is sparse.

Response shapes

/api/billing (trimmed):

{
  "balanceNanos": 4707099860,
  "billed": true,
  "floorNanos": 0,
  "hasCard": true,
  "onHold": false,
  "reload": { "enabled": false, "monthlyCapCents": null, "targetCents": null }
}

/api/billing/spend (trimmed):

{
  "days": [
    {
      "day": "2026-09-27",
      "modelId": "deepseek-ai/DeepSeek-V4.1-Flash",
      "apiKeyId": "baed3486-c07f-467b-b993-5b6de0400601",
      "nanos": 260066994,
      "inputTokens": 24942619,
      "cachedTokens": 23912448,
      "outputTokens": 56340
    }
  ],
  "start": "2026-09-20",
  "end": "2026-09-27"
}

/api/me (trimmed) — note activeOrganization.id, which the console sends as X-Organization-Id:

{
  "user": { "email": "…", "givenName": "…", "id": "…" },
  "activeOrganization": { "id": "311c17cc-…", "name": "…" },
  "platformRole": "user"
}

Money unit (the easy one to get wrong)

*Nanos fields are nanocents of a cent, i.e. 1 USD = 1e9. The console's own formatter treats a value below 1e7 as "less than $0.01", which pins it down:

function formatMoney(nanos) { return nanos > 0 && nanos < 1e7 ? "less than $0.01" : dollars(nanos) }

So balanceNanos: 4707099860 is $4.71, not $47.07 or $0.47. I got this wrong twice before deriving it from the bundle.

What a CodexBar plugin can map this to

There is no quota window, so usedPercent/resetsAt don't apply — the natural snapshot is a prepaid balance provider, in the shape /api/billing already provides:

• primary metric: balance remaining (the hasCard/onHold flags are worth surfacing)
• details rows: today's spend, this month's spend, tokens (cached/input/output), top models over the range

The one gap I could not solve inside the plugin manifest

The console requires X-Console-Csrf to match the __Host-console_csrf cookie value, and it must come from the same session as __Host-console_session. ctx.browser.cookieHeader(domain) returns a single header string, so a plugin would need to read that pair, send the session cookie as Cookie and echo the CSRF value as X-Console-Csrf.

That isn't the declared auth header, so unless opts.headers is permitted to carry an extra header here, a LithosAI plugin needs either:

• a way to derive one header from a declared-domain cookie value, or
• the CSRF cookie exposed alongside the session header.

Worth confirming before scoping. Everything else — declared origin, browser-cookies capability, cookie domain, manual-cookie fallback — fits the existing plugin contract as documented in docs/plugins.md.

rejectCookie on a 401 would map cleanly here too: an expired console session returns 401 {"error":"unauthenticated"}.

Happy to help test or answer questions about the contract. The repo above has the working parsing, the unit derivation, and the cookie decryption if it's useful as a reference.