AI Wrapper, built on every verified stack.
AI-wrapper app: per-user profile extending Better Auth, per-call token metering, and append-only prompt/completion history.
40 verified stacks
Showing 12 across 1 app types. Every stack page links its neighbours along each axis, so any combination is a click or two from here.
What AI Wrapper gives you
Three tables sit on top of the identity Better Auth owns, and the line between them is settings on one side, records of calls that already happened on the other. user_profiles is the 1:1 extension of the identity row: user_id is both a foreign key into user and a UNIQUE constraint, which is what makes it an extension rather than a collection, and it holds the two values the wrapper reads at call time — default_model (text, defaulting to gpt-4o-mini) and monthly_token_budget (bigint). token_usage takes one row per completed provider call: the model billed, the prompt/completion token split, and cost_microcents as a bigint, because a float accumulating over millions of sub-cent rows is how rounding error ends up in an invoice.
prompt_logs takes one row per exchange — prompt text, completion (nullable, so a streamed response can be logged before it finishes), latency_ms, a status narrowed by prompt_logs_status_check to 'ok', 'error' or 'filtered', and a JSON metadata bag that absorbs finish_reason, tool calls, and whatever else a provider invents, without forcing a column migration each time. The two append-only streams are deliberately not wired to each other. Both reference user.id directly and no key connects a usage row to the log row for the same call, so metering and logging fail independently on the hot path — the cost of that is you cannot ask what one specific prompt cost without matching on user and timestamp yourself.
What the streams do share is their index: idx_usage_user_time and idx_log_user_time are the same (user_id, created_at) composite, so every cheap question here has the shape of this user, this window. Fleet-wide reads get exactly two handles — idx_usage_model on the billed model and idx_profile_model on the profile default — and nothing else. There is no index on status, so a failure-rate query is a filter applied inside a user-and-time range. The budget is a number in a column rather than a constraint: nothing in the database refuses an over-budget call, so enforcement is a profile read plus a range sum you run before dispatch.
Built for
A range scan on token_usage through idx_usage_user_time (user_id, created_at), summing prompt_tokens plus completion_tokens and cost_microcents. user_id is the leading column, so the month boundary costs nothing beyond the range itself.
One probe of user_profiles on its UNIQUE user_id — the 1:1 foreign key into user — to read monthly_token_budget, compared against the idx_usage_user_time rollup. The bigint is a soft cap the dispatch path checks; no database constraint backs it.
idx_usage_model on token_usage.model groups spend by provider model id without touching user_profiles at all, and cost_microcents being an integer means the sum stays exact however many sub-cent rows it covers.
prompt_logs read back along idx_log_user_time (user_id, created_at), newest first. Prompt, completion, latency_ms and the JSON metadata all live on the row, so the feed renders from one index range with no join to token_usage.
status is held to three values by prompt_logs_status_check but carries no index of its own, so count it inside a bounded idx_log_user_time range rather than scanning prompt_logs by status across all users.
Why AI Wrapper, specifically
user_profiles.userId carries a UNIQUE constraint — it is the 1:1 extension of Better Auth's user row; the FK itself is the identity, so no separate join table is needed.
token_usage is append-only and stores cost as costMicrocents (bigint integer): no float money, fine-grained enough for sub-cent per-token pricing without a numeric type.