tben
d9aea8e9c8
Nothing anywhere recorded what a model call cost: the harness used a provider's usage numbers only to decide whether a turn had finished, then dropped them. So a reply could not say what it took to make, one model could not be compared with another on price, and there was no way to ask what a day, a week or a month of the crew's work came to. - `token_usages` records one row per call: user, bot, workspace, session, job and message, the harness, the provider and model that actually answered, the prompt and completion counts, and the cost when the provider reports one. - `harness-usage-scope.ts` carries those ids in an AsyncLocalStorage scope that `run-bot-job.ts` enters once, so a run's turns, its session summary, its transcriptions, images and embeddings are all attributed without threading ids through every harness function. Nested runs merge rather than replace, and a null genuinely clears a field (a bot's own chat has no workspace). - Work with no run behind it is charged to its owner instead: `run-with-fallback-scope.ts` reaches the workspace's creator else the bot's, and deliberately does not override a real run, so an ingest a bot asked for is not misattributed to the bot's owner. - All six harnesses record through `withCandidates`'s `on_success`. Recording never throws: a model that answered must not lose its answer to a failed insert. - A job's calls land before its message exists, so `complete-bot-job.ts` back-fills `message_id` once the message is inserted. - The message's actions row shows what it cost, beside the timestamp and the play button, with the breakdown in its title. - `/admin/usage` totals the install's spending for 7, 30 or 90 days: the total against the previous period, a day-by-day chart, a split per kind of call, and a table per model with the price per thousand tokens worked out from cost and tokens, which is what makes two models comparable. Crew managers only, since it is the whole install's work rather than one user's conversation. It sits with Routines and Activity in the user popover rather than under Settings, because it is a record of what happened, not something to configure. Days are grouped in local time (`date(created_at / 1000, 'unixepoch', 'localtime')`), matching the local midnights the window builds and the `YYYY-MM-DD` buckets it looks up. Grouping by the bare UTC day put a late evening's calls under a name no bucket carried, so they vanished and the chart's total silently disagreed with the totals card; a test pins it. `canSeeRailItem` now decides who sees a popover or rail entry. The two each filtered with their own inline rule and only one understood `can_view`, so a gated page could be offered in the popover to everyone.
99 lines
3.2 KiB
TypeScript
99 lines
3.2 KiB
TypeScript
import type { BUN_SQLITE_COBBLE_BOT_MESSAGES } from "@/db/types/db";
|
|
import type { BotMessageWithAttachments } from "@/src/types";
|
|
import BunSQLite from "@moduletrace/bun-sqlite";
|
|
import grabMessageUsage from "../usage/grab-message-usage";
|
|
import grabMessagesMedia from "./grab-messages-media";
|
|
import grabMessagesReactions from "./grab-messages-reactions";
|
|
import grabMessagesReplies from "./grab-messages-replies";
|
|
import mediaToAttachment, { grabAttachmentFileIds } from "./media-to-attachment";
|
|
|
|
type Params = {
|
|
session_id: number | string;
|
|
limit?: number;
|
|
/**
|
|
* Only messages older than this one, for loading further back.
|
|
*/
|
|
before_id?: number | null;
|
|
/**
|
|
* Whose conversation it is, so a reaction can show as the user's own.
|
|
* Left out for the bot's own history reads, which don't need it.
|
|
*/
|
|
user_id?: number | string;
|
|
};
|
|
|
|
/**
|
|
* The latest messages of a session (or the latest before `before_id`),
|
|
* oldest first, with their attachments,
|
|
* what each replies to, and (when `user_id` is given) its reactions.
|
|
*/
|
|
export default async function grabBotMessages({
|
|
session_id,
|
|
limit = 100,
|
|
before_id,
|
|
user_id,
|
|
}: Params): Promise<BotMessageWithAttachments[]> {
|
|
let sql = ``;
|
|
|
|
sql += `SELECT * FROM (\n`;
|
|
sql += ` SELECT * FROM bot_messages\n`;
|
|
sql += ` WHERE session_id = ?\n`;
|
|
|
|
if (before_id) {
|
|
sql += ` AND (created_at, id) < (SELECT created_at, id FROM bot_messages WHERE id = ?)\n`;
|
|
}
|
|
|
|
sql += ` ORDER BY created_at DESC, id DESC\n`;
|
|
sql += ` LIMIT ?\n`;
|
|
sql += `) ORDER BY created_at ASC, id ASC\n`;
|
|
|
|
const res = await BunSQLite.sql<BUN_SQLITE_COBBLE_BOT_MESSAGES>({
|
|
sql,
|
|
values: before_id ? [session_id, before_id, limit] : [session_id, limit],
|
|
});
|
|
|
|
const messages = res.payload || [];
|
|
const message_ids = messages.map((message) => Number(message.id));
|
|
|
|
const [media, replies, reactions, usage] = await Promise.all([
|
|
grabMessagesMedia({ message_ids }),
|
|
grabMessagesReplies({ message_ids }),
|
|
user_id
|
|
? grabMessagesReactions({ message_ids, user_id })
|
|
: Promise.resolve(new Map()),
|
|
grabMessageUsage({ message_ids }),
|
|
]);
|
|
|
|
/**
|
|
* Files that live in a bot's folder carry their `bot_files` id, so a
|
|
* chip opens the file rather than only its bytes.
|
|
*/
|
|
const file_ids = await grabAttachmentFileIds({
|
|
media_ids: [...media.values()].flat().map((file) => Number(file.id)),
|
|
});
|
|
|
|
return messages.map((message) => {
|
|
const id = Number(message.id);
|
|
const files = media.get(id);
|
|
const reply_to = replies.get(id);
|
|
|
|
const spent = usage.get(id);
|
|
|
|
return {
|
|
...message,
|
|
...(files
|
|
? {
|
|
attachments: files.map((file) =>
|
|
mediaToAttachment({
|
|
media: file,
|
|
file_id: file_ids.get(Number(file.id)),
|
|
}),
|
|
),
|
|
}
|
|
: {}),
|
|
...(reply_to ? { reply_to } : {}),
|
|
...(user_id ? { reactions: reactions.get(id) || [] } : {}),
|
|
...(spent ? { usage: spent } : {}),
|
|
};
|
|
});
|
|
}
|