Proposal: prepaid tool-wallet provider interface (apifare as first implementation)

Author: iamalanluiCreated Sep 12, 2026Updated Sep 12, 2026

Problem

When an agent/chat session needs a paid capability (search, scraping, filings, imagery), today each end user must create a provider account, generate a key, and paste it — per provider. For tool calls (as opposed to LLM calls, where prepaid pools like OpenRouter solved this), there's no equivalent: costs either land on the app operator or the feature stays off.

Proposal: a generic "tool wallet" provider interface

A small interface — deliberately not a vendor bolt-on — that lets an end user connect a prepaid tool balance to their account:

  • connect(credentials) — user links a wallet (bearer token or OAuth).
  • call(tool, params) — eligible tool calls route through the wallet's metering endpoint; the wallet debits per call at a disclosed price.
  • balance() — remaining credit, for display.
  • 402 handling — when the balance is empty the wallet returns a structured payment-required result (human-readable line + top-up URL + caps context) that the app surfaces in-chat; the user tops up and the task resumes. Failed provider calls are refunded by the wallet.
  • Spend guardrails live wallet-side (per-agent caps, kill switch, signed audit log), so the app never touches money.

Why SillyTavern specifically

Your OpenRouter docs already sell exactly this pattern for LLM calls — one key, prepaid credit pool. Tool/extension calls have no equivalent: each user pastes per-provider keys. And because provider error JSON surfaces nearly verbatim via toastr, the wallet's structured 402 (human-readable line + top-up URL) relays in-chat with zero code today. The clean fit looks like a UI extension (wallet connect + balance + top-up affordance); posting here first per the "talk to maintainers first" convention — also happy to bring this to Discord if that's the better venue.

What I'm asking

Does the generic interface fit, and is an extension the right shape? If there's interest — or no objection — I'll build it against staging per your process.