@danypops/jittor 0.11.0 → 0.12.1

package/README.md

@@ -1,90 +1,41 @@
-# Jittor
+# @danypops/jittor
 
-**Just-in-Time Token Optimizing Router** for Pi.
-
-Jittor observes provider budgets and per-turn usage, computes whether the current burn rate is sustainable, and applies a deterministic policy before each model request:
-
-1. continue
-2. throttle
-3. lower thinking
-4. switch model
-5. switch provider
-6. halt
-
-Initial telemetry providers:
-
-- ChatGPT-authenticated Codex subscription usage
-- OpenRouter API key usage, response accounting, and model pricing
-- Anthropic official per-response rate-limit headers (requests, tokens, input/output tokens, and optional Priority Tier buckets)
-- Google Vertex AI classified failure pressure (quota/auth/invalid-request/overload/transport), since Vertex has no documented remaining-budget header or personal polling endpoint
-
-Jittor follows the Papyrus daemon architecture: a supervised Bun service owns SQLite and provider polling; the native Pi extension uses an authenticated loopback client and applies model/thinking decisions.
+Supervised Bun daemon, router policy, provider telemetry adapters, and CLI for Jittor. See the [repo root README](../../README.md) for the two-package overview and [`@danypops/pi-jittor`](../pi-jittor) for the Pi extension that talks to this daemon.
 
 ## Architecture
 
-The initial service scaffold is split into domain, ports, and adapters:
-
 - `src/domain/metric.ts` — normalized timestamped metric observations
 - `src/ports/metric-store.ts` — storage boundary used by the application service
 - `src/adapters/sqlite-metric-store.ts` — SQLite time-series adapter
 - `src/service.ts` — authenticated operation registry
 - `src/client.ts` — operation-typed loopback client
 - `src/daemon.ts` — Bun composition root and maintenance loop
+- `src/index.ts` — the package's public surface: everything `@danypops/pi-jittor` (or any other consumer) imports
 
 SQLite runs in WAL mode with versioned migrations, JSON validation, bounded queries, chronological indexes, pruning, and checkpoints. The database follows `XDG_DATA_HOME`; private authentication state follows `XDG_STATE_HOME`; the daemon handle follows `XDG_RUNTIME_DIR`.
 
 Operations currently include bounded metric recording/query/pruning, benchmark refresh/status/query, context assessment, routing control, telemetry polling, and service checkpointing. Every operation is exposed through the authenticated typed client; benchmark operations also have CLI parity.
 
-Provider adapters currently include official OpenRouter key/usage/model telemetry and an explicitly experimental Codex subscription adapter. The Codex adapter follows the pinned open-source CLI `/wham/usage` payload and `x-codex-*` response-header contracts, accepts additional metered limits, and fails closed on malformed windows or impossible percentages. File credentials must be explicitly configured and private (`0600`); Jittor reads only the access token and account ID, never refreshes credentials, and never logs or persists OAuth secrets. Anthropic has no personal-account polling endpoint (its Admin/Rate Limits API is documented as unavailable for individual accounts), so Jittor instead reads the official `anthropic-ratelimit-*` response headers Pi observes on every Messages API call and fails closed on schema drift the same way. Google Vertex AI has neither a personal polling endpoint nor a documented remaining-quota response header, so Jittor never fabricates a Vertex budget bar; it instead classifies Vertex's `google.rpc.Status` failure shape (quota, authentication, invalid-request, overload, transport, unknown) from Pi's bounded, content-free `errorMessage` and records only a bounded failure-count metric. Because no budget signal can ever exist for this provider, the footer's `budget` segment is omitted entirely for it rather than showing a permanent `?` placeholder that could never resolve; the `?` placeholder is reserved for providers that can report a budget but simply haven't yet (router not ready, or telemetry not observed on the first turn).
-
-The third-party `anthropic-vertex` provider (Anthropic Claude models served through Google Vertex, e.g. via `@twogiants/pi-anthropic-vertex`) is tracked separately from both of the above: it reuses Pi's own Anthropic Messages stream implementation with Anthropic's official `@anthropic-ai/vertex-sdk` client, so its wire shape is Anthropic's, but its quota accounting is Google's. Jittor applies Google Vertex's failure classification to it (real-world reports confirm its 429s still carry GCP's own quota-exceeded shape even through Anthropic's own SDK) and, best-effort, also checks for genuine Anthropic rate-limit response headers on it, since it is unverified whether this specific passthrough ever forwards them. Either way, every metric is tagged `anthropic-vertex`, never blended into direct Anthropic's `anthropic` source or Pi's unrelated native `google-vertex` provider, since each represents a different account/quota pool. Its footer budget (labeled `vtok`/`vreq` when headers are observed) stays `null` (may still resolve) rather than `undefined` (provably impossible) until it's confirmed one way or the other.
-
-The native Pi extension preflights input and every provider turn, applies model/thinking decisions, records response headers and finalized usage through the daemon, and blocks requests when required telemetry is unsafe. It follows Pi's current authenticated model/provider and synchronizes Pi's available models before every decision, so unavailable catalog routes are never selected. Mutable route state is scoped by Pi session, so concurrent sessions cannot replace each other's active provider or footer budget selection. Each session registers an opaque secret with the daemon at `session_start` (best-effort; a registration failure leaves that session unarmored rather than blocked) and presents it on every router-mutating call for the rest of its lifetime; an unregistered `session_id` continues to mutate exactly as before, so this is additive armor, not a breaking change for other callers of the same API. A configured required budget source still fails closed; a provider with no enforceable budget window continues explicitly monitor-only. Its responsive integrated footer groups repository and model identity with cumulative usage, a color-coded context-window bar, and current-provider budget telemetry. Codex shows the active model's bounded quota as a draining remaining-budget bar with reset and freshness information. OpenRouter uses the same drain semantics when its official key telemetry exposes a configured limit and remaining balance; keys without a limit remain honest text-only spend and never receive a fabricated denominator. Anthropic shows the same drain semantics from its most-restrictive-in-effect token bucket, falling back to the request bucket when no token telemetry has been observed yet. During Pi compaction, the context bar drains from its captured fill against a learned median duration estimated from the last few completed compactions (bounded to the most recent 20 samples, requiring at least 3 before trusting it). It never renders a timer. Until enough evidence exists, the bar does not drain; it blinks in place at its captured fill. Run `jittor compaction estimate [--json]` to inspect the current estimate and its confidence directly. Unknown and stale telemetry are marked explicitly. Run `/jittor` for the consolidated Settings TUI (its default action), or `/jittor status` for detailed burn pressure, freshness, route state, and confirmed emergency-halt/override controls.
-
-Jittor currently registers no model-callable native tools, so Pi's native model `content` versus renderer `details` contract is explicitly not applicable. Daemon JSON, CLI `--json`, human CLI output, command notifications, panels, and the footer remain separate bounded channels. See [`docs/OUTPUT_CHANNELS.md`](docs/OUTPUT_CHANNELS.md) for the conformance matrix and the requirements that apply if a native tool is introduced later.
+## Provider telemetry
 
-Blocking always has a daemon-independent escape hatch. `/jittor off` immediately enters persisted monitor-only mode and never blocks provider requests. The informational footer is independently controlled with `/jittor footer on` and `/jittor footer off`, so showing status never enables enforcement. `/jittor on` only enables enforcement after telemetry polling and available-route synchronization succeed. Every fail-closed error includes these recovery commands plus the daemon restart command.
-
-### Opt-in Codex settled-turn recovery
-
-Transient Codex recovery is securely off by default and controlled through the existing Jittor command surface:
-
-```text
-/jittor recovery status
-/jittor recovery on
-/jittor recovery off
-/jittor recovery cancel
-```
-
-The on/off choice persists privately in `$XDG_CONFIG_HOME/jittor/extension.json` (or `~/.config/jittor/extension.json`). Status reports only enabled state, cooldown, bounded attempt/window counters, and the normalized failure class. `cancel` clears the current cooldown and attempt window without changing the persisted on/off choice.
-
-Jittor observes finalized Codex assistant errors through Pi's public message lifecycle, classifies only bounded error metadata, and waits for `agent_settled` before acting. That boundary guarantees Pi's built-in retry, compaction retry, and queued follow-up work has finished. A transient concurrency, rate-limit, overload, or transport failure then schedules one hidden follow-up with Retry-After-aware capped jitter. Recovery is limited to three attempts per ten-minute window, never overlaps pending Pi messages, resets after success, and is canceled by human input or session shutdown. Quota, authentication, invalid-request, unknown, and aborted failures remain terminal. Raw provider payloads are never retained or injected.
-
-### Settings
-
-`/jittor` is the settings and control command. Bare `/jittor` (or `/jittor settings`) opens one keyboard-navigable TUI covering routing enforcement, the informational footer, Codex recovery, and all four token-budget thresholds, with explicit ON/OFF and configured/not-configured labels, bounded rendering on narrow terminals, and confirmation for weaker enforcement/recovery changes. `/jittor status` shows the routing/pressure panel that used to be the bare command's default. Existing non-TUI subcommands (`benchmarks`, `outcome`, `recovery`, `on`/`off`, `footer on`/`off`, `context`) remain available for automation and are unchanged.
-
-### Usage and cost graphs
-
-`/usage` is its own top-level command, separate from `/jittor`. Bare `/usage` opens a colored Unicode cumulative graph with X/Y axes, per-provider/model series, and explicit **Hourly**, **Daily**, **Weekly**, **Monthly**, and **Quarterly** periods; `/usage cost` opens the same graph showing aggregated USD spend instead of tokens, reusing the `cost` metric already recorded content-free on every finalized Pi assistant message (no new instrumentation). Left/Right or Tab/Shift+Tab changes the time frame, `v` toggles between the token and cost views, and `r` refreshes.
-
-The graph fetches metrics per distinct provider/model scope (`jittor metrics distinct-scopes`, bounded to 40 scopes, 250 rows each) rather than one flat "most recent rows" query. A flat query lets one heavy, long-running session monopolize the entire row budget with its own most recent activity, silently hiding every other provider from the chart no matter which time frame is selected, since the query would never reach back far enough in time to see anything else. Fetching per scope guarantees every active provider/model gets its own fair share of the query budget instead.
-
-### Cost per Papyrus task
+- ChatGPT-authenticated Codex subscription usage
+- OpenRouter API key usage, response accounting, and model pricing
+- Anthropic official per-response rate-limit headers (requests, tokens, input/output tokens, and optional Priority Tier buckets)
+- Google Vertex AI classified failure pressure (quota/auth/invalid-request/overload/transport), since Vertex has no documented remaining-budget header or personal polling endpoint
 
-Jittor observes Papyrus's task-focus lifecycle in real time over a shared Pi extension event bus (`papyrus.task-focus.v1`) -- Papyrus never depends on Jittor, it only broadcasts which task is currently focused. Every token/cost metric Jittor already records on a finalized Pi assistant message is tagged with the currently focused task's id, and the provider/model/thinking level active at that moment, the instant it is recorded (no time-window estimation, no new instrumentation). A paused or cleared focus stops tagging; spend recorded with nothing focused is reported separately as unattributed, never dropped or folded into an invented task. Run `jittor metrics cost-by-task --since <ms> --until <ms> [--json]` for a bounded per-task breakdown of cost and input/output/cache tokens, broken down further by which provider/model/thinking combination each task actually spent on.
+Provider adapters currently include official OpenRouter key/usage/model telemetry and an explicitly experimental Codex subscription adapter. The Codex adapter follows the pinned open-source CLI `/wham/usage` payload and `x-codex-*` response-header contracts, accepts additional metered limits, and fails closed on malformed windows or impossible percentages. File credentials must be explicitly configured and private (`0600`); Jittor reads only the access token and account ID, never refreshes credentials, and never logs or persists OAuth secrets. Anthropic has no personal-account polling endpoint (its Admin/Rate Limits API is documented as unavailable for individual accounts), so Jittor instead reads the official `anthropic-ratelimit-*` response headers Pi observes on every Messages API call and fails closed on schema drift the same way. Google Vertex AI has neither a personal polling endpoint nor a documented remaining-quota response header, so Jittor never fabricates a Vertex budget bar; it instead classifies Vertex's `google.rpc.Status` failure shape (quota, authentication, invalid-request, overload, transport, unknown) from Pi's bounded, content-free `errorMessage` and records only a bounded failure-count metric.
 
-Series are colored with a categorical palette chosen to avoid this UI's own status colors ("success"/"warning"/"error" already mean something specific elsewhere in this panel, so reusing them for arbitrary model identity would make a model's bar segment look like a warning or a failure) and instead reuses the theme's syntax-highlighting roles, which are already tuned by theme authors to stay mutually distinguishable on screen — the same design problem as a categorical data palette. Once more series are active than there are hues, a series reuses a hue in bold rather than repeating an indistinguishable color. Multiple models active within the same cumulative time frame are rendered as one bar stacked by color, not separate bars.
+The third-party `anthropic-vertex` provider (Anthropic Claude models served through Google Vertex, e.g. via `@twogiants/pi-anthropic-vertex`) is tracked separately from both of the above: it reuses Pi's own Anthropic Messages stream implementation with Anthropic's official `@anthropic-ai/vertex-sdk` client, so its wire shape is Anthropic's, but its quota accounting is Google's. Jittor applies Google Vertex's failure classification to it (real-world reports confirm its 429s still carry GCP's own quota-exceeded shape even through Anthropic's own SDK) and, best-effort, also checks for genuine Anthropic rate-limit response headers on it, since it is unverified whether this specific passthrough ever forwards them. Either way, every metric is tagged `anthropic-vertex`, never blended into direct Anthropic's `anthropic` source or Pi's unrelated native `google-vertex` provider, since each represents a different account/quota pool.
 
-Token-budget thresholds are optional and must be configured by the user; Jittor never infers a token allowance from Codex or another provider's subscription percentage. Configure or clear one period with `/usage budget <hourly|daily|weekly|monthly|quarterly> <positive-tokens|off>`, and inspect all of them with `/usage budget`. A configured budget appears as a horizontal threshold on the cumulative graph with explicit remaining or **OVER BUDGET** state; the cost view does not yet support a budget threshold. These private settings persist in `$XDG_CONFIG_HOME/jittor/extension.json` (or `~/.config/jittor/extension.json`).
+Blocking always has a daemon-independent escape hatch: `/jittor off` (in the extension) immediately enters persisted monitor-only mode and never blocks provider requests, regardless of daemon state.
 
-### Benchmark evidence
+## Benchmark evidence
 
 Jittor can ingest bounded OpenRouter model metadata, p50 latency/throughput ordering, and Design Arena Elo rankings as provenance-bearing evidence without treating OpenRouter as model-scope authority. Enable online ingestion explicitly with `JITTOR_OPENROUTER_BENCHMARKS=1`; it is off by default. OpenRouter model metadata and operational ordering are public; Design Arena ingestion additionally uses `OPENROUTER_API_KEY` from the supervised service environment without retaining it. Snapshots preserve the upstream publisher, normalized model identities, immutable retrieval revisions, source URLs, confidence, license terms, and explicit freshness deadlines. A malformed or oversized refresh leaves the last complete snapshot visible and records only a payload-safe failure state.
 
-Design Arena rates models across dozens of arena/category pairs (music, video, text-to-speech, ASCII art, ...); Jittor ingests only the bounded allowlist of categories (`codecategories`, `website`, `uicomponent`, `dataviz`, `svg`) that measure frontend/UI-generation skill relevant to routing a coding agent, tagged into one `design` domain distinct from `coding`. A model with no OpenRouter-reachable identity (proprietary platforms, image/video generators) is skipped rather than fabricated into unroutable evidence. Kept on the OpenRouter passthrough rather than migrated to a direct integration: Design Arena's own native API requires a manually reviewed application (1-2 business days), unlike Artificial Analysis's instant self-serve signup below.
+Design Arena rates models across dozens of arena/category pairs (music, video, text-to-speech, ASCII art, ...); Jittor ingests only the bounded allowlist of categories (`codecategories`, `website`, `uicomponent`, `dataviz`, `svg`) that measure frontend/UI-generation skill relevant to routing a coding agent, tagged into one `design` domain distinct from `coding`. A model with no OpenRouter-reachable identity (proprietary platforms, image/video generators) is skipped rather than fabricated into unroutable evidence.
 
-Jittor also ingests LMArena's own official Hugging Face dataset (`lmarena-ai/leaderboard-dataset`, via the public `datasets-server.huggingface.co` API -- no credential required) for its Code Arena (`webdev`) and Agent Arena human-preference battles, and, when `ARTIFICIAL_ANALYSIS_API_KEY` is configured, Artificial Analysis's own direct API (replaces the former OpenRouter passthrough to the same publisher; adds a `math` domain and measured per-model latency the passthrough never exposed). LMArena's Bradley-Terry/IPS ratings aren't on the same scale as Artificial Analysis's 0-100 indices, so they're tagged under distinct `-arena`-suffixed dimensions (`quality-coding-arena`, `quality-type-planning-arena`) instead of blended into the same average -- stored and queryable on their own, not yet part of the default ranked "quality" score.
+Jittor also ingests LMArena's own official Hugging Face dataset (`lmarena-ai/leaderboard-dataset`, via the public `datasets-server.huggingface.co` API -- no credential required) for its Code Arena (`webdev`) and Agent Arena human-preference battles, and, when `ARTIFICIAL_ANALYSIS_API_KEY` is configured, Artificial Analysis's own direct API (adds a `math` domain and measured per-model latency). LMArena's Bradley-Terry/IPS ratings aren't on the same scale as Artificial Analysis's 0-100 indices, so they're tagged under distinct `-arena`-suffixed dimensions instead of blended into the same average.
 
 Use the authenticated CLI channels independently:
 
@@ -96,17 +47,17 @@ jittor benchmarks list --source openrouter-models [--model provider/model] [--di
 
 Only complete snapshots are queryable. Query output reports both completeness and freshness. See [`docs/BENCHMARK_SOURCES.md`](docs/BENCHMARK_SOURCES.md) for source authority, provenance, conflict, and redistribution rules.
 
-Jittor separately records content-free local model observations from Pi's public lifecycle: TTFT, wall latency, output throughput, token/cache/cost efficiency, provider retries, tool-loop counts, failures, and two independent classifications derived only from bounded tool names: domain (subject matter, e.g. `coding`) and type (activity, e.g. `research`, `planning`) -- a run can be domain=coding and type=research at once. Prompts, responses, tool arguments/results, credentials, and project paths are never retained. `/jittor outcome accepted` or `/jittor outcome rejected` attaches explicit outcome evidence to the latest completed local run; runtime completion alone is not treated as quality success. Robust aggregates report sample size, median, p90, median absolute deviation, recency, and confidence without merging local observations into external benchmark facts.
+The ranking operation (`domain/model-ranking.ts`) accepts an explicit bounded candidate set and never adds identities found only in evidence. It scores quality (a domain-specific dimension, e.g. `quality-coding`, and a type-specific dimension, e.g. `quality-type-planning`, each optional and additive over the universal `quality-general` fallback), cost, latency, context, and local reliability with bounded user weights, budget-pressure adjustment, component confidence, freshness, provenance, and deterministic tie-breaking. Missing evidence remains unknown and lowers confidence.
 
-The ranking operation accepts an explicit bounded candidate set and never adds identities found only in evidence. It scores quality (both a domain-specific dimension, e.g. `quality-coding`, and a type-specific dimension, e.g. `quality-type-planning`, each optional and additive over the universal `quality-general` fallback), cost, latency, context, and local reliability with bounded user weights, budget-pressure adjustment, component confidence, freshness, provenance, and deterministic tie-breaking. Missing evidence remains unknown and lowers confidence. Run `/jittor benchmarks [coding|general] [research|planning|general]` (either order, either or both omitted) for the responsive recommendation panel. Because the released Pi extension API does not expose the exact `/scoped-models` set, the current adapter labels candidates `available-models`; the panel says **ADVISORY** and offers no selection action. Automatic route ordering is allowed only for `exact-session` authority and then narrows/reorders routes already present in the supplied candidate set.
+Jittor separately records content-free local model observations from Pi's public lifecycle: TTFT, wall latency, output throughput, token/cache/cost efficiency, provider retries, tool-loop counts, failures, and two independent classifications derived only from bounded tool names: domain (subject matter, e.g. `coding`) and type (activity, e.g. `research`, `planning`). Prompts, responses, tool arguments/results, credentials, and project paths are never retained. Robust aggregates report sample size, median, p90, median absolute deviation, recency, and confidence without merging local observations into external benchmark facts.
 
-### Context pressure
+## Context pressure
 
 Papyrus emits content-free prompt-injection observations through Pi's shared extension event bus. Jittor validates and records their exact Rule/Task character sizes, prompt share, fingerprint repetition, and explicitly estimated token size. Jittor also records completed, aborted, and unmatched Pi compactions with duration, reason, retry state, pre-compaction context usage, and bounded turns/injection/provider/cache usage since the previous compaction.
 
-Run `/jittor context` for the in-session summary, or `jittor context [--since <epoch-ms>] [--until <epoch-ms>] [--json]` through the authenticated daemon client. The assessment reports bounded average/p95/max injection, Rule/Task mix, unchanged rate, compaction frequency/duration/reasons, and between-compaction provider/cache facts. Repeated prompt content is not labeled billed waste: provider-reported input/cache usage and an injection-disabled control are required before making cost or compaction-causality claims.
+`jittor context [--since <epoch-ms>] [--until <epoch-ms>] [--json]` reports bounded average/p95/max injection, Rule/Task mix, unchanged rate, compaction frequency/duration/reasons, and between-compaction provider/cache facts. Repeated prompt content is not labeled billed waste: provider-reported input/cache usage and an injection-disabled control are required before making cost or compaction-causality claims.
 
-### CLI operations
+## CLI operations
 
 Every daemon operation is reachable from the CLI through the authenticated typed client only — no command reads the SQLite store or a provider adapter directly. Each command supports `--json` for stable machine output; without it, a purpose-built human presenter renders the same result, per [`docs/OUTPUT_CHANNELS.md`](docs/OUTPUT_CHANNELS.md).
 
@@ -114,10 +65,9 @@ Every daemon operation is reachable from the CLI through the authenticated typed
 jittor metrics record --source <s> --scope <s> --metric <s> --value <number|null> --unit <unit> [--observed-at <ms>] [--attributes <json>] [--json]
 jittor metrics record-batch --observations <json-array, max 100> [--json]
 jittor metrics query [--source <s>] [--scope <s>] [--metric <s>] [--since <ms>] [--until <ms>] [--limit <n>] [--order asc|desc] [--json]
-jittor metrics prune --before <ms> [--json]
+jittor metrics prune --before <ms> [--force] [--json]  # force required if before is newer than 24h ago
 jittor metrics distinct-scopes --source <s> --since <ms> --until <ms> [--limit 1..40] [--json]
 jittor metrics cost-by-task --since <ms> --until <ms> [--json]
-jittor metrics prune --before <ms> [--force] [--json]  # force required if before is newer than 24h ago
 jittor service checkpoint [--json]
 jittor telemetry poll [--json]
 jittor compaction estimate [--json]
@@ -132,7 +82,7 @@ jittor op <operation> [--input <json>]
 
 `jittor op` is a raw escape hatch restricted to the daemon's own `EXPECTED_OPERATION_NAMES`; it rejects an unrecognized operation name before ever reaching the daemon rather than forwarding it blindly. Human-readable metric listings and router status are bounded (at most 50 metric rows and 20 telemetry sources are printed; `--json` output is bounded independently by the daemon's own query and response-size limits). No command prints the daemon bearer token, a provider API key, or an OAuth credential; a daemon-unavailable error stays actionable ("install or start jittor.service") without ever including the token used to reach it.
 
-See [`docs/CALIBRATION.md`](docs/CALIBRATION.md) for thresholds and rollback, and [`docs/USAGE_PRIOR_ART.md`](docs/USAGE_PRIOR_ART.md) for the chart design research.
+See [`docs/CALIBRATION.md`](docs/CALIBRATION.md) for routing thresholds and rollback, and [`docs/PROVIDER_RESEARCH.md`](docs/PROVIDER_RESEARCH.md) for verified provider API boundaries and caveats.
 
 ```bash
 bun test
@@ -141,5 +91,3 @@ bun run service:install
 ```
 
 The systemd user unit binds only to `127.0.0.1`, discovers a 256-bit token without logging it, restarts on failure, and exposes authenticated health and operation endpoints.
-
-See [`docs/PROVIDER_RESEARCH.md`](docs/PROVIDER_RESEARCH.md) for verified API boundaries and caveats.

package/package.json

@@ -1,8 +1,10 @@
 {
   "name": "@danypops/jittor",
-  "version": "0.11.0",
-  "description": "Just-in-Time Token Optimizing Router for Pi",
+  "version": "0.12.1",
+  "description": "Just-in-Time Token Optimizing Router for Pi -- supervised daemon, router policy, and CLI",
   "type": "module",
+  "main": "./src/index.ts",
+  "types": "./src/index.ts",
   "keywords": ["pi-package", "llm-router", "token-budget"],
   "bin": {
     "jittor": "src/cli.ts"
@@ -11,19 +13,11 @@
     "test": "bun test",
     "typecheck": "tsc --noEmit",
     "serve": "bun src/cli.ts serve",
-    "service:install": "bun src/cli.ts service install",
-    "guard:install": "git config core.hooksPath .githooks"
-  },
-  "pi": {
-    "extensions": ["extension/src/index.ts"]
-  },
-  "peerDependencies": {
-    "@earendil-works/pi-coding-agent": "*",
-    "@earendil-works/pi-tui": "*",
-    "typebox": "*"
+    "service:install": "bun src/cli.ts service install"
   },
   "dependencies": {
-    "@danypops/daemon-kit": "^0.3.1",
+    "@danypops/vehicle-server": "^0.2.1",
+    "@danypops/vehicle-client": "^0.1.1",
     "google-auth-library": "^10.9.0"
   },
   "devDependencies": {
@@ -31,7 +25,11 @@
   },
   "repository": {
     "type": "git",
-    "url": "git+https://github.com/DanyPops/jittor.git"
+    "url": "git+https://github.com/DanyPops/jittor.git",
+    "directory": "packages/jittor"
+  },
+  "publishConfig": {
+    "access": "public"
   },
-  "files": ["src", "extension", "docs", "README.md"]
+  "files": ["src", "docs", "README.md"]
 }

package/src/cli-commands/service-daemon.ts

@@ -41,7 +41,7 @@ export function systemctl(...args: string[]): void {
 
 /** cliPath is the caller's own entrypoint file -- resolved from the real CLI script's `import.meta.url`, never this module's own, so the installed unit's ExecStart always points at the actual runnable CLI. */
 export function installService(cliPath: string): void {
-	const unitPath = resolveJittorPaths().systemdUnit;
+	const unitPath = resolveJittorPaths().serviceDescriptor;
 	mkdirSync(dirname(unitPath), { recursive: true });
 	const codexAuthFile = join(process.env["CODEX_HOME"] ?? join(homedir(), ".codex"), "auth.json");
 	writeFileSync(unitPath, renderSystemdUnit({

package/src/cli-commands/support.ts

@@ -8,7 +8,7 @@ export interface CliDependencies {
 	stderr(line: string): void;
 	systemctl(...args: string[]): void;
 	installService(): void;
-	serve(): void;
+	serve(): Promise<void>;
 }
 
 export function humanField(value: string): string {

package/src/cli.ts

@@ -52,7 +52,7 @@ function usage(stderr: (line: string) => void): number {
 export async function runCli(args: string[], deps: CliDependencies = DEFAULT_DEPENDENCIES): Promise<number> {
 	const [command, action, ...rest] = args;
 	const fail = () => usage(deps.stderr);
-	if (command === "serve") { deps.serve(); return 0; }
+	if (command === "serve") { await deps.serve(); return 0; }
 	if (command === "session") return runSessionCommand(action, rest, deps, fail);
 	if (command === "metrics") return runMetricsCommand(action, rest, deps, fail);
 	if (command === "telemetry") return runTelemetryCommand(action, rest, deps, fail);

package/src/client.ts

@@ -1,4 +1,4 @@
-import { AuthenticatedRpcClient, type FetchTransport } from "@danypops/daemon-kit/rpc-client";
+import { AuthenticatedRpcClient, type FetchTransport } from "@danypops/vehicle-client/rpc-client";
 import type { OperationInputs, OperationName, OperationOutputs } from "./service.ts";
 import { ensureAuthToken, readDaemonHandle, resolveJittorPaths, type JittorPaths } from "./state.ts";
 
@@ -6,7 +6,7 @@ export type { FetchTransport };
 
 /**
  * Jittor's typed authenticated RPC client, now a thin named subclass of
- * `@danypops/daemon-kit/rpc-client`'s `AuthenticatedRpcClient` -- the shared substrate factored
+ * `@danypops/vehicle-client/rpc-client`'s `AuthenticatedRpcClient` -- the shared substrate factored
  * out after jittor's own client.ts and web-spider-daemon's were found byte-identical (see
  * daemon-kit's README). Keeps the old 3-positional-argument constructor so every existing call
  * site is untouched by this migration.

package/src/daemon.ts

@@ -1,4 +1,4 @@
-import { startDaemon as startDaemonKit, type RunningDaemon } from "@danypops/daemon-kit/daemon";
+import { startDaemon as startDaemonKit, type RunningDaemon } from "@danypops/vehicle-server/daemon";
 import { MAINTENANCE_INTERVAL_MS, TELEMETRY_POLL_INTERVAL_MS } from "./constants.ts";
 import { DEFAULT_POLICY, UNCONFIGURED_ROUTE } from "./config.ts";
 import { SQLiteMetricStore } from "./adapters/sqlite-metric-store.ts";
@@ -23,7 +23,7 @@ import type { GoogleVertexMetricSource } from "./providers/google-vertex-contrac
 import { ensureAuthToken, resolveJittorPaths, type JittorPaths } from "./state.ts";
 import { logEvent, logger } from "./log.ts";
 
-export type { RunningDaemon } from "@danypops/daemon-kit/daemon";
+export type { RunningDaemon } from "@danypops/vehicle-server/daemon";
 
 export function reportMaintenanceFailure(event: string, error: unknown): void {
 	logEvent("error", event, { message: error instanceof Error ? error.message : String(error) });
@@ -65,7 +65,7 @@ export function telemetrySourcesFromEnvironment(env: Record<string, string | und
 }
 
 /**
- * Composition root, now built on `@danypops/daemon-kit/daemon`'s `startDaemon` for binding,
+ * Composition root, now built on `@danypops/vehicle-server/daemon`'s `startDaemon` for binding,
  * atomic handle write, maintenance-timer driving, and clean shutdown -- the skeleton that used to
  * be hand-rolled here (and, byte-identically, in web-spider-daemon's and papyrus's daemon.ts; see
  * daemon-kit's README). Each maintenance task still catches and classifies its own failure via
@@ -74,10 +74,10 @@ export function telemetrySourcesFromEnvironment(env: Record<string, string | und
  * daemon-kit's own generic "maintenance task failed: <name>" catch, which exists as a safety net
  * for tasks that don't self-classify, not to replace a consumer's own richer classification.
  */
-export function startDaemon(
+export async function startDaemon(
 	paths: JittorPaths = resolveJittorPaths(),
 	env: Record<string, string | undefined> = process.env,
-): RunningDaemon {
+): Promise<RunningDaemon> {
 	const token = ensureAuthToken(paths);
 	const db = openJittorDb(paths.database);
 	const metrics = new SQLiteMetricStore(db);
@@ -96,7 +96,7 @@ export function startDaemon(
 	});
 	const service = new JittorService(metrics, router, benchmarks, modelRanker, sessionIdentity);
 
-	const daemon = startDaemonKit({
+	const daemon = await startDaemonKit({
 		daemonLabel: "Jittor",
 		handlePath: paths.handle,
 		logger,
@@ -115,8 +115,8 @@ export function startDaemon(
 	return daemon;
 }
 
-export function serveMain(): void {
-	const daemon = startDaemon();
+export async function serveMain(): Promise<void> {
+	const daemon = await startDaemon();
 	console.error(`[jittor] listening on ${daemon.host}:${daemon.port}`);
 	const stop = async (): Promise<void> => {
 		await daemon.stop();

package/src/db.ts

@@ -1,5 +1,5 @@
 import type { Database } from "bun:sqlite";
-import { openSqliteWithPragmas } from "@danypops/daemon-kit/storage";
+import { openSqliteWithPragmas } from "@danypops/vehicle-server/storage";
 import { SQLITE_BUSY_TIMEOUT_MS } from "./constants.ts";
 
 const INITIAL_SCHEMA = `
@@ -31,7 +31,7 @@ CREATE INDEX session_identities_last_seen_idx
 `;
 
 /**
- * Delegates bootstrap (pragmas, migration engine) to `@danypops/daemon-kit/storage`, which
+ * Delegates bootstrap (pragmas, migration engine) to `@danypops/vehicle-server/storage`, which
  * generalizes the byte-identical pragma/PRAGMA-user_version skeleton jittor's own db.ts used to
  * hand-roll (see daemon-kit's README). Jittor's only remaining responsibility is its own schema.
  */

package/src/index.ts

@@ -0,0 +1,137 @@
+export * from "./constants.ts";
+export {
+	type FetchTransport,
+	JittorClient,
+	connectJittorClient,
+} from "./client.ts";
+export {
+	EXPECTED_OPERATION_NAMES,
+	InvalidSessionSecretError,
+	JittorService,
+	UnknownOperationError,
+	createApp,
+	type JittorAppOptions,
+	type OperationInputs,
+	type OperationName,
+	type OperationOutputs,
+} from "./service.ts";
+export {
+	type CompactionDurationEstimate,
+	type CompactionStart,
+	CompactionTelemetry,
+	type ContextAssessment,
+	type PapyrusContextInjection,
+	assessContextTelemetry,
+	estimateCompactionDuration,
+	papyrusContextMetric,
+	validatePapyrusContextInjection,
+} from "./domain/context-telemetry.ts";
+export {
+	type TaskFocusEvent,
+	type TaskFocusStatus,
+	applyTaskFocusEvent,
+	validateTaskFocusEvent,
+} from "./domain/task-focus.ts";
+export {
+	METRIC_UNITS,
+	type MetricObservation,
+	type MetricQuery,
+	type MetricUnit,
+	type StoredMetricObservation,
+	validateMetricObservation,
+} from "./domain/metric.ts";
+export {
+	TASK_DOMAINS,
+	TASK_TYPES,
+	type ExplicitOutcome,
+	type ModelAggregateOptions,
+	type ModelMetricAggregate,
+	type ModelRunObservation,
+	type ModelTaskClassification,
+	type ModelTaskDomain,
+	type ModelTaskType,
+	aggregateModelMetrics,
+	classifyTaskFromTools,
+	modelRunMetrics,
+	validateModelRunObservation,
+} from "./domain/model-observation.ts";
+export {
+	type ModelCandidate,
+	type ModelRankingInput,
+	type ModelRankingResult,
+	type RankedModel,
+	type RankingProvenance,
+	type ScopeAuthority,
+	type UtilityComponent,
+	type UtilityComponentName,
+	type UtilityWeights,
+	rankModelCandidates,
+} from "./domain/model-ranking.ts";
+export {
+	USAGE_PERIODS,
+	type CostBucket,
+	type CostGraph,
+	type CostSeries,
+	type UsageAggregateRow,
+	type UsageBreakdown,
+	type UsageBucket,
+	type UsageBucketWindow,
+	type UsageGraph,
+	type UsageGraphOptions,
+	type UsagePeriod,
+	type UsageSeries,
+	buildCostGraph,
+	buildUsageGraph,
+	identity,
+	resolveUsageWindow,
+	usageBucketIndex,
+	usagePeriod,
+	usagePeriodStart,
+} from "./domain/usage.ts";
+export {
+	CodexRecoveryPolicy,
+	classifyCodexFailure,
+	type CodexFailure,
+	type CodexFailureKind,
+	type CodexFailureMetadata,
+	type CodexRecoveryAttempt,
+	type CodexRecoveryOptions,
+	type CodexRecoveryPlan,
+} from "./domain/codex-recovery.ts";
+export {
+	hasAnthropicRateLimitHeaders,
+	parseAnthropicRateLimitHeaders,
+	type AnthropicMetricSource,
+	type AnthropicRateLimitSnapshot,
+	type AnthropicRateLimitWindow,
+} from "./providers/anthropic-contracts.ts";
+export { parseCodexRateLimitHeaders } from "./providers/codex.ts";
+export {
+	classifyGoogleVertexFailure,
+	googleVertexFailureMetrics,
+	type GoogleVertexFailure,
+	type GoogleVertexFailureKind,
+	type GoogleVertexFailureMetadata,
+	type GoogleVertexMetricSource,
+} from "./providers/google-vertex-contracts.ts";
+export {
+	evaluateRoutingPolicy,
+	type BudgetWindow,
+	type PolicyAction,
+	type PolicyConfig,
+	type PolicyDecision,
+	type PolicyInput,
+	type PolicyThresholds,
+	type PreviousDecision,
+	type Route,
+	type TelemetryFreshness,
+} from "./policy.ts";
+export type {
+	RouteOverride,
+	RouterController,
+	RouterStatus,
+	TelemetryPollResult,
+	TelemetrySourceStatus,
+} from "./ports/router-controller.ts";
+export type { DistinctScopesFilter, MetricStore, UsageAggregateFilter } from "./ports/metric-store.ts";
+export { VERSION as jittorVersion } from "./version.ts";

package/src/log.ts

@@ -1,5 +1,5 @@
 /**
- * Structured daemon logging, now backed by `@danypops/daemon-kit/logging` (pino) instead of a
+ * Structured daemon logging, now backed by `@danypops/vehicle-server/logging` (pino) instead of a
  * hand-rolled `console.error(JSON.stringify(...))` -- daemon-kit's own module doc explains why:
  * level ordering/filtering/child-scoping is exactly the kind of thing worth one shared,
  * dependency-backed implementation instead of four independent hand-rolled ones. One deliberate,
@@ -8,9 +8,9 @@
  * four daemons. `component`/`level`/`timestamp` and credential-safety (callers still must pass
  * only bounded, non-sensitive fields) are unchanged.
  */
-import { createLogger, type LogLevel as DaemonKitLogLevel, type Logger } from "@danypops/daemon-kit/logging";
+import { createLogger, type LogLevel as VehicleLogLevel, type Logger } from "@danypops/vehicle-server/logging";
 
-export type LogLevel = Extract<DaemonKitLogLevel, "info" | "warn" | "error">;
+export type LogLevel = Extract<VehicleLogLevel, "info" | "warn" | "error">;
 
 /**
  * Also passed directly as `StartDaemonOptions.logger` so daemon-kit's own maintenance-task

package/src/ports/session-identity-store.ts

@@ -1,5 +1,5 @@
-import type { SessionIdentityRecord, SessionIdentityStore as DaemonKitSessionIdentityStore } from "@danypops/daemon-kit/session-identity";
+import type { SessionIdentityRecord, SessionIdentityStore as VehicleSessionIdentityStore } from "@danypops/vehicle-server/session-identity";
 
 /** Jittor's persistence port for daemon-kit's storage-agnostic session-identity primitive. */
-export type SessionIdentityStore = DaemonKitSessionIdentityStore;
+export type SessionIdentityStore = VehicleSessionIdentityStore;
 export type { SessionIdentityRecord };

package/src/service.ts

@@ -1,4 +1,4 @@
-import { errorResponse, healthResponse, readyResponse, requireBearerToken } from "@danypops/daemon-kit/http";
+import { errorResponse, healthResponse, readyResponse, requireBearerToken } from "@danypops/vehicle-server/rpc-http";
 import { SERVICE_MAX_BODY_BYTES, SERVICE_MAX_RESPONSE_BYTES } from "./constants.ts";
 import { InvalidSessionSecretError, SessionIdentity, type RegisterSessionIdentityResult } from "./session-identity-service.ts";
 import { VERSION } from "./version.ts";
@@ -188,7 +188,7 @@ export interface JittorAppOptions {
 
 /**
  * Bearer-check and the trivial health/ready/not-found responses now delegate to
- * `@danypops/daemon-kit/http` (the same handful of lines every daemon's service.ts hand-rolled).
+ * `@danypops/vehicle-server/rpc-http` (the same handful of lines every daemon's service.ts hand-rolled).
  * The response-size guard below stays jittor-specific: daemon-kit's `jsonResponse` is intentionally
  * unbounded (it has no operation dispatch of its own to guard), while jittor's `/api/v1/ops` can
  * return arbitrarily large query results that must be capped (see SERVICE_MAX_RESPONSE_BYTES).

package/src/session-identity-service.ts

@@ -1,4 +1,4 @@
-import { isSessionRegistered, registerSessionIdentity, releaseSessionIdentity, verifySessionSecret } from "@danypops/daemon-kit/session-identity";
+import { isSessionRegistered, registerSessionIdentity, releaseSessionIdentity, verifySessionSecret } from "@danypops/vehicle-server/session-identity";
 import type { SessionIdentityStore } from "./ports/session-identity-store.ts";
 
 export interface RegisterSessionIdentityResult {

package/src/state.ts

@@ -1,20 +1,20 @@
 /**
- * Jittor's XDG paths/token/handle layout, now delegating to `@danypops/daemon-kit/paths` --
+ * Jittor's XDG paths/token/handle layout, now delegating to `@danypops/vehicle-server/paths` --
  * the shared substrate factored out after jittor's own state.ts and web-spider-daemon's were
  * found byte-identical (see daemon-kit's README). Kept as a thin jittor-named wrapper (same
  * exported function names/signatures as before) so every existing call site (daemon.ts,
  * client.ts, cli.ts, and their tests) is untouched by this migration.
  */
 import {
-	ensureAuthToken as ensureDaemonKitAuthToken,
-	readDaemonHandle as readDaemonKitHandle,
-	removeDaemonHandle as removeDaemonKitHandle,
+	ensureAuthToken as ensureVehicleAuthToken,
+	readDaemonHandle as readVehicleHandle,
+	removeDaemonHandle as removeVehicleHandle,
 	resolveDaemonPaths,
-	writeDaemonHandle as writeDaemonKitHandle,
+	writeDaemonHandle as writeVehicleHandle,
 	type DaemonHandle,
 	type DaemonPaths,
 	type PathEnvironment,
-} from "@danypops/daemon-kit/paths";
+} from "@danypops/vehicle-server/paths";
 import {
 	DATABASE_FILENAME,
 	HANDLE_FILENAME,
@@ -39,17 +39,17 @@ export function resolveJittorPaths(options: PathEnvironment = {}): JittorPaths {
 }
 
 export function ensureAuthToken(paths: JittorPaths = resolveJittorPaths()): string {
-	return ensureDaemonKitAuthToken(paths.token, "Jittor");
+	return ensureVehicleAuthToken(paths.token, "Jittor");
 }
 
 export function writeDaemonHandle(paths: JittorPaths, handle: DaemonHandle): void {
-	writeDaemonKitHandle(paths.handle, handle);
+	writeVehicleHandle(paths.handle, handle);
 }
 
 export function readDaemonHandle(paths: JittorPaths = resolveJittorPaths()): DaemonHandle | null {
-	return readDaemonKitHandle(paths.handle);
+	return readVehicleHandle(paths.handle);
 }
 
 export function removeDaemonHandle(paths: JittorPaths = resolveJittorPaths()): void {
-	removeDaemonKitHandle(paths.handle);
+	removeVehicleHandle(paths.handle);
 }

package/src/version.ts

@@ -1,4 +1,4 @@
-import { readPackageVersion } from "@danypops/daemon-kit/version";
+import { readPackageVersion } from "@danypops/vehicle-server/version";
 
 /** Runtime package version; package.json is the single release source of truth. */
 export const VERSION = readPackageVersion(new URL("../package.json", import.meta.url), "Jittor");