Claude products

AITuber MCP Server Create AI-powered videos from your AI assistant. Generate videos with AI narration, visuals, and synced captions for YouTube Shorts, TikTok, Instagram Reels, and long-form content. Supports AI-generated images, video clips, stock footage, and viral templates like skeleton and character styles. AITuber handles script writing, voice synthesis, visual generation, and video rendering. One server, one URL: https://mcp.aituber.app AITuber | Setup Guide | API Documentation Set up your client claude.ai and Claude Desktop Open Settings, go to Connectors, click "Add custom connector", and paste https://mcp.aituber.app. A browser window opens to sign in with your AITuber account. Done. Claude Code claude mcp add --transport http aituber https://mcp.aituber.app Your browser opens once to sign in and approve access. ChatGPT Open Settings, go to Connectors, then Advanced, and turn on Developer mode (required for custom connectors). Add a new connector with the URL https://mcp.aituber.app and sign in with your AITuber account. Cursor Add to ~/.cursor/mcp.json: { "mcpServers": { "aituber": { "url": "https://mcp.aituber.app" } } } Codex Add to ~/.codex/config.toml: [mcp_servers.aituber] url = "https://mcp.aituber.app" OpenClaw and other MCP clients Add a remote MCP server with the URL https://mcp.aituber.app. If your client supports OAuth, sign in when prompted. If it asks for credentials instead, use an API key (next section). Two ways to sign in 1. Your AITuber login (default). Apps like Claude, ChatGPT, and Cursor open a browser window where you sign in and approve access. No key to copy, nothing to store. 2. An API key (servers, CI, automation). Where a browser sign-in is not practical (a VPS, CI pipeline, n8n, cron), create a key at app.aituber.app/dashboard/api-keys (starts with ak_) and send it as a bearer token to the same URL: claude mcp add --transport http aituber https://mcp.aituber.app \ --header "Authorization: Bearer ak_your_key_here" { "mcpServers": { "aituber": { "url": "https://mcp.aituber.app", "headers": { "Authorization": "Bearer ak_your_key_here" } } } } API keys are long-lived and revocable from the dashboard, so they fit unattended automation better than OAuth tokens. What you can do Generate videos from a prompt or script - describe a topic and get a fully produced video, or provide exact narration text for precise control Short-form and long-form - create 15-second Shorts or 20-minute videos 1,300+ AI voices - filter by gender, accent, age, or language 27+ visual styles - photorealistic, anime, cinematic, 3D Pixar, watercolor, comic book, and more Video templates - skeleton X-ray style, character-driven stories Multiple media types - AI-generated images, AI video clips, or real stock footage Music videos - generate a song from a prompt (or upload your own track) and turn it into a music video with AI visuals and synced lyric captions YouTube, TikTok, and Instagram - publish directly to your connected channels Export to MP4 - render and download the final video Check credits and plan - monitor usage before generating Start creating Ask your AI assistant: "Create a 60-second video about 5 mind-blowing facts about the ocean" "List available British female voices for narration" "Check how many credits I have left" "Export my latest video to MP4 and give me the download link" "List my connected channels and publish my finished video to YouTube, TikTok, and Instagram" How it works The server provides two tools: search_api Finds the right AITuber API endpoint for your task. Describe what you want in natural language. search_api("create a video about cats") -> Returns: POST /videos/generate with all parameters and examples execute_api Calls the AITuber API. Use after search_api to know which endpoint and parameters to use. execute_api(method: "POST", path: "/videos/generate", body: { "script": "5 amazing facts about the deep ocean", "inputType": "idea", "expectedDurationSeconds": 60 }) -> Returns: { videoId: "abc-123", status: "pending" } Example workflows Generate and download MP4 Search - find the right endpoint for creating a video Generate - create the video with your script and settings Poll - check video status until generation completes Export - render the completed video to MP4 Download - get the MP4 download URL Generate and publish Generate - create the video with your script and settings Poll - wait until the video status is completed List channels - call GET /channels to find connected channel IDs Publish - call POST /publications with the videoId and per-channel settings Poll publication - call GET /publications/{publicationId} until it reaches published, scheduled, or failed Publishing requires channels to already be connected through the AITuber dashboard and an active paid plan with the Publish feature. If the video is not exported yet, the API starts the export automatically. Generate a music video Make a song - call POST /music with a prompt (or upload a track with POST /uploads purpose music) Poll the song - call GET /music/{id} until status is completed Build the video - call POST /music-videos with the musicId (or musicAssetId) and a visualMode (ai-images, ai-video, or cover-image) Poll the video - call GET /videos/{id} until status is completed, then export or publish it API endpoints Endpoint Description GET /voices Browse 1,300+ AI voices with filters (public, no auth required) GET /voices/cloned List voices you cloned in the dashboard GET /avatars List avatars for talking-head videos GET /elements List saved people, products, and places (with @handles) POST /elements Save an element from a photo URL or uploaded asset POST /uploads Upload media (from a URL or a direct PUT) GET /ugc/reactions List UGC reaction clips (library + your own) POST /ugc/reactions Generate a reaction clip from your character GET /ugc/reactions/{id} Get a reaction clip status POST /ugc/videos Build a finished UGC hook video POST /music Generate an original song from a prompt GET /music List your generated and uploaded tracks GET /music/{id} Get a song's status and audio URL POST /music-videos Turn a song into a music video with AI visuals POST /ideas Get video topic ideas for a niche POST /scripts Write a narration script from a topic GET /image-styles List image styles for video generation GET /caption-styles List caption styles for video generation POST /videos/generate Create a video from a script or idea GET /videos List all your videos GET /videos/{id} Get video details and generation status DELETE /videos/{id} Delete a video GET /clip-models List AI models for standalone clips with capabilities and costs POST /clips Generate a standalone AI video clip from a prompt or image GET /clips List your clips GET /clips/{id} Get clip status and download URL GET /subscription Check your plan, credits, and billing info POST /exports Start rendering a video to MP4 GET /exports/download Get a temporary download URL for the MP4 GET /channels List connected YouTube, TikTok, and Instagram channels POST /publications Publish a completed video to one or more connected channels GET /publications/{publicationId} Check publication status after publishing DELETE /publications/{publicationId} Cancel a scheduled publication before it goes live Supported video types Type Description How to create Faceless narration (images) AI images with Ken Burns animation, narration, and captions Default. Just send a script or idea. Faceless narration (video clips) AI-generated video clips instead of images Set mediaType: "video" Stock footage Real stock footage matched to narration Set mediaType: "stock" Skeleton template Viral "what happens if..." X-ray style Set templateId: "skeleton" Character template Character-driven story format Set templateId: "character" Avatar (talking head) An avatar speaks your script to the camera Set mediaType: "avatar" + avatarId + voiceId Under the hood The server is a stateless Cloudflare Worker (src/remote.ts, source in this repo). It verifies your AITuber sign-in or API key, exposes the search_api and execute_api tools, and forwards each call to the AITuber API with your own credential. Nothing is stored, there are no sessions, and there are no analytics. The endpoint catalog is generated from the API's OpenAPI definition, so the tools always match the live API. Dev and deploy notes: CONTRIBUTING.md. Links AITuber - AI video creation tool Setup Guide - Connect from any client API Documentation - Interactive API reference Dashboard - Manage videos and billing API Keys - Create and manage your API keys

Makoto An integrity hook for Claude Code that watches the agent's own tool calls and blocks the ones that fake a check. When Claude says it did something — ran the tests, cited a paper, committed the fix, verified the certificate — makoto holds that word against its record. If the deed isn't there, or the verification was quietly disabled, makoto blocks the tool call (or the end-of-turn) and hands the agent a one-line correction to retry against. It judges the agent against its own utterances and record — never the world's truth. It holds no facts ("France doesn't exist to it"); it only checks that a claimed word is kept, whole, and honored in deed. A word it lets through becomes spendable: trustworthy tender a reviewer or another agent can accept without re-deriving it. What it catches makoto fires on mechanical hook events — every PreToolUse, PostToolUse, and Stop — and blocks (exit 2, which Claude Code treats as block-and-retry) on 15 pre-checks across five families and 19 end-of-turn gates. Every pre-check and every end-of-turn gate but four blocks; there is no silent "warning" tier for those (see Fire level) — the four documented exceptions are gate.self_wired, gate.canon_fingerprints_advisory, gate.relative_path_citation, and gate.plan_item_drift (below), advisory-only checks that by design never block. Verifier weakening — a check silently neutered content.verifier_predicate_weakened loose-comparator verifier (startswith/endswith/re.match where == is meant) content.verifier_exit_masking exit-code masking (|| true, ; true, set +e on a test/build/lint) content.verifier_body_hollowed hollowed verifier body (return True / pass in a constitution check) content.env_gated_audit audit/verification code gated behind an env var · content.integrity_suppression_flag integrity-named suppression flag (*_skip = true) Fabricated evidence — a claim with no backing artifact content.phantom_citation phantom citation (Author-Year not in makoto/docs/CITATIONS.md) content.unsourced_webfetch WebFetch of a URL never seen in any prior tool result this session content.fabricated_commit_sha fabricated commit SHA/tag presented as proof of a commit content.deferred_checkbox_theater DEFERRED-style checkbox theater on an open to-do item content.illusory_authorship_trailer an illusory Claude/Anthropic authorship or generation attribution (trailer, session link, routing address, or "Generated with/by Claude" footer) — a plain "Claude Code" product-name mention is not matched content.illusory_interruption_claim a fabricated "interrupted by user" claim with no genuine harness-set interruption anywhere in this session's recorded history Self-defense content.self_mute_guard makoto self-mute (disabling or un-wiring makoto via settings.json) Scope & contract discipline — illusory progress and out-of-contract action (SPEC-5, ported by shape from Assay) event.thrash_revert a whole-file Write that reverts a file to an earlier byte-identical content after an intervening different Write (A→B→A, no net progress) gate.contract_order a result-producing call issued while a declared Plan's dependency for that step is still undischarged (its Stop-time sibling gate guards the remainder at turn end) End-of-turn gates — fire on the agent's closing claims, checked against the recorded ledger: gate.completion — "done / created X" but the artifact isn't on disk gate.advance — advancing a phase whose precondition isn't recorded as met gate.green_claim — "suite green" against a recorded test failure gate.dropped — a forward promise carrying identifying info ("I'll add def X to Y", "3 tests in Z") left undischarged at turn-end — said-but-not-done, checked against the agent's own touched-keys gate.fabricated_action — "I ran X / executed Y" in a turn with no tool call at all (presence-of-work, not command-text match) gate.named_test — "test_foo passes" against a recorded FAILED of that exact named test (coreference-pinned; the green_claim delta) gate.stale_pass — "all tests pass" against pytest's own lastfailed record still naming a live failing test (the runner's ledger, existence-filtered for staleness) gate.claimed_running — "the server is running" / "it's up and listening on port 5173" but this session's own recorded Bash evidence contradicts it: no process-start or liveness-check command ran at all this session, or the most recently recorded one ended in a direct error state (interrupted, or a non-zero exit code). Agnostic in the gate.canon sense — the failure verdict reads only those two protocol terminals, never a test-runner regex or a language/framework token; the command classifier is a broad, open-world, multi-ecosystem net (like is_test_runner's), so an unlisted launcher/healthcheck shape is a documented recall bound, never a false-block source. gate.run_promised — the forward-looking sibling of gate.claimed_running: the immediately prior turn's own message promised a first-person run-intent action ("I'll run the tests", "I'm going to restart the server", "let me deploy this") but no Bash call appears anywhere in this session's recorded history since — the word must match the world, checked one turn later. Closed first-person-auxiliary + closed process-lifecycle-verb lexicon (mirroring gate.claimed_running's own verb set), so "it's going to rain today" cannot match on either the subject or the verb axis. Stateless: the one-turn grace period falls out of history structurally never containing the row for the Stop currently being evaluated, so a promise made THIS turn can only ever be checked starting at the NEXT one — no new persistence, no Plan/PlanNode extension (a run-intent promise's only evidence is "a Bash call happened", not a located file write). gate.claimed_shipped — a completed-action sibling to gate.claimed_running/gate.run_promised, but scoped to REMOTE mutations instead of local process liveness: "I merged the PR", "pushed it to main", "it's live now" with no successful remote-mutating tool call anywhere in this session's recorded history. Evidence is a non-dry-run git push over Bash, or a successful call from a closed non-Bash tool set (merge_pull_request — requiring merged: true, not just an error-free response — and push_files, plus their mcp__github__-qualified forms); create_pull_request is deliberately excluded, since opening a PR establishes intent but does not substantiate "merged" or "live". Reads history_all_agents so a subagent's own real push/merge grounds a main-thread claim. Immediate check, no grace period — this claims something already done. gate.completion keeps sole ownership of local file-production claims; this gate never duplicates it. gate.liveness — fires on the code itself, not a claim: a statement with no live effect inside a closed function (dead/illusory work the present-closure model can prove inert). It walks the turn's touched .py ASTs, so it yields a finding per illusory statement rather than one per turn. gate.self_wired — advisory only, never blocks (see Fire level): partial-strip detection of makoto's own .claude/settings.json hook wiring — fires if PreToolUse/PostToolUse/Stop is missing a makoto-dispatching entry while at least one other still has one. It has a documented blind spot: a single edit that strips all three simultaneously disables this check in the same instant it would have fired (Claude Code reloads hook config live, not once at session start), so it provides zero coverage against that full-strip case — see docs/self-defense-asymmetry-followup.md. gate.hollow_test — fires on the code itself, not a claim: a HOLLOWED test (SPIRIT.md §4) — one that survives in name while its content is gutted, so it can never actually fail. Four sub-patterns: no assertion of any kind in the test body; an asserted tautology (assert True, or comparing an expression to itself); a broad, no-op try/except that silently swallows the only call-under-test's failure; and a test-shaped function that can never fire independently — either nested inside another function (pytest's collector never discovers it) or gated behind a skipif/skipIf condition that is provably always true. gate.canon — blocking (level="error", unlike the advisory exceptions below): two language-agnostic Stop primitives over the turn's own call stream, reading only closed protocol fields (tool_name/tool_input identity, tool_response.interrupted/.error) — no test-runner regex, no language token. canon.timeout fires when the turn's LAST tool call ended in a direct error state (interrupted, or a self-emitted error code) and closed without resurfacing or resolving it — an error resolved by a later successful call stays silent. canon.recur fires when the SAME tool call (identical name + byte-identical input) was re-issued back-to-back and every call in that consecutive run ended in the same direct error state — a stuck retry loop with nothing changed between attempts; judged per (tool, input) key, so a later success for that same key silences it even with other, different calls in between. Certified via held-out adversarial RED fixtures (planted cases that must fire) plus a near-vacuous corpus-FP check — the honest corpus almost never carries the triggering precondition (interrupted/self_error_code) at all, so a clean corpus replay alone is inconclusive, not a certification (see ANCESTRY.md §2 Part B for the corrected framing). gate.canon_fingerprints — blocking: 4 of 17 ported session-level "canon" fingerprints (SPEC-5 Task 9, from REF-lever-graded-primitives/signalminer/grade_planted.py's 27-fingerprint THE_CANON) that are robust-core, blocking-capable by construction — 0-FP on both the planted-clean and real-Claude-gold negative sets per the gold-oracle certification (nogreen_checkdisabled, nosrc_destruct, nosrc_green_timeout, notestedit_destruct). gate.canon_fingerprints_advisory — advisory only, never blocks: the other 13 of the same 17 fingerprints — each either rests on a soft/claim atom (claimed_pass_no_run, tool_timeout, assertion_weakened) the gold-oracle finding doesn't certify as robust, or is one of that finding's explicitly-named worst-disqualified fingerprints. Recorded to the audit log per SPEC-5's total-retention rule, never emitted as a block decision. gate.contract_order — blocking: the Stop-time remainder guard over a declared Plan (SPEC-5, ported by shape from Assay's ContractOrder pattern) — fires when the turn ends with the plan's dependency remainder still non-empty. Its PreToolUse sibling guard is a pre-check, not a Stop gate; see makoto/checks/contractOrder.py. Inspect the live catalog with makoto pattern list; see one pattern in full with makoto pattern show content.phantom_citation. Discharging a permanent session-level block gate.canon_fingerprints (and canon.timeout within gate.canon) read the session's own recorded call stream. Once a fingerprint's atoms go true they stay true forever, so without a real discharge path a single sanctioned action (e.g. an owner-approved destructive command) would otherwise block every remaining Stop for the rest of the session. The only discharge is an operator-attributed release, re-derived from the host-written transcript at check time and never trusted from ledger content, so no tool call or file write can forge it. Say, as a real message in the conversation (never inside a tool call or file write): makoto release.operator <fingerprint-id>: <your reason> makoto verifies the turn is genuinely user-authored, non-synthetic, and timestamped after the finding first fired, then discharges that exact fingerprint for the rest of the session. The discharge is chain-appended (kind="release.operator") for the audit trail; the block decision itself is always re-derived from the transcript, never read back from that row. Legitimately writing a flagged shape? Annotate the line with makoto-allow: <reason> (any comment style, case-insensitive). makoto won't fire on it, and your rationale is on the record — an auditable note, not a silent bypass. if os.environ.get("ENABLE_AUDIT_TRAIL"): # makoto-allow: app feature, gates user-facing audit logging write_audit_trail() See docs/SPIRIT.md — 誠 (makoto), the constitution every pattern derives from: a word is real the way water is wet, a constitutive property, not an after-the-fact audit. Install (plugin) /plugin marketplace add Clear-Sights/Makoto /plugin install makoto@makoto Enabling the plugin is the whole install: .claude-plugin/plugin.json + hooks/hooks.json auto-wire dispatch on enable. Claude Code registers PreToolUse, PostToolUse, Stop, SubagentStop, and SessionStart hooks pointing at ${CLAUDE_PLUGIN_ROOT}/makoto/_dispatch_shim.sh automatically (which execs python -m makoto._dispatch). ~/.claude/settings.json is NOT modified — the plugin system manages its own hook registry. State dir + makoto.db are created lazily on the first hook invocation. Companion setting (optional): suppress the harness auto-trailer An illusory AI-authorship commit trailer reaches a commit through two doors. Pre-Check content.illusory_authorship_trailer blocks the agent-authored one — the trailer typed into a git commit message or into file content, the surface no setting can reach. The other door is Claude Code's own automatic append, which a setting governs. To close it at the source, set in ~/.claude/settings.json:

Your AI bill can be quietly wrong. Providers shouldn't get to grade their own bills. Today, the company that charges you also decides what counts as a failure, what gets credited, and keeps the only detailed records. inferock-bench puts an independent, per-call receipt of what you were billed — and what failed — in your own hands. We built inferock-bench because we kept paying for answers that died mid-sentence, and nobody could tell us where the money went. Quickstart · Test your loss · What can go wrong · Key boundary · Docs Use it when you need to audit an AI/LLM bill, measure Claude or GPT token usage locally, or answer "was I billed for a failed API call?" It is a local LLM cost-tracking proxy for four measured provider planes: OpenAI, Anthropic, Gemini Developer API, and pinned OpenRouter endpoints spanning meta-llama, deepseek, mistral, moonshot/kimi, z-ai/glm, and qwen on observed hosts. Everything else is extensible-by-design, not measured today. It does not declare every mismatch an OpenAI overcharge or Anthropic billing error; it preserves token, cost, retry, and failure evidence so billing-integrity questions can be checked. Common cases it can help you inspect: a failed or timed-out request that still has usage, token counts that do not match the visible output, retries that may have amplified cost, and latency or model-version changes that need a trail. It cannot cap provider spend across calls it never sees, and it cannot explain traffic that bypassed the local proxy. The receipt headline Receipt word Plain-English meaning spent provider spend observed by the run for priced calls it saw. money loss bill-bounded dollar loss The Inferock Standard can tie to observed spend or charge evidence. time loss real wait or downtime measured as time, never added to dollars. invoice-check exposure an invoice-check amount, such as cache discount at risk; it is labeled "verify your invoice" and never summed into money loss. Real measured traffic, not fixture rows. Measured since 2026-07-09, the cumulative public ledger through run15 captured 1,268 measured calls, 565 failures/signals, $7.15 provider spend observed, $0.07 bill-bounded money loss (stored exact: $0.073875), ~2.9 min time loss, and $16.80 invoice-check exposure across 202 cache-discount-at-risk signals. The current-code cumulative receipt watches 12 of 13 surfaces and keeps invoice-check exposure separate from money loss. Run facts: sanitized public run card for 2026-07-09 and run15 public run card for 2026-07-10. The 2026-07-06 0.1.7 card remains published as a historical artifact; the current public receipt presentation ships with 0.1.10. ImportantThe receipt is spend-anchored. The headline is spent $X · money loss $Y · time loss Z · invoice-check exposure $E; bill-bounded money loss and recognition gap never include invoice-check exposure. CACHE_DISCOUNT_AT_RISK is still visible below the headline as a separate detail line that says "verify your invoice" rather than as money loss or a refund claim. Watch it run Share the receipt Quickstart Run it locally. We think you should be able to see exactly what a provider failure cost you, to the cent. Provider keys are not sent to Inferock; attached only to provider requests. Prerequisite: install Node.js 22+ with npm. node --version npm --version If either command is missing, install Node.js 22 or newer first. Run the local benchmark: npx inferock-bench The first run downloads the package and can take a minute or two before printing anything. Leave it running. You see lines like: inferock-bench listening at http://127.0.0.1:4318 Dashboard: http://127.0.0.1:4318/ Config: ~/.inferock-bench/config Save your provider key locally. Easiest path with the server from step 2 still running: open http://127.0.0.1:4318/ and save the provider key in the dashboard. Create that key in your provider account first; use a low-limit or development key while evaluating. It stays local under ~/.inferock-bench/, is saved with owner-only file permissions, and is shown back only in masked form. CLI path, before starting the server or after stopping it: npx inferock-bench setup <provider> The setup prompt hides your key while you type it. On a headless machine, pipe the key from your secret manager into the same command. To see the current supported provider names, run npx inferock-bench status or npx inferock-bench --help. A running server does not reload provider keys written by a separate CLI setup process; restart it after CLI setup. Any traffic you send through the benchmark is real provider usage. Start with a few short prompts and expect a small evaluation spend, controlled by your provider account limit. The built-in npx inferock-bench test flow shows estimated tokens, estimated dollars, and a spend cap before it makes any provider call. Get your local bench key: npx inferock-bench key reveal This prints the local ibl_ bench key to stdout, so it is pipe-friendly. It is a LOCAL-ONLY credential, not your provider key. To copy it to the clipboard instead, run: npx inferock-bench key copy If no clipboard is available, the copy command falls back to printing the key. You can also copy the local bench key from the dashboard. Check what is configured at any point: npx inferock-bench status It shows each provider's configured/masked state, the local store location, server state, and version. For a fast command list or package version without starting the server, use npx inferock-bench --help or npx inferock-bench --version. Point some traffic at the local benchmark. No app yet? Use one of these equal local targets after saving the matching provider key in step 3. Claude Code: npm i -g @anthropic-ai/claude-code ANTHROPIC_BASE_URL=http://127.0.0.1:4318 ANTHROPIC_API_KEY=ibl_your_local_bench_key claude -p "Draft a five-bullet checklist for reviewing an AI invoice." OpenAI SDK: import OpenAI from "openai"; const openai = new OpenAI({ apiKey: process.env.INFEROCK_BENCH_KEY ?? "ibl_your_local_bench_key", baseURL: "http://127.0.0.1:4318/v1", }); await openai.chat.completions.create({ model: "gpt-4o-mini-2024-07-18", messages: [{ role: "user", content: "Draft a five-bullet checklist for reviewing an AI invoice." }], }); Gemini: await fetch("http://127.0.0.1:4318/v1beta/models/gemini-2.5-flash:generateContent", { method: "POST", headers: { authorization: "Bearer " + (process.env.INFEROCK_BENCH_KEY ?? "ibl_your_local_bench_key"), "content-type": "application/json", }, body: JSON.stringify({ contents: [{ role: "user", parts: [{ text: "Draft a five-bullet checklist for reviewing an AI invoice." }] }], }), }); For these commands, the SDK API key is the local ibl_ bench key from step 4. Your provider key is not passed to Claude Code or your app; it is not sent to Inferock and is attached only to provider requests. If you configured OpenRouter, use the provider-specific SDK snippet in the dashboard's Local app connection panel or in the package README. Note: a Claude subscription (OAuth) login is not a supported mechanism for measuring calls. inferock-bench measures metered API traffic only — save a provider API key in the bench and point your SDK or agent at it with the local ibl_ key, as shown above. After the first successful proxied call, the terminal running inferock-bench prints: first call measured ✓ View your receipt from another terminal: npx inferock-bench receipt --compact If you installed inferock-bench globally, inferock-bench receipt --compact works too. This README uses the npx inferock-bench <cmd> form so one-time users are not stranded. Already have an app? Change exactly two SDK settings: apiKey and baseURL. const client = new YourProviderSdk({ apiKey: process.env.INFEROCK_BENCH_KEY ?? "ibl_your_generated_local_key", baseURL: "http://127.0.0.1:4318", }); Some SDKs use /v1 in the base URL. The dashboard shows the exact value for every configured provider; npx inferock-bench init prints OpenAI and Anthropic constructor snippets. Run npx inferock-bench init to detect OpenAI or Anthropic SDK usage and print the exact SDK change. npx inferock-bench init --patch path/to/client.ts --yes patches simple constructors only when it can update both apiKey and baseURL; otherwise it refuses with a clear message. For Gemini or OpenRouter, use the dashboard's Local app connection snippet or the package README's provider example. Run from source git clone https://github.com/inferock/inferock-bench.git cd inferock-bench pnpm install pnpm -r --workspace-concurrency=1 build node apps/inferock-bench/dist/index.js start Test your loss npx inferock-bench test runs the complete coverage battery through your configured provider scope, on your provider key, so the receipt can show what your provider cost you and which loss surfaces the run actually opened. The checked-in measured baseline powers the estimate, so a configured provider key and priced compatible model are enough to reach the consent step. For the exact formulas behind the receipt, see Paid-loss arithmetic. You see the estimated tokens, estimated dollars, model, suite, baseline, pricing source, and spend cap before any provider call is made. The copy states the price plainly: running the complete test set on the selected provider(s) will cost approximately the displayed amount. If you stop there, the command makes zero provider calls. Interactive runs require you to type RUN; automation must pass the displayed hash with --accept-estimate <hash> because --yes alone is not consent to a changed estimate. In the dashboard, open Advanced options, set Test driver to Agent test, then run the test to use a real coding agent. Agent test currently supports OpenAI and Anthropic runs; use the built-in generator for Gemini and OpenRouter coverage. If the pinned local agent is not installed, the dashboard names the exact npm tarballs, versions, SRI checksums, sizes, source URLs, and local install path before downloading. The agent receives only localhost and an ephemeral local ibl_ key, never your provider key. CLI equivalent: npx inferock-bench test --generator agent. The receipt is run-scoped. It reports spent $X · money loss $Y · time loss Z · invoice-check exposure $E, provider-recognized recovery, bill-bounded recognition gap, the separate invoice-check exposure detail line when applicable, and surfaces watched N of M surfaces your selected providers can open (M varies by provider), with every surface labeled watched-clean, signal, or not-openable. A zero only counts when the surface was watched; unopened surfaces are named as coverage debt, not silently claimed clean. For a priced call that fails the standard and is tied to observed spend or charge evidence, money loss is bill-bounded; provider-recognized can still be $0, and the gap is the difference inside that bill-bounded money ledger. The receipt opens with a one-line plain-English guide to spent dollars, bill-bounded money loss, time loss, and invoice-check exposure. A receipt "failure" is a measurement finding, not necessarily your app crashing. A signal is one finding the benchmark saw, such as a token cross-check. CACHE_DISCOUNT_AT_RISK is shown as invoice-check exposure with "verify your invoice" guidance; it is not summed into money loss or recognition gap. Provider-recognized is the part that appears likely to fit the provider's current credit rules; bill-bounded gaps stay visible instead of being hidden. If no provider key is configured, pricing is unknown, or the token baseline is ever absent or bootstrap-only, the CLI and dashboard fail closed and make zero provider calls. The baseline-degraded state is reported as baseline not measured yet: run `npx inferock-bench test --record-baseline` with explicit consent to produce a real per-task token baseline. The method details are in Coverage test methodology. What your provider doesn't tell you The gap is simple: providers give you totals. They usually do not give you the per-call receipt you would need to prove which answer broke, which retry ran, or which token count changed. We do not think you should have to trust a monthly total. We think every broken answer should leave a trail: what happened, how sure we are, and whether the provider would actually recognize the claim. Illustrative mechanism — not measured data. This is the kind of billing blind spot we built inferock-bench to catch on your own traffic.

Agent OS A local-first AI Project Operating System — the harness that turns a coding model into a reliable software agent. LLM + Harness = Agent See Agent OS in action ▶ Watch the 1-minute demo on YouTube The 1-minute demo runs on real Pulseboard run records — no re-run, no rebuild, no fabricated data — and walks the full harness loop: plan → execute → verify → recover → approve → ship. Docs map. This README is the public landing page. The system's shape (files, pipelines, invariants) lives in ARCHITECTURE.md; the evolution log in ROADMAP.md; the long-term direction in BLUEPRINT.md; the operating guide for coding agents working on this repo in CLAUDE.md. What is Agent OS? Agent OS is a local-first cockpit for running multiple long-term software projects through a single web chat surface — and the harness that wraps a coding model with everything it needs to finish real work reliably. It runs entirely on your machine — filesystem + SQLite + FastAPI + React, no cloud queues, no hidden infrastructure — and combines: Project-scoped conversations — each project has its own chat history, memory, and execution workspace, isolated from the others. Structured markdown memory — durable project state lives in readable, editable .md files, not buried in chat scrollback. A two-agent split — a Main Agent (the brain: planner, memory steward, orchestrator) and a sandboxed Coding Agent (the hands: a bounded executor inside one project's workspace). A capability-aware provider registry — six model providers (Claude, GPT, Gemini, DeepSeek, Kimi, Zhipu GLM), each with a selectable model list and vision metadata. A full build → verify → deliver → deploy loop — plan into a task graph, execute (in parallel agent teams when safe), verify with a real build, walk the running app in a headless browser, review it with a vision model, deliver through audited Git/GitHub contracts, and ship it to production through Vercel / Supabase / Stripe-test connectors — every external or destructive step behind an explicit human approval gate. Self-healing that stays on a leash — a typed Recovery Matrix classifies failures, packages the evidence, and (only with your pre-approved budget) runs bounded, fully-audited repair passes. Discoverable agents, skills & approval-first research — an @-command palette backed by structured agent contracts and editable skill files; a @search research channel that fetches bounded, cited web sources only on your explicit command; and bounded local retrieval over a project's own memory, runs, and repo. It is deliberately not a general-purpose assistant or a heavyweight agent platform. It's a clear, controllable place for one builder to plan, decide, and execute project work — with the model on a leash that makes its output trustworthy. Why an Agent Harness matters A foundation model that can generate code is necessary but not sufficient. The gap between "the model produced a diff" and "the task is reliably done" is filled by the harness: The model gives you… …but reliable execution also needs A plausible diff Verification that the change actually builds and renders — ground truth, not the model's say-so A single-shot answer Memory that persists project state across turns and runs Raw tool-call intent A sandbox chokepoint so every file write and shell command is validated and bounded An opaque "done" Observable artifacts — task card, plan, event log, result, screenshots, diff — you can replay Confident hallucination Bounded repair loops and a typed recovery matrix that catch and correct failure Eagerness to act Permission gates so nothing pushes code, mutates external systems, or spends money without explicit approval A code change Delivery — checkpoint, reviewed diff, commit, push, PR, deployment, migration — with full traceability Agent OS is an attempt to build that harness end-to-end, with the boundaries and audit trail treated as constitutional rather than optional. Showcase: a production SaaS Agent OS shipped by itself Pulseboard — live at agent-os-sample-project.vercel.app — is a public product-feedback & roadmap SaaS: feedback posts with upvotes and comments, a Planned / In Progress / Shipped roadmap, a changelog, Supabase auth + Postgres + RLS, and a Stripe test-mode Pro subscription. Agent OS planned it, built it, verified it, repaired it when things broke, and shipped it from an empty repository to a paying production deployment — driven only by short chat messages, with a human doing nothing but approving contracts. Everything ran through Agent OS itself, the way a user would drive it: Planned & built. A natural-language product request became a judged, confirmable plan, then a multi-task Coding Agent run; a real npm run build gated completion (the model can't mark its own homework). Browser-verified, interactively. Headless Chromium walked 8 rendered pages and executed the declared submit-feedback flow — goto → fill → submit → assert — with per-step screenshots. The AI visual review caught a real rendering bug (roadmap upvote arrows showing literal ↑ escape text); after a fix run, the verdict flipped to passed. Self-healed. A bad dev-server flag broke browser verification. The typed Recovery Matrix classified the failure runtime, packaged the actual stderr into a confirmable repair plan, and the repair child fixed the config — budget-clamped to one pass, fully linked parent↔child lineage, all audited. Delivered through contracts. Two-phase preview→confirm all the way: Git commit → push to its own repo, Vercel production deploy (READY), Supabase link + SQL migration (tables + RLS verified live), Stripe test-mode product/price provisioning + signed webhook registration, and per-key env-var pushes — every step recorded in the project's OPS.md ledger. Proven in production. A real signup on the live site, a real Stripe test checkout, and the signed checkout.session.completed webhook flipping profiles.plan to "pro" in the live Postgres — confirmed by reading the row back. The full payment→persistence loop, on the deployed app. And this is the cockpit itself — the new-conversation landing (left) and a live run inside the chat thread (right), with reconciled project memory, the provider integrations, and the Git/connector state in the context panel. Shown in dark mode; a light theme ships too. Architecture overview ┌────────────┐ /api ┌──────────────────┐ ┌─────────────────────────────┐ │ Frontend │ ←──────→ │ FastAPI backend │ ←────→ │ Provider Registry │ │ React/TS │ │ (main.py) │ │ Claude · GPT · Gemini · │ └────────────┘ └────────┬─────────┘ │ DeepSeek · Kimi · GLM │ │ └─────────────────────────────┘ ┌────────────────────────┼────────────────────────────┐ ▼ ▼ ▼ memory/ projects/{id}/ execution_workspaces/{id}/ (global .md) (project .md) ├─ repo/ ← Coding Agent's sandbox │ │ ├─ runs/ ← per-run artifacts └─── Main Agent ────────┘ ├─ patches/ ← team-run isolation (chat brain) └─ (runner + verify + git + deploy) Brain vs. hands — the central rule Main Agent = brain. Holds the conversation, loads global + project memory, assembles context, produces planning / explanation / review replies, decides delegation, and reconciles memory. It never edits repo/ code and never runs a shell command. It can read specific repo files on demand through a bounded, read-only inspection channel — but repo contents are never auto-injected into its context. Coding Agent = hands. A bounded JSON tool loop inside exactly one project's execution_workspaces/{id}/repo/. It edits code through six sandboxed tools and produces run artifacts. It never edits memory and never touches another project's workspace. They communicate through summaries, not shared context — a boundary that is load-bearing for the whole design. The sandbox chokepoint Every repo path and every shell command routes through one boundary: ProjectSandbox → ToolRuntime. There is no raw os / pathlib / subprocess access to repo paths anywhere else. The Coding Agent gets exactly six tools — list_files, read_file, write_file, append_file, search_files, run_shell — each with bounded output. Git and the Supabase CLI are separate audited executors, not agent tools, and run_shell blocks git push and destructive commands. The run lifecycle: build → verify → deliver → deploy A single natural-language task card flows through a phased, auditable pipeline. Each stage leaves a durable artifact, and each external/destructive stage is gated behind explicit approval. flowchart LR A([Task card]) --> B[Plan task graph] B --> C[Execute solo or agent team] C --> D[Command verify + iterative repair] D --> E[Browser verify views + declared flows] E --> F[AI visual review diagnostic] F --> G[Memory reconcile] G --> H[Typed recovery assess] H --> I{{Deliver & deploy commit, push, PR, Vercel · Supabase · Stripe}} style I fill:#2f6f4e,color:#fff Loading Explicit dispatch only. Only @code <task> or clicking OK, run this on a model-proposed plan starts a run. Inferred intent never auto-runs code; the one scoped exception is a bounded auto-recovery budget you pre-approve at confirm time. Verification is the ground truth for "done." A run is completed only after a real build/test passes — not because the model claimed success. Best-effort tail. Verification, browser checks, reconciliation, and diff capture never crash a run and never leave it stuck. What's inside Capability What it does Project cockpit Three-column React UI (projects / chat / context + runs) with light/dark themes, editable memory files, a live Runs panel, and a multi-modal composer (voice, attachments, @-command palette). Main Agent orchestration Context assembly from memory, deterministic @-modes (@plan @design @debug @review @inspect @memory), a model-judged delegation classifier that only ever proposes, and bounded on-demand file inspection. Memory engine One atomic, policy-filtered markdown write path; a structured intake judge proposes updates after each turn; post-run reconciliation folds run outcomes into project status. Coding Agent runner Phased runs: plan (read-only inspection → task graph) → execute (solo, sequential, or parallel agent teams in isolated patch workspaces with deterministic integration) → finalize, with live metrics and a full event trace. Verification Inferred or declared command verification (real npm run build / pytest) with a bounded iterative repair loop; a run is completed only when the build is green. Browser verification + visual review Headless Playwright walks the running app — render-readiness-gated multi-page captures plus declared interaction flows (click / fill / submit / expect_text, bounded and same-origin) with per-step screenshots, console/network evidence, and a diagnostic vision-model verdict. Typed recovery A Recovery Matrix classifies every failure (build / runtime / visual / integration / deployment / database / product / docs), packages redacted evidence into the repair card, and honors a user-granted, contract-clamped auto-recovery budget (≤2). Git/GitHub delivery Automatic pre-run checkpoint + redacted post-run diff, then explicit two-phase commit / push / PR / rollback contracts. Tokens reach git only via a push-time GIT_ASKPASS env — never argv, config, logs, or the UI. Production connectors Vercel deploy/redeploy/rollback, Supabase link + migrations (sandboxed CLI), Stripe test-mode checkout + webhooks, and a presence-only env registry — all preview→confirm contracts, all redacted, all recorded in a deterministic OPS.md ledger. Research & skills Grant-gated @search web research (SSRF-screened, allowlisted, cited, egress-guarded), bounded local RAG over memory/runs/repo, 18 editable agent skills, and review-first skill-patch proposals after green runs. Test coverage: 820+ backend tests across 59 files, each runnable standalone. Every test stubs the LLM caller, so the full suite runs with no API key. Frontend npm run build (tsc + vite) is green. Quick start One-command install (Windows) Open PowerShell and run:

Claude

Explore categories

How Product Visit works