Skip to content

[Enhancement] Add usage and cost visibility for user-configured API keys #292

Description

@xingxingluolei

Problem

When users configure their own API keys, API usage and spending can feel like a black box. Users can hit provider-side billing failures such as 402 Insufficient Balance, but before that point there is no obvious in-app feedback about how much the configured key has been used or what the approximate spend is.

This makes it hard for users to build trust in BYOK mode and understand whether OpenLoomi is using their API key lightly or heavily.

Desired experience

Add API usage / cost visibility for user-configured API keys in two places:

  1. A detailed usage surface in the API provider settings page.
  2. A lightweight always-visible usage summary under the desktop Loomi Pet, so users can intuitively feel ongoing API consumption without opening settings.

The detailed settings view could include:

  • Current provider and model in use
  • Recent requests count
  • Input tokens, output tokens, and total tokens
  • Estimated cost by provider/model, with a clear “estimated” label
  • Usage over time, such as today / last 7 days / last 30 days
  • Last error related to quota/billing, if any
  • Optional provider billing link or guidance for checking the real provider balance

The desktop pet summary should stay compact and non-intrusive, for example:

  • Today: estimated $X / Y tokens
  • This session: estimated $X / Y tokens
  • Optional warning state when usage spikes or the provider reports quota/billing errors
  • Click-through to the detailed API usage page

For providers that expose a safe balance/quota API, OpenLoomi could optionally show live provider balance or quota. For providers that do not expose this consistently, OpenLoomi should still show local usage and estimated spend based on captured request usage.

Why this matters

  • Makes BYOK mode feel transparent instead of opaque.
  • Helps users notice unexpected spend early.
  • Makes provider-side billing/quota errors easier to understand.
  • Builds user trust, especially for scheduled jobs or background agent activity that may consume tokens outside a direct chat turn.
  • Puts lightweight cost awareness where users already look: the desktop Loomi Pet.

Implementation notes

Current code already has some adjacent pieces, but they appear focused on OpenLoomi credits rather than user-configured API key spend:

  • apps/web/hooks/use-billing-ledger.ts fetches OpenLoomi billing ledger entries.
  • apps/web/hooks/use-daily-usage.ts fetches OpenLoomi quota daily usage.
  • packages/ai/src/agent/types.ts includes raw SDK token usage on result messages.
  • packages/ai/src/agent/native-cli/index.ts has a cost field in native agent output.
  • packages/ai/src/agent/billing/model-pricing.ts contains model pricing logic that may help estimate costs.

A practical first version could record local BYOK usage events with fields like provider, model, timestamp, request id/session id, input tokens, output tokens, estimated cost, and error category. Then the UI can render a local usage ledger and trend summary.

The desktop pet can consume the same summarized usage data as the settings page, but should present only the most useful compact numbers and avoid turning the pet into a heavy dashboard.

Acceptance criteria

  • Users with a custom API key can see recent token usage and estimated cost in the API settings area.
  • A compact usage summary can be shown under the desktop Loomi Pet.
  • The pet summary links or navigates to the detailed usage view.
  • The UI clearly distinguishes estimated local spend from authoritative provider billing balance.
  • The feature works even when the provider does not expose a balance API.
  • Scheduled/background agent usage is included where possible.
  • The app does not expose raw API keys or sensitive provider response payloads in the usage UI.

Priority

Low priority. This is not required for the main happy path, but it improves trust, cost awareness, and recovery from provider billing/quota issues.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions