bunnyquery 1.8.6 → 1.8.8

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "bunnyquery",
-  "version": "1.8.6",
+  "version": "1.8.8",
   "description": "Embeddable BunnyQuery AI chat widget + its framework-agnostic chat engine",
   "main": "bunnyquery.js",
   "exports": {

package/src/engine/budget.ts

@@ -7,23 +7,81 @@
 import { sanitizeAttachmentLinksForHistory } from './links';
 
 export var CONTEXT_WINDOW_DEFAULT: Record<string, number> = { claude: 200000, openai: 128000 };
-// Exact model ids first, then family keys (see getContextWindow: a suffixed id
-// falls back to its family rather than to the platform default). Claude figures
-// come from Anthropic's published model table; `max_input_tokens` from
+// Exact model ids first, then family keys (see getModelContextWindow: a suffixed
+// id falls back to its family rather than to the platform default). Claude
+// figures come from Anthropic's published model table; `max_input_tokens` from
 // /v1/models overrides all of this at runtime when a listing has been seen.
-// 'claude-opus-4-7' read 200000 here, which was wrong by 5x, and the default
-// Claude model 'claude-sonnet-4-6' was absent entirely so it fell through to
-// CONTEXT_WINDOW_DEFAULT.claude. Neither was observable, because the history
-// budget and the Claude per-request cap below bind long before the window does.
+// OpenAI's /v1/models carries NO context field at all, so every gpt entry here
+// is hand-maintained and is the only source for those models.
+// These are TOTAL windows (input + output), which is what the published tables
+// report and what getInputTokenBudget assumes when it subtracts the output
+// reserve. The two readings reconcile: gpt-5.6-luna is 1,050,000 total with a
+// 128,000 output cap, i.e. the ~922,000 of usable input quoted for it elsewhere.
 export var CONTEXT_WINDOW_BY_MODEL: Record<string, number> = {
-	// exact ids
-	'claude-opus-5': 1000000, 'claude-opus-4-8': 1000000, 'claude-opus-4-7': 1000000,
-	'claude-sonnet-5': 1000000, 'claude-sonnet-4-6': 1000000, 'claude-sonnet-4': 200000,
-	'claude-haiku-4-5': 200000, 'gpt-5.4': 128000, 'gpt-5.6-luna': 128000,
+	// claude, exact ids
+	'claude-fable-5': 1000000, 'claude-opus-5': 1000000,
+	'claude-opus-4-8': 1000000, 'claude-opus-4-7': 1000000,
+	'claude-opus-4-6': 1000000, 'claude-opus-4-5': 200000,
+	'claude-sonnet-5': 1000000, 'claude-sonnet-4-6': 1000000,
+	'claude-sonnet-4-5': 1000000, 'claude-sonnet-4': 200000,
+	'claude-haiku-4-5': 200000, 'claude-3-5-sonnet': 200000,
+	// openai, exact ids
+	'gpt-5.6-sol': 1050000, 'gpt-5.6-terra': 1050000, 'gpt-5.6-luna': 1050000,
+	'gpt-5.5': 1000000, 'gpt-5.4': 1050000,
+	'gpt-5.4-mini': 400000, 'gpt-5.4-nano': 400000,
+	'gpt-4.1': 1040000, 'gpt-4o': 128000, 'o1': 200000, 'o1-pro': 200000,
 	// family keys
-	'claude-opus': 1000000, 'claude-sonnet': 1000000, 'claude-haiku': 200000,
-	'gpt-5.6': 128000, 'gpt-5': 128000,
+	'claude-fable': 1000000, 'claude-opus': 1000000, 'claude-sonnet': 1000000,
+	'claude-haiku': 200000, 'gpt-5.6': 1050000, 'gpt-5': 128000,
 };
+// Two rows above are load-bearing rather than redundant, both because the family
+// walk drops trailing segments:
+//   'claude-opus-4-5' — a dated id like 'claude-opus-4-5-20251101' would
+//     otherwise walk past it to the 'claude-opus' family and resolve 1000000 for
+//     a model whose real window is 200000.
+//   'gpt-5.4-mini' and 'gpt-5.4-nano' — would otherwise walk to 'gpt-5.4' and
+//     resolve 1050000 instead of their actual 400000. nano is the one that
+//     matters most in practice: the indexing path selects it by name.
+// The bare 'gpt-5' family stays deliberately low: it is the catch-all for gpt-5
+// variants not listed here, and a mini-class variant is the likelier unknown.
+//
+// One asymmetry these rows expose: a total minus our output reserve can exceed a
+// model's separately-published INPUT ceiling (gpt-5.4-nano is 400000 total but
+// caps input at 272000, where 400000 - 25000 - 4000 reads as 371000). Harmless
+// today because INPUT_CAP_RATIO binds far below either figure (59360 for nano),
+// but it is why the ratio is not something to remove.
+
+// Provider hard ceilings on output tokens per request. Only used to clamp what
+// we ask for (see getMaxOutputTokens) — we never request more than
+// MAX_OUTPUT_TOKENS anyway, so this matters exactly where a model's cap is
+// BELOW that: gpt-4o at 4000 and legacy 3.5 Sonnet at 8000 would reject the
+// flat 25000 the request builder used to send unconditionally.
+export var MAX_OUTPUT_BY_MODEL: Record<string, number> = {
+	// claude
+	'claude-fable-5': 128000, 'claude-opus-5': 128000,
+	'claude-opus-4-8': 128000, 'claude-sonnet-5': 128000,
+	'claude-sonnet-4-6': 64000, 'claude-haiku-4-5': 64000,
+	'claude-3-5-sonnet': 8000,
+	// openai
+	'gpt-5.6-sol': 128000, 'gpt-5.6-terra': 128000, 'gpt-5.6-luna': 128000,
+	'gpt-5.5': 128000, 'gpt-5.4': 128000,
+	'gpt-5.4-mini': 128000, 'gpt-5.4-nano': 128000,
+	'gpt-4.1': 16000, 'gpt-4o': 4000, 'o1': 100000, 'o1-pro': 100000,
+	// family keys
+	'claude-fable': 128000, 'claude-opus': 128000, 'claude-sonnet': 64000,
+	'claude-haiku': 64000, 'gpt-5.6': 128000, 'gpt-5': 128000,
+};
+
+// The window a project runs at when nobody has touched the setting, clamped per
+// model by getContextWindow. Deliberately BELOW every frontier ceiling it can
+// resolve against (1,000,000 on the Claude 5 line, 1,050,000 on gpt-5.6) because
+// the client-side budget covers only the FIRST request: after that the model
+// runs a server-side tool loop whose web_fetch and MCP results accumulate in the
+// same conversation and are not counted here. The gap (120k and 170k
+// respectively) is that loop's room. It matters because no compaction beta is
+// enabled, so overrunning the real window is a hard error, not a graceful
+// degrade.
+export var DEFAULT_CONTEXT_WINDOW = 880000;
 
 // Context windows reported by a provider's own models listing, keyed by model id.
 // Anthropic's GET /v1/models returns `max_input_tokens` per model, which is the
@@ -31,21 +89,35 @@ export var CONTEXT_WINDOW_BY_MODEL: Record<string, number> = {
 // OpenAI models resolve from the table above. Populated by
 // registerModelContextWindows() when a client fetches its model list.
 var apiReportedContextWindows: Record<string, number> = {};
+var apiReportedMaxOutput: Record<string, number> = {};
 
 /**
- * Record context windows from a provider models listing. Accepts the raw list
- * items and reads `max_input_tokens` (Anthropic); items without it are skipped,
- * so passing an OpenAI listing is a no-op rather than an error.
+ * Record context windows and output caps from a provider models listing. Reads
+ * `max_input_tokens` and `max_tokens` (Anthropic); items without them are
+ * skipped, so passing an OpenAI listing is a no-op rather than an error.
+ *
+ * Note the asymmetry against the static table: Anthropic reports
+ * `max_input_tokens` (input only) where CONTEXT_WINDOW_BY_MODEL holds totals, so
+ * a registered Claude window is treated as a total and loses its output cap
+ * worth of budget. That is deliberate — under-spending the window is safe, and
+ * with no compaction beta enabled overrunning it is a hard error.
  */
-export function registerModelContextWindows(models: Array<{ id?: string; max_input_tokens?: number }> | null | undefined): void {
+export function registerModelContextWindows(
+	models: Array<{ id?: string; max_input_tokens?: number; max_tokens?: number }> | null | undefined,
+): void {
 	if (!Array.isArray(models)) return;
 	for (var i = 0; i < models.length; i++) {
 		var m = models[i];
 		var id = (m && m.id ? String(m.id) : '').trim().toLowerCase();
+		if (!id) continue;
 		var reported = m ? Number(m.max_input_tokens) : NaN;
-		if (id && Number.isFinite(reported) && reported > 0) {
+		if (Number.isFinite(reported) && reported > 0) {
 			apiReportedContextWindows[id] = Math.floor(reported);
 		}
+		var out = m ? Number(m.max_tokens) : NaN;
+		if (Number.isFinite(out) && out > 0) {
+			apiReportedMaxOutput[id] = Math.floor(out);
+		}
 	}
 }
 
@@ -64,18 +136,37 @@ export function getProjectContextWindow(projectId: string): number | null {
 	var key = (projectId || '').trim();
 	return key && projectContextWindows[key] ? projectContextWindows[key] : null;
 }
-export var OUTPUT_TOKEN_RESERVE = 22000;
+// `max_tokens` sent on every chat request. Exported so the reserve below and the
+// actual request cannot drift: they were 22000 and 25000 respectively, which
+// under-reserved by 3k on a window spent to the last token.
+export var MAX_OUTPUT_TOKENS = 25000;
+export var OUTPUT_TOKEN_RESERVE = MAX_OUTPUT_TOKENS;
 export var TOOL_AND_RESPONSE_BUFFER = 4000;
 export var MIN_INPUT_TOKEN_BUDGET = 8000;
-export var CLAUDE_PER_REQUEST_INPUT_CAP = 28000;
+// Floor under INPUT_CAP_RATIO. Anthropic's default tier enforces 30,000 input
+// tokens per MINUTE on Opus, which is where the number comes from; it is applied
+// on OpenAI too so a small-window model keeps a usable attachment budget instead
+// of collapsing to the ratio.
+export var MIN_PER_REQUEST_INPUT_CAP = 28000;
+/** @deprecated renamed to {@link MIN_PER_REQUEST_INPUT_CAP} (no longer Claude-only). */
+export var CLAUDE_PER_REQUEST_INPUT_CAP = MIN_PER_REQUEST_INPUT_CAP;
 export var MAX_HISTORY_MESSAGES = 20;
 export var HISTORY_TOKEN_BUDGET = 8000;
 // Ratios that scale the two ceilings above off the resolved context window.
-// Calibrated to reproduce the previous fixed values at the default windows:
-// claude 200000 -> cap 27840 (was 28000, so the 28000 floor holds), and
-// openai 128000 -> history 8160 (~the previous 8000). Both are floored at the
-// old constants, so these can only ever raise a budget, never lower one.
-export var CLAUDE_INPUT_CAP_RATIO = 0.16;
+// Originally calibrated to reproduce the previous fixed values at the old
+// default windows (claude 200000 -> cap 27840, openai 128000 -> history 8160).
+// Both are floored at the old constants, so they can only ever raise a budget,
+// never lower one, which is what keeps a small-window model (claude-opus-4-5 at
+// 200000) behaving as it always did.
+//
+// INPUT_CAP_RATIO now applies to BOTH platforms. It was Claude-only because it
+// encoded a Claude rate limit, but at a 880000 default it does a second job that
+// matters just as much on OpenAI: it is the headroom. Uncapped, gpt-5.6-luna
+// resolved an input budget of 851000 against a 922000 ceiling, leaving 71000 for
+// the whole server-side tool loop, and ONE web_fetch result can be 200000.
+export var INPUT_CAP_RATIO = 0.16;
+/** @deprecated renamed to {@link INPUT_CAP_RATIO} (no longer Claude-only). */
+export var CLAUDE_INPUT_CAP_RATIO = INPUT_CAP_RATIO;
 export var HISTORY_BUDGET_RATIO = 0.08;
 
 export function estimateTextTokens(text: string): number {
@@ -87,34 +178,91 @@ export function estimateMessageTokens(msg: { role: string; content: string }): n
 }
 
 /**
- * Resolve a model's context window, most specific source first:
- *   1. per-project override (project settings)
- *   2. the provider's own models listing (Anthropic `max_input_tokens`)
- *   3. an exact entry in CONTEXT_WINDOW_BY_MODEL
- *   4. a family entry, by dropping trailing '-' segments off the id
- *   5. the platform default
+ * The model's own HARD ceiling: the largest window it can be asked for at all.
+ * Resolved most specific source first:
+ *   1. the provider's own models listing (Anthropic `max_input_tokens`)
+ *   2. an exact entry in CONTEXT_WINDOW_BY_MODEL
+ *   3. a family entry, by dropping trailing '-' segments off the id
+ *   4. the platform default
  *
- * Step 4 is why a new or suffixed id no longer drops straight to the platform
+ * Step 3 is why a new or suffixed id no longer drops straight to the platform
  * default: 'gpt-5.6-luna' resolves via 'gpt-5.6', and a dated Claude snapshot
  * such as 'claude-opus-4-7-20260101' resolves via 'claude-opus-4-7'. The walk
  * stops at the first hit, so a more specific entry always wins over its family.
+ *
+ * This is what the settings UI offers presets against; it is NOT what a request
+ * is budgeted at. For that see getContextWindow.
+ */
+/**
+ * Shared id resolution for both per-model tables: provider listing, then exact
+ * table entry, then family entries by dropping trailing '-' segments. Returns 0
+ * when nothing matches so callers can apply their own default.
+ */
+function resolveByModelId(
+	apiTable: Record<string, number>,
+	staticTable: Record<string, number>,
+	model?: string,
+): number {
+	var normalized = (model || '').trim().toLowerCase();
+	if (!normalized) return 0;
+	if (apiTable[normalized]) return apiTable[normalized];
+	if (staticTable[normalized]) return staticTable[normalized];
+	var parts = normalized.split('-');
+	for (var end = parts.length - 1; end > 0; end--) {
+		var family = parts.slice(0, end).join('-');
+		if (staticTable[family]) return staticTable[family];
+	}
+	return 0;
+}
+
+export function getModelContextWindow(platform: string, model?: string): number {
+	return resolveByModelId(apiReportedContextWindows, CONTEXT_WINDOW_BY_MODEL, model)
+		|| CONTEXT_WINDOW_DEFAULT[platform];
+}
+
+/**
+ * How many output tokens to ask for. We never want more than MAX_OUTPUT_TOKENS,
+ * but a model whose own cap is lower rejects the request outright, so clamp to
+ * whichever is smaller. Models with no known cap keep MAX_OUTPUT_TOKENS.
+ */
+export function getMaxOutputTokens(platform: string, model?: string): number {
+	var cap = resolveByModelId(apiReportedMaxOutput, MAX_OUTPUT_BY_MODEL, model);
+	return cap ? Math.min(MAX_OUTPUT_TOKENS, cap) : MAX_OUTPUT_TOKENS;
+}
+
+/**
+ * The window a request is actually budgeted at: the per-project override when
+ * one is set, otherwise DEFAULT_CONTEXT_WINDOW. Both are clamped to the model's
+ * hard ceiling, because a budget above the ceiling builds a request the provider
+ * rejects, and a stored override outlives the model it was chosen under.
  */
 export function getContextWindow(platform: string, model?: string, projectId?: string): number {
+	var ceiling = getModelContextWindow(platform, model);
 	var override = projectId ? getProjectContextWindow(projectId) : null;
-	if (override) return override;
+	return Math.min(override || DEFAULT_CONTEXT_WINDOW, ceiling);
+}
 
-	var normalized = (model || '').trim().toLowerCase();
-	if (normalized) {
-		if (apiReportedContextWindows[normalized]) return apiReportedContextWindows[normalized];
-		if (CONTEXT_WINDOW_BY_MODEL[normalized]) return CONTEXT_WINDOW_BY_MODEL[normalized];
-
-		var parts = normalized.split('-');
-		for (var end = parts.length - 1; end > 0; end--) {
-			var family = parts.slice(0, end).join('-');
-			if (CONTEXT_WINDOW_BY_MODEL[family]) return CONTEXT_WINDOW_BY_MODEL[family];
-		}
-	}
-	return CONTEXT_WINDOW_DEFAULT[platform];
+/**
+ * Per-request input-token budget, i.e. how much of the resolved window this turn
+ * may spend on system prompt + history + the latest message. The single
+ * implementation behind both buildBoundedChatMessages and the composer's
+ * pre-send guard, which used to be separate copies that disagreed.
+ */
+/**
+ * The share of the resolved window left after reserving what this request may
+ * emit. The reserve is per-model rather than the flat OUTPUT_TOKEN_RESERVE
+ * because getMaxOutputTokens clamps small-cap models below it.
+ */
+function contextBasedBudgetFor(platform: string, model?: string, projectId?: string): number {
+	var contextWindow = getContextWindow(platform, model, projectId);
+	return Math.max(MIN_INPUT_TOKEN_BUDGET,
+		contextWindow - getMaxOutputTokens(platform, model) - TOOL_AND_RESPONSE_BUFFER);
+}
+
+export function getInputTokenBudget(platform: string, model?: string, projectId?: string): number {
+	var contextBasedBudget = contextBasedBudgetFor(platform, model, projectId);
+	return Math.min(contextBasedBudget,
+		Math.max(MIN_PER_REQUEST_INPUT_CAP, Math.round(contextBasedBudget * INPUT_CAP_RATIO)));
 }
 
 export function stripFileBlocksFromHistory(content: string): string {
@@ -132,33 +280,24 @@ export type BoundedChatOptions = {
 };
 
 export function buildBoundedChatMessages(options: BoundedChatOptions) {
-	var contextWindow = getContextWindow(options.platform, options.model, options.projectId);
-	var contextBasedBudget = Math.max(MIN_INPUT_TOKEN_BUDGET,
-		contextWindow - OUTPUT_TOKEN_RESERVE - TOOL_AND_RESPONSE_BUFFER);
-	// Scaling is gated on an EXPLICIT per-project window set from project
-	// settings. Without one, the fixed ceilings apply exactly as before, so every
-	// existing project keeps byte-identical behavior and nobody's token spend
-	// moves because a table value was corrected. With one, the Claude per-request
-	// cap and the history budget scale off the window, so raising it genuinely
-	// sends more history instead of being absorbed by a hardcoded ceiling.
-	// Both derive from contextBasedBudget (pre-Claude-cap) so the two platforms
-	// scale symmetrically rather than the Claude cap compounding the ratio down.
-	var scaled = !!(options.projectId && getProjectContextWindow(options.projectId));
-	var claudeInputCap = scaled
-		? Math.max(CLAUDE_PER_REQUEST_INPUT_CAP, Math.round(contextBasedBudget * CLAUDE_INPUT_CAP_RATIO))
-		: CLAUDE_PER_REQUEST_INPUT_CAP;
-	var availableInputBudget = options.platform === 'claude'
-		? Math.min(contextBasedBudget, claudeInputCap) : contextBasedBudget;
+	var contextBasedBudget = contextBasedBudgetFor(options.platform, options.model, options.projectId);
+	// Scaling used to be gated on an EXPLICIT per-project override so that a
+	// project nobody had configured kept the old fixed ceilings. That gate is
+	// gone now that DEFAULT_CONTEXT_WINDOW is itself the default: leaving it in
+	// would mean an unconfigured project resolved 880000 and then spent 28000 of
+	// it, making the new default purely cosmetic, and would keep the trap where
+	// "Default (880K)" and an explicit 880K behaved differently.
+	// Both ceilings derive from contextBasedBudget (pre-Claude-cap) so the two
+	// platforms scale symmetrically rather than the Claude cap compounding down.
+	var availableInputBudget = getInputTokenBudget(options.platform, options.model, options.projectId);
 	var systemCost = estimateTextTokens(options.systemPrompt) + 12;
-	var historyAllowance = scaled
-		? Math.max(HISTORY_TOKEN_BUDGET, Math.round(contextBasedBudget * HISTORY_BUDGET_RATIO))
-		: HISTORY_TOKEN_BUDGET;
+	var historyAllowance = Math.max(HISTORY_TOKEN_BUDGET,
+		Math.round(contextBasedBudget * HISTORY_BUDGET_RATIO));
 	var budgetForHistory = Math.max(1000, Math.min(historyAllowance, availableInputBudget - systemCost));
 	// The message count scales alongside the token budget; otherwise 20 messages
 	// is a second ceiling that swallows the extra budget on a raised window.
-	var maxHistoryMessages = scaled
-		? Math.max(MAX_HISTORY_MESSAGES, Math.round(MAX_HISTORY_MESSAGES * (budgetForHistory / HISTORY_TOKEN_BUDGET)))
-		: MAX_HISTORY_MESSAGES;
+	var maxHistoryMessages = Math.max(MAX_HISTORY_MESSAGES,
+		Math.round(MAX_HISTORY_MESSAGES * (budgetForHistory / HISTORY_TOKEN_BUDGET)));
 	var windowed = options.history.slice(-maxHistoryMessages);
 	var latestIndex = windowed.length - 1;
 	var trimmed = windowed.map(function (m, i) {

package/src/engine/config.ts

@@ -47,6 +47,54 @@ export interface ChatEngineConfig {
      * until the worker is deployed, then flip it per environment.
      */
     windowedIndexing?: boolean;
+    /**
+     * Mint the durable "indexing finished" marker record ("done::<path>",
+     * reference "src::<path>", table __INDEXING__ — same shape the backend
+     * worker writes via /internal/index-complete) for runs whose completion
+     * THIS CLIENT knows deterministically: a single-pass file's settled pass,
+     * or a client-driven chain whose reply carried the completion token.
+     * Worker-driven chains are NOT minted from the client (their completion is
+     * only ever inferred here); the worker writes their marker itself.
+     * Must be best-effort: tolerate the marker already existing and never
+     * throw. Optional so older consumers keep the pre-marker inference.
+     */
+    mintIndexDoneMarker?: (info: { service: string; storagePath: string }) => void;
+    /**
+     * Create-or-update the per-file indexing RUN record ("run::<path>",
+     * reference "src::<path>", table __INDEXING__). The record is the durable
+     * "a run exists and this is its status" signal that lets chat rows and
+     * files-page badges paint without scanning bg history.
+     *
+     * The consumer implements upsert semantics (the records API has none):
+     * create, and on "is already taken" look the record up by unique_id and
+     * re-post with its record_id, merging `patch` over the stored data.
+     * Status precedence is the consumer's job too: 'working' must NEVER
+     * overwrite a terminal status (done/error/cancelled) — a late create from
+     * a slow enqueue must not resurrect a run another writer already closed.
+     * Must be best-effort and never throw. Optional: without it the engine
+     * behaves exactly as before (legacy scan/probe path).
+     */
+    upsertIndexRunRecord?: (info: {
+        service: string;
+        storagePath: string;
+        patch: {
+            status: 'working' | 'done' | 'error' | 'cancelled';
+            filename?: string;
+            started?: number;
+            finished?: number;
+            error?: string;
+            queue?: string;
+        };
+    }) => void;
+    /**
+     * Single-item csr-poll point lookup (skapi.util.request('csr-poll', {id,
+     * service, owner}, {auth:true})). For a RESOLVED item the backend returns
+     * the provider response body itself; for a failed one, the resolved error.
+     * Used by ChatSession.hydrateCompactItems to fetch the real bodies of
+     * compact history stubs when the user expands an indexing row. Optional:
+     * without it, stubs keep their server-extracted heads.
+     */
+    csrHistoryItemLookup?: (fullId: string, service: string, owner: string) => Promise<any>;
 }
 
 let _config: ChatEngineConfig | null = null;

package/src/engine/errors.ts

@@ -139,3 +139,41 @@ export function isAuthExpiredError(input: any): boolean {
 		hay.indexOf('unauthorized') !== -1 || hay.indexOf('not authorized') !== -1 ||
 		(hay.indexOf('invalid_request') !== -1 && hay.indexOf('token') !== -1);
 }
+
+/**
+ * True when the AI PROVIDER rejected the project's own API key.
+ *
+ * Deliberately narrow, and deliberately NOT the same question as
+ * isAuthExpiredError: that one is about OUR session/MCP bearer going stale,
+ * which the client fixes by refreshing and resending. This one means the key
+ * the project owner pasted is wrong or revoked, which only a human can fix.
+ *
+ * A bare 401 is NOT enough to conclude it (the MCP bearer expiring is also a
+ * 401), so this matches only the provider's key-specific markers:
+ *   Anthropic -> `authentication_error`, "invalid x-api-key"
+ *   OpenAI    -> `invalid_api_key`, "Incorrect API key provided"
+ * Accepts a response object, a thrown error, or the message string those get
+ * reduced to by getErrorMessage, because the view usually only keeps the text.
+ */
+export function isProviderApiKeyError(input: any): boolean {
+	if (!input) return false;
+	var blobs: string[] = [];
+	var push = function (v: any) { if (typeof v === 'string' && v) blobs.push(v); };
+	if (typeof input === 'string') push(input);
+	else {
+		push(input.message); push(input.code); push(input.type);
+		if (input.error) { push(input.error.message); push(input.error.code); push(input.error.type); }
+		if (input.body) {
+			push(input.body.message); push(input.body.type);
+			if (input.body.error) { push(input.body.error.message); push(input.body.error.code); push(input.body.error.type); }
+		}
+	}
+	var hay = blobs.join(' | ').toLowerCase();
+	if (!hay) return false;
+	return hay.indexOf('authentication_error') !== -1 ||
+		hay.indexOf('invalid_api_key') !== -1 ||
+		hay.indexOf('invalid x-api-key') !== -1 ||
+		hay.indexOf('incorrect api key') !== -1 ||
+		hay.indexOf('invalid api key') !== -1 ||
+		hay.indexOf('no api key provided') !== -1;
+}