VoltageInputMcp

refuse.** Executing half of an intended sequence is worse than not executing the whole sequence.

• deny_labels refuses a click on anything named like Delete / Confirm / Purchase / Allow anywhere — catches the dialog that pops up in an unexpected place.

• Region fencing, key allowlists, denied chord (ctrl+alt+delete, alt+f4), denied text patterns (rm -rf, sudo), limits on burst length and inputs-per-second.

• Four independent stops: voltage stop (writes out a file — works over SSH), an deadman mouse that fires in its own thread if the loop jams, physical input conflict (if you touch the real mouse it stops), and Playbook budgets.

• Held keys are always released — on aborts, crashes, timeout. A run interrupted between d:shift and u:shift must not leave Shift depressed.

"

" * dry_runがデフォルトです。 新しいPlaybookは、あらゆるバーストを解析、チェック、ジャーナル化し、実際の制御には決して触りません。"

Hmm, "while touching nothing." -> "実際には何にもアクションを起こしません。"

• バースト全体の拒否。 意図したシーケンスの半分を実行することは、まったく実行しないことよりも悪いです。

• deny_labels — どこに出てきても、Delete / Confirm / Purchase / Allowという名前の要素へのクリックを拒否します。これは、予期しない場所に現れた予期しないダイアログを捕まえるための仕組みです。

• リージョン分けのフェンス、キー許可リスト、拒否コード(ctrl+alt+delete, alt+f4)、拒否されたテキストパターン(rm -rf、sudo)、バーストの大きさと秒あたりの入力回数の上限。

• 4つの独立した停止: voltage stop (ファイルを書き込む — SSH上でも有効)、ループが固着した場合に自分のスレッドで発火の鍵となるデッドマンのタイマー、物理入力の競合(実物のマウスを触ると停止)、そしてPlaybookの予算。

• 押し下げられたままのキーは必ず離される — 中断時、クラッシュ時、タイムアウト時。d:shiftからu:shiftの間に割り込まれた場合、さらにShiftが押されたままになってはいけません。

Wait: "Held keys are always released — on demand". The original: "Held keys are always released — on abort, on crash, on timeout."

I'll translate "- 保持されたキーは常にリリースされます — 中断、クラッシュ、タイムアウトのどの場合でも。"

Install

cd voltage-input-mcp && ./scripts/setup.sh

"That checks /dev/uinput access, folder needed for dependencies, creates the venv, and prints what is missing. Then:"

"つまり、/dev/uinputへのアクセスを確認、システムの依存関係をインストール、venvの作成、不足しているリストの表示、まで行います。それから:"

./scripts/fetch-models.sh lean && ./scripts/serve.sh lean

.venv/bin/voltage doctor

Launching from an MCP client

"MCP clients start servers with a sanitized environment — PATH, HOME, and little else. This is a sensible default, but it breaks screen capture because the compositor needs DBUS_SESSION_BUS_ADDRESS and WAYLAND_DISPLAY. Input injection still works without them (uinput is a device file, not a session service), so the symptom look confusingly partial: bursts fire, screenshots don’t happen.

Translate:

"MCPクライアントは、サーバーをどのようにきれいな環境で起動します。環境変数は PATH と HOME とほとんどそれだけです。これは妥当なデフォルトですが、screen captureを壊します。というのは、コンポジッタへの静止には DBUS_SESSION_BUS_ADDRESS と WAYLAND_DISPLAY が必要だからです。入力インジェクションはこれらの環境がなくても動作するため(uinputはセッションサービスではなく、デバイスファイル)、症状が紛らわしいというきれい:バーストは実行されるのに、スクリーンのキャプチャーは失敗します。"

"Pass them through explicitly:"

"明示的に渡してください:"

claude mcp add voltage-input \
  -e WAYLAND_DISPLAY="$WAYLAND_DISPLAY" \
  -e DISPLAY="$DISPLAY" \
  -e DBUS_SESSION_BUS_ADDRESS="$DBUS_SESSION_BUS_ADDRESS" \
  -e XDG_RUNTIME_DIR="$XDG_RUNTIME_DIR" \
  -- /absolute/path/to/voltage-input-mcp/.venv/bin/voltage-input-mcp

"voltage_doctor reports exactly which of these are missing, so it is the first place to look if capture is failing."

" voltage_doctor は、これらのうちどれが欠けているかを正確に報告します。キャプチャ失敗時、最初に確認すべき情報です。

Requirements

• Linux で /dev/uinput を持つ (X11, Wayland, console — ディスプレイサーバの下のレイヤーで入力される)

• Python 3.11+

• lean プロファイルの GPU 空き約5GB のGPU; voltage profiles がマシンに応じて動作するものを表示する

• llama.cpp による最速パス、またはより遅いビルドをしないパスとしてのOllama

"Movement KDE Plasma 6 on Wayland (KWin), CUDA, Python 3.14."

"KDE Plasma 6 on Wayland (KWin)" - this is config, keep: "Wayland (KWin) 上の KDE Plasma 6, CUDA, Python 3.14で検証済み。"

MCP tools

Table. Since the table is there, I translate Purpose column:

1. ボルトにリセット... "voltage_reference": Playbook と burst DSL のリファレンス。まずこれを呼ぶ。 "voltage_doctor": このマシンには何かが欠けている場合、その修復方法まで。 "voltage_capture": スクロール返すスクリーンショット。 "voltage_observe": ビジョンを1パス — guard watch リストが機能するか、それに依存してから確認 "voltage_validate_playbook": 完全な静検証: ガード、爆発、グラフ、各遷移のデッド "voltage_run": 実行を開始。run_id を返す。 "voltage_status": 状態、変数、最後のバースト、見えたもの、フェースごとのタイミング "voltage_steer": 動作中のランを修正 — ヒント、変数、強制状態、dry_run "voltage_stop" / voltage_pause: 停止または一時停止; 停止常に保持中の入力を解放 "voltage_journal": サイクル毎の記録で、with only_refused でポリシーの競合をみる "voltage_execute_burst": ローカルモデを停止せず、自分で入力を駆動 "voltage_calibrate": インジェクションがコンポジックタに届く確認。

Hmm for "voltage_observe": "One vision pass — check that a watch list works before depending on it."

"One vision pass" meaning "ビジョンパス一回分の実行". So: "ビジョンを一回通過する— watch リストが機能することを確認してから依存するさせる" I'll write: "ビジョンパス1回分を実行し、watchリストが機能するかを、それに頼る前に確認します。"

"hosted": "一度きりの" maybe. I'll craft.

Note: "dead references" - "遷移先のない状態遷移" might be clearer: "完全静的検査: ガード、バースト、グラフ遷移、到達不能状態遷移"。

"Two tools" table needs exactly two columns.

Documentation

• ARCHITECTURE.md — ループの作り方、各選択の答え、どう動いたか

• PLAYBOY.md — 作成ガイド

Status

"Built and verified as far as possible without actual weights on disk. 149 tests cover the burst DSL, the guard sandbox, safety governor, build the playbook, GBNF generation, the u入力 wire format, and the run loop itself (driven with mock models — including a check that on_change perception really does skip the vision model on an unchanged screen)."

"重みファイルをディスクに置かない状態で可能な限りまで構築し、検証しました。149のテストが、バーストDSL、ガードサンドボックス、セーフティガバナー、プレイブックのコンパイル、GBNFの生成、uinputのワイヤエンコーディング、そして実行ループ自身(スタブモデルを使って駆動 — on_change知覚が変化しない画面で実際ビジョンモデルをスキップするかどうかの確認を含む)を網羅しています。"

"The MCP server has been end through end over stdio to a real client: 13 tools, correct schemas, execute_burst accepted a valid burst and refused sudo rm -rf / with matching rules."

"MCPサーバは、実際のクライアントからstdio経由でエンドツーエンドの動作を確認しました。13個のツール、正しいスキーマ、execute_burstは有効なバーストを受け入れ、sudo rm -rf /を拒否しました。それぞれマッチするルールです。"

"each one with a matching rule" Or "both using the correct matching rules" — "どちらも対応するルールに一致していました。"

Now, regarding those "GXP" placeholders: I will write them exactly: "GXP1" etc. Should I put them on their own lines. They're placeholder tokens, likely image placeholders, and the instruction says to keep.

One subtlety: The input contains "that was" separate characters and an em dash in headings. My translation will preserve.

Let me also nail down the markdown formatting: preserve bullets as "*". Preserve bold/italic markers. The table cells with "500 ms" should have the markers.

Now: output should be Japanese only. I'll ensure no code fences.

Let me also review a few translations for idiomatic quality:

• "input speed instead of tool-call speed" → "ツール呼び出しの速度でなく、入力速度" Hmm, the phrase: "An MCP server that lets a frontier model drive a computer at input speed instead of tool-call speed." = "フロンティアモデルが、ツール呼び出し速度ではなく入力速度で、コンピュータを操作することを可能にするMCPサーバー。" I'll use "駆動".

• "Computer-use tools round-trip to a remote model for every action." = "コンピューター使用ツールは、アクションごとにリモートのモデルへ往復します。"

• "Screenshot up, decision down, one click." = "スクリーンショットが上がり、決定が下り、クリックが一つ入る。"

• "The bottleneck is not the model's intelligence. The intelligence is 800 ms away" — I translate as "ボトルネックはモデルの知能ではありません。それは、知能が800ミリ秒先に存在し いること、また入力を8ミリ秒間隔で届ける必要があることです。"

• "Separate deciding from doing" → "決定(考える)と実行(やる)を分離する" — "決定を実行から分離し"

• "The arms are not smart and are never asked to be." → "腕は賢くありませんし、賢いことを求められませんでもありません。"

• "The shape of the answer" → "回答の形" / "解答の形" options: "アプローチの形" (the shape of the answer as in solution). I'll use "解決策の形" or "答えの形". To keep formal, "解決策の形".

• "That's fine for filling out a form" → "それはフォームへの入力には十分です。"

Let me finalize each section in full.

I'll now start writing the complete translation, double-checking each line. Also use Japanese punctuation "。" and "、" that's fine.

Need to preserve line breaks: The original has paragraphs with line wraps; I don't need to preserve those soft returns exactly (only structure"), but I will output with line breaks matching paragraph grouping. The instruction says "Preserve the document structure exactly" - meaning headings, lists, tables. I think it's fine to wrap lines naturally. I'll put each paragraph on its own line, and preserve blank lines between blocks, bullet lists, etc.

Be faithful: "a 3B VLM still costs ~300 ms." => "3BのVLMでさえ、約300ミリ秒をコスる。盟"

Alright, let me also decide on "property names (slug)" must not be translated; OK.

Now the "Because it is there in the text without backticks" - we keep GXP tokens verbatim even if not backticks. Same for "Playbook"? The source calls "the actuator", which is a concept. The user only asked to keep code-ish names verbatim. "Playbrook" spelling: The text uses "Playbook" (capital P) consistently. It's a proper name in this repo. I'll keep "Playbook" as-is. Similarly "DSL", "burst" "guard" -- in running prose I can use kanji "バースト" etc. For "Playbook", I might write "Playbook(プレイブック)" once? Since it's a project concept, keep as "Playbook" throughout to be safe. But Japanese text needs particles; "Playbook" followed by particles is typographically fine in Japanese tech docs.

Other options include "バーストDSL" for "burst DSL" since "burst" is the concept.

Table tool purposes: Keep the tool name column exactly, including backticks and the /. Translate the Purpose cell.

I'll now check each "GXP" location from the source:

• After "The arms are not smart and are never asked to be." → GXP1

• After "Bursts. ... program..." → GXP2

• After "Reflexes. ... no model at all." → GXP3

• After "** ... , not by a model." → GXP4

• After "Measure instead of guessing: GXP5 → "Measure rather than guess:" → GXP5

• After items 1-3 in "Comparing models" → GXP6

• After "## Install" → GXP7

• After "Then:" → GXP8 and GXP9 (two lines after each other)

• In "Launching from an MCP client" after "Pass them through explicitly:" → GXP10

These keep exact.

Now, in the "Install" paragraph: "That checks /dev/uinput access, installs system dependencies, creates the venv, and prints what is missing. Then:" — I translated.

Also, "MCP clients start server with sanitized env..." uses "sanitized environment" → "サニタイズされた環境" is a bit technical but ok. Maybe "スケルトンの環境" no. I'll use "サニタイズ済みの環境".

One more check: "Prompt-cache locality" - I wrote "プロンプトキャッシュの局所性". Good.

Now, what about "the watch list" - in text, "watch" is in inline code. Keep with code.

"voltage_reference" tool, etc. All keep.

Now, some commentary sentences such as "Not from the small models being fast — a 3B VLM still costs ~300 ms." — "速度は、モデルが小さいからではありません — 3BのVLMでさえ約300ミリ秒必要だ。". OK.

"Two settings that fail silently if wrong:" — "間違っていた場合静かに失敗する2つの設定:"

"Numeric: 1.7B model" - "1.7Bモデル", "3Bモデル".

"Prompt-cache locality" - as a concept, "プロンプトキャッシュの局所性".

"the actuator gets more CPU threads than the vision model" - "そのアクチュエータは、ビジョンモデルよりも多くのCPUスレッドを取得します".

"despite being fully GPU around" — wait, source: "the actuator gets more CPU threads than the vision model despite the GPU offload" hmm let me read original:

"GBNF evaluating is evaluated by a single CPU run for every sample token, so the actuator gets more CPU threads than the vision model despite a fully GPU under offloading — and having allow_keys locked down is a latency optimization, not just a security one."

Actually reading the source again: "so the actuator gets more CPU threads than the vision model despite being fully GPU-offloaded" hmm, actually: "so the actuator gets more CPU threads than the vision model despite being fully GPU-offloaded" — wait the grammar runs on CPU, so actuator consumes CPU threads as much as vision model consumes GPU... fine.

"though being fully GPU-offloaded" refers to the actuator being fully GPU-offloaded for its model inference. So: "アクチュエータは完全にGPUにオフロードされているにもかかわらず、ビジョンモデルより多くのCPUスレッドを取得します。" Hmm, being offloaded to GPU means it doesn't use CPU, but inline: we're rationale that "because the GBNF eval runs on CPU..." The cause: "GBNF評価はサンプリングされたトークン毎にCPUで1回実行されるため..." So it reads.

Wait, "The actuator gets more CPU threads than the vision model despite being fully GPU-offloaded" means the deploy provided more CPU threads to the actuator process than to the vision model process. Could be because of the grammar.

My translation: "GBNF評価はサンプリングされたトークンごとにCPUで1回実行されるため、アクチュエータは、完全にGPUオフロードされているにもかかわらず、ビジョンモデルよりも多くのCPUスレッドを割り当てられています。また、allow_keysを制限することは安全性の向上だけでなく、レイテンシの最適化でもあります。"

The "despite fully model accelerator" - maybe I'll phrase: "アクチュエータはビジョンモデルとは異なり完全にGPUオフロードであるにもかかわらず、..." Actually as it says: even though the actuator is fully GPU-offloaded, it still gets more CPU (because the grammar requires CPU evaluation); the vision model also GPU offload? hmm not important.

I'll write: "そのためアクチュエータは、ビジョンモデルの背後で全GPUオフロードにもかかわらず、より多くのCPUスレッドを必要とします" — Not accurate. The original literally: "the actuator gets more CPU threads than the vision model" — to put Japanese: "アクチュエータは、完全にGPUオフロードであるにもかかわらず、ビジョンモデルよりも多くのCPUスレッドを持つ". That's it.

"and restricting allow_keys is a latency optimization, not only a safety one." — "allow_keysの制限は、安全性だけでなく、レイテンシーの最適化でもあります。"

Now: "## The Playbook" — capitalized "The" in heading. I'll write "## Playbook" but maybe keep "## The Playbook" verbatim? The heading text is of prose, but it is a title. I should translate text content: "Playbook" is a proper noun. I'll translate to "## Playbook" — that is both a product name and translated title. It's fine.

"## The problem" → "## 問題" or "## 課題". "## 問題" "## The shape of the answer" → "## 解決策の形" "## Where the speed actually comes from" → "## 速度は実際どこから来るのか" "## Why the small models are reliable despite being small" → "## 小さいモデルが小さいのに信頼できる理由" or "小さなモデルが、小さいにもかかわらず信頼できる理由" "## Performance tuning" → "## パフォーマンスチューニング" "## Comparing models" → "## モデルの比較" "## Safety" → "## 安全性" "## Install" → "## インストール" "## Launching from an MCP client" → "## MCPクライアントから起動する" "## Requirements" → "## 必要条件" "## MCP tools" → "## MCPツール" "## Documentation" → "## ドキュメント" "## Status" → "## ステータス"

Also section headings with "The Playbook": I'd rather keep "## Playbook" (without The) or "## Playbook (The Playbook)"? I'll use "## Playbook".

Alright, one more: "Now let's do "Design" phrase "the Playbook" in the intro: "do not give them a goal ... state machine... transition guard expressions evaluated by the runtime, not by a model." => should be "not by a model" — yes.

The word "trigger" is "guard" in safeguards. Fine.

Now produce the final result.

Careful with line endings: I'll use same line breaks between headings etc.

One more check: original in "Perf tuning" bullet:

"* allow_keys — 1, 2, 3... Actually in Safety bullet. OK.

Also "Region fencing" is a concept I translated "リージョンフェンス-ing"?

Let me see the original: "Region fencing, key allowlists, rejected chords..." The bullet becomes "* リージョンフェンシング、キー許可リスト、否定的キーボード (...) ,のinput deny text patterns ..." — I must ensure punctuation correct.

I'll finalize everything.

Let me pad a little: I'll output the translated text with no intro, no code fence, just the mark# VoltageInputMcp

フロンティアモデルに、ツール呼び出し速度ではなく入力速度でコンピュータを駆動させるMCPサーバー。

問題

Computer-useツールは、すべてのアクションについてリモートモデルへ往復します。スクリーンショットを送信し、判断を受け取り、クリックを1回。これはフォームへの入力には十分ですが、素早く送る必要のある一連の入力を必要とするものには役に立ちません。— ゲームのプレイ、モーダルダイアログの操作、タイムラインの駆動、3番目の入力が最初の2つの入力が既に届いていることに依存するようなUIであれば、どれもそうです。ボトルネックはモデルの知能ではありません。問題は、知能が800ミリ秒先にあり、入力は8ミリ秒間隔で届ける必要があるということです。

解決策の形

決定することと実行することを分離し、実行側をキーボードと同じマシンに置く。

オーケストレーターが頭脳です。小さなモデルは腕です。腕は賢くなく、賢くあることも求められません。

  ┌─────────────────────────────────────────────────────────────────┐
  │  Layer 1  —  the orchestrator (Claude, or any MCP client)       │
  │  Writes a Playbook: states, what to look for, what is allowed,  │
  │  when to move on. Thinks once, up front. Watches and corrects.  │
  └───────────────────────────┬─────────────────────────────────────┘
                              │  MCP
  ┌───────────────────────────▼─────────────────────────────────────┐
  │  Layer 2  —  two small local models, on your GPU                │
  │                                                                 │
  │   vision (Qwen2.5-VL-3B)     "of these specific things,         │
  │                               which are on screen, and where?"  │
  │   actuator (Qwen3-1.7B)      "given that, which inputs?"        │
  │                                                                 │
  │  Neither plans. Both answer one closed question per cycle.      │
  └───────────────────────────┬─────────────────────────────────────┘
                              │
  ┌───────────────────────────▼─────────────────────────────────────┐
  │  safety governor  →  /dev/uinput  →  the actual desktop         │
  └─────────────────────────────────────────────────────────────────┘

速度は実際にどこから来るのか

小さなモデルが速いからではありません — 3B VLMでさえ、約300ミリ秒はかかります。速度は、影響の大きい順に4つの要素から生まれます。

バースト。 アクチュエータは個々の入力を送信しません。バーストを送信します。バーストとは、モデルを介さない専用の実行器が実行する、時間指定された入力のプログラムです。

g:0;c:l;w:150;t:"README.md";k:enter;w:80;k:ctrl+s

これは、1回の決定と7つの入力を約400ミリ秒にわたってミリ秒単位でスケジュールしたものです。40アクションのバーストでも決定は1回で済みます。入力レートは、モデルではなくバーストが決めます。

反射。 モデルを一切使わず、数マイクロ秒で実行される、安価な画面プローブ(1ピクセル、1リージョンの平均など)を発火させるルール。

{"id": "heal", "when": "probe('health') < 0.25", "do": "k:q;w:60", "cooldown_ms": 800}

知覚のスキップ。 ほとんどのサイクルは、変化していない画面を処理しています。40マイクロ秒のフレーム差分で、ビジョンモデルに300ミリ秒使うか、前回の観測結果を再利用するかを判断します。通常のデスクトップ作業では、これによりほとんどのサイクルでVLMをスキップします。

プロンプトキャッシュの局所性。 プロンプトは静的要素を先頭にしてLLMを生成することで、llama.cppがKVキャッシュを再利用し、変更された末尾部分だけを再プリフィルするようにしています。

小さなモデルが小さいのに信頼できる理由

それは、信頼できるよう求められていないからです。制約されているのです。

llama.cppでは、両方のモデルがGBNF文法にしたがって生成を行います。この文法は、毎サイクル、現状の状態から再生成されます。文法は単なる助言ではありません。ロジットをマスキングするので、有効なパースを継続させるトークンしか到達できません。具体的には、アクチュエータは次のことをできません。

• 不正なバーストを出力する

• ポリシーが拒否するキーを名指しする — そのキーは文法に存在しないため

• 観測されていない要素を参照する — インデックス範囲はこのサイクルの要素数から構築されます

• Playbookが宣言していない状態遷移を提案する

さらにビジョンモデルは、UI要素名をでっち上げることができません: ラベルの語彙は、あなたが指定したwatchリストに小さな汎用セットを加えたものだけです。したがって、sees("address bar")ガードは、3Bモデルがたまたま生成した名詞とではなく、閉じた語彙との比較になります。

リトライループも防御的なJSONパースにありません。不正な出力がただ可能性低いのではなく、表現不可能なのです。

Playbook

小さなモデルにゴールを与えるのではなく、状態機械を与えます。遷移は、モデルが評価するのではなく、ランタイムが評価するガード表現です。

{
  "name": "open_downloads",
  "goal": "Open the file manager at ~/Downloads. Delete nothing, confirm nothing.",
  "initial": "launch",
  "policy": {
    "dry_run": true,
    "allow_verbs": ["g", "c", "k", "t", "w"],
    "deny_labels": ["delete", "trash", "confirm", "empty trash"]
  },
  "budget": { "max_cycles": 60, "max_seconds": 90 },
  "states": {
    "launch": {
      "brief": "Open the application launcher and start the file manager.",
      "watch": ["application launcher", "search field", "file manager icon"],
      "on_enter": "k:meta;w:400",
      "transitions": [
        { "when": "sees('search field')", "to": "type_name" },
        { "when": "cycles() > 6", "to": "@failure", "note": "launcher never opened" }
      ]
    },
    "navigate": {
      "brief": "Focus the location bar with ctrl+l, type the path, press Enter.",
      "watch": ["location bar", "file list", "error message"],
      "on_enter": "k:ctrl+l;w:200",
      "transitions": [
        { "when": "text('Downloads')", "to": "@success" },
        { "when": "sees('error message')", "to": "@failure" }
      ]
    }
  },
  "success_when": "text('Downloads') and not flag('loading')"
}

voltage_referenceは、完全なDSL、JSONスキーマ、ガード関数テーブルを返します。そのため、オーケストレーターはこのリポジトリを読みることなくPlaybookを作成できます。

パフォーマンスチューニング

以下の数値はすべて、基準マシン(RTX 3050 6GBを搭載したラップトップ、llama.cppでQwen2.5-VL-3B + Qwen3-1.7B)で測定されたものであり、見積もりではありません。

両方のモデルはデコードがボトルネックです。出力トークンだけが効くレバーです。

意外でした — 設計当初はビジョンがプリフィル律速だと考えていましたが、そうではありませんでした。プリフィルは448×252から896×504まで約28msで一定と測定されました。デコードは約22ms/トークンでした。つまり:

この3つの結果は、それぞれのデフォルトを変更しました。

• max_elements がビジョンの主要なコストです。 デフォルトの3を6に上げると、知覚サイクルごとに約1.5秒追加になります。実際にガードがテストするのと同じ数に設定してください。

• downscale_to を縮小しても効果はなく、通常は逆効果にします。 448×252は896×504より*2.5倍遅かく測定されました — 画像がぼやけるほどモデルの確信度が下がり、より多くのトークンを出力します。収まる最大サイズを使ってください。

• アクチューターのnoteフィールドは、そのレイテンシの55%を占めていました。 これはい専ら診断用で、48文字の場合412ミリ秒/サイクルと測定されたのに対し、12文字では184ミリ秒、0文字では140ミリ秒でした。デフォルトは現在12です。

要素は、同じ理由で [ラベル_インデックス, x1, y1, x2, y2] としてエンコードされ、 {"l":"アドレスバー","b":[...],"c":0.9} のような形式ではありません。測定の結果、トーク数は27〜29%減、レイテンシは32〜41%減でした。閉じたwatch語彙へのインデックス化は、さらに安全です。なぜなら、モデルはラベルを綴「もできず、ましてやのスペルミスも起こせないからです。

GBNF評価はサンプリングされたトークンごとにCPUで1回実行されるため、アクチュエーターは完全にGPUオフロードされるにもかかわらず、ビジョンモデルより多くのCPUスレッドを受け取ります。また、allow_keysの制限はレイテンシの最適化でもあります。

間違えると静かに失敗する設定が2つあります:

• ビルド時のGGML_CUDA_FA_ALL_QUANTS=ON。 この環境では、q8_0 KVキャッシュおよびフラッシュアテンションとともに提供します。このフラグがないと、llama.cppはそのKVの組み合わせ向けFAカーネンをコンパイルせず、低速パスにフォールバック — エラーはなく、ただ蔼味に悪い数値が出ます。scripts/build-llama.shがこれを設定します。

• 実行時のGGML_CUDA_ENABLE_UNIFIED_MEMORY=0。 これが1の場合、VRAMのオーバーフローは失敗の代わりに静かにPCIeへあふれ出ます。まるすべて動き、約10倍遅くなります。serve.shはこれを固定して無効にしています。

推測ではなく、測定しましょう:

.venv/bin/voltage bench

このツールは、ループで使用するのとまったく同じプロンプト形状で両バックエンドを駆動し、同一ウォームvsプロンプトキャッシュのレイテンシ、3つの入力サイズでのms/視覚トーク、およびそれらが示すサイクル時間を報告します。プロンプトキャッシュによる高速化が~1.5倍を下回る場合は、プロンプトの前置ン部分に何か動的なものが混入していることを意味します。

モデルの比較

「どのモデルがバーストをうまく書くか」という明白な実験は、間違ったものを測っています。文法はすでにどんなバーストも有効であることを保証しているので、より大きなモデルが構文で勝ることはありません。構成が使えるかどうかを実際に決定するのは、次の要素です。

1. グランディング精度。 200ミリ秒速くても40ピクセルずれるモデルは役に立た — クリックが外れます。クリックは中心位置に着弾は centerであるため、IoUではなく画面ピクセル単位の中心距離で測定します。

2. 制約下での判断品質。 同じ観測結果に対して、正しい合法行動を選ぶか、そして1サイクルに1つの控えめなアクションを出すのではなく、一連の一連のを1つのバーーストにまとめられるか。

3. レイテンシ。 この要素は、1と2が満たされてから初めて重要になります。

.venv/bin/voltage fixture desktop      # capture a real screen
.venv/bin/voltage compare              # score whatever is running now

グランドトゥルースは、オーケストレーションモデルがラベル付けした実際のスクリーショット — このシステムが実行## 時に使う参照と具体的同じです。合成UIは罠です。描画された四角形は、実際のインターフェースで学習したモデルに対してボタンとして読めるものではないため、そのようなものに対して評価することは、誤った技術を測ってしまいます。

結果は実行またの蓄積されるので、ワークフローは: プロファイルAをserve → ベンチマークを起動 → プロファイルB を serve → ベンチマークを起動 → テーブルを読む、というものです。voltage compare --listは、再実行せずに結果を出力します。

フィクスチャはユーザーのものであり、コミットされません。スクリーショットにプライベートなものが含まれる場合は、fixtures/を.gitignoreにを入力ください。

安全性

入力を生成しているのは1.7Bのモデルです。ガバナーは、助言的ではないレイヤーでき。すべてのバーストをこれに通過します。それにはリフレックスバーストや、あなた自身が作成したバーストも含まれます。

• dry_runはデフォルト。 新しいPlaybookは、何にも触れまま、すべてのバーストを解放し、検証し、ジャーナルに記録します。

• バースト全体の拒否。 意図したシーケンスを中途半端に実行することは、まったく実行しないより悪い結果になります。

• deny_labels は、Delete / Confirm / Purchase / Allow という名前を持つすべてのクリックを拒否します。どこに現われてもです。この仕組みが、想定外の場所に現れたダイアログを捉えます。

• **フィギュアリング、キーの許可リスト、拒否されたキーコンビネーション (ctrl+alt+delete、alt+f4)、は拒否されたテキストパターン (rm -rf、sudo)、バスのサイズと1秒あたりの入力数の上限。

• 4つの独立した停止手段: voltage stop (ファイルを書くためSSHとしても働く)、if というループが固まった際に専用スレッドで発火するデッドマンタイマー、物理入力の競合検出 (実物のマウスに触れると停止する)、Playbookの予算。

• 押したままのキーは常に必ず離される — 途中中断、クラッシュ、タイムアウト時も。d:shiftとu:shiftの間で中断された実行で、Shiftキーが押下されたまま残ってはなりません。

インストール

GXP測試で

これで /dev/uinputへのアクセスを確認し、システム依存をインストールして、venvを作成し、欠落しているものを出力します。その次に:

./scripts/fetch-models.sh lean && ./scripts/serve.sh lean

.venv/bin/voltage doctor

MCPクライアントから起動

MCPクライアントは、サリー化された環境 (環境変数 PATH、HOME など) でサーバーを起動します。これ自体は合理的なデフォルトですが、スクリーンショットの取得ができなくなります。作曲者にリーチするには DBUS_SESSION_BUS_ADAPTERス と WAYLAND_DISPLAY が必要だからです。入力注入は、これらなしでも動作します (uinputはデバイスいいファイルであり、セッションサービスではないため)。そのため、失敗が紛らわしいものに溢れます: バーは実行される、スクリーンショットが取得されない、というよう。

それを明示的に渡してください:

• 見本: DBUS_SESSION_BUS_ADDRESS と 「GXP10」

claude mcp add voltage-input \
  -e WAYLAND_DISPLAY="$WAYLAND_DISPLAY" \
  -e DISPLAY="$DISPLAY" \
  -e DBUS_SESSION_BUS_ADDRESS="$DBUS_SESSION_BUS_ADDRESS" \
  -e XDG_RUNTIME_DIR="$XDG_RUNTIME_DIR" \
  -- /absolute/path/to/voltage-input-mcp/.venv/bin/voltage-input-mcp

voltage_doctor は、そのこれらののどれが欠けているのかの中でも正確を報告します。したがって、キャプチャが失敗している場合、まず確認すべきはそこです。

必要条件う条件

• /dev/ 付きのLinux (X11、Wayland、またはコンソールの入れ — ディスプレイサーバーの下で注入します)

• 1B の場合は Python 3.11 以上

• voltage プロファイルの場合、約5GB の空きがあるGPU。 voltage profiles で自分のマシンに合うものを調べられます

• 高速なパスの場合は llama.cpp、または 0ビルドの遅いパスは Ollama

KDE Plasma 6 on Wayland (KWin)、CUDA、Python 3.14 で検証済み。

MCPツール

ドキュメント

• ARCHITECTURE.md — ループの動き、各選択理由、時間の費やされ方

• PLAYBOOK.md — 問作者向けのガイド

ステータス

ディスクに重みがあるかはありませんが、最大限構築および検証されています。149のテストは、ブローストDSL、ガードサンドボックス、セーフティガバナー、Playbookのコンパイル、GBNF生成、uinputのワイヤ形式、ランループ自体をカバーします(スタブモデルで駆動され、on_change知覚が静止画面でビジョンモデルをスキップすることを確認するテストを含む)。 MCPサーバーは実際のクライアントによりstdioでend-to-endに駆動されました: 13ツール、正しいスキーマ、 execute_burstが有効なバーストを受け入。, sudo rm -rf / を拒否 — でれも 照合ルールを適合ましす。

MCP server was driven end-to-end over stdio by a real client: 13 tools, correct schemas, execute_burst accepted a valid burst and refused sudo rm -rf / with both matching rules.

まだ実行されていないのはライブモデルです。それには llama.cpp のビルドと重みの取得が必要で、scripts/ がその準備を行います。また、ビルド中に意図的に実行しなかったものが2つあります — ポータルの権限ダイアログと、実際の入力インジェクションです。どちらもデスクトップ上で機能するためです。

ここからの操作手順:

./scripts/setup.sh          # reports what needs sudo, doesn't run it
./scripts/build-llama.sh    # ~15 min with CUDA
./scripts/fetch-models.sh lean
./scripts/serve.sh lean
.venv/bin/voltage doctor    # should now say READY

次に MCP クライアントで: voltage_calibrate（カーソルが実際に動くのを確認）、voltage_observe（ビジョンモデルがあなたのラベルを見つけられるかを確認）、それから voltage_journal Playbook と voltage_journal の読み取りを、dry_run=false を設定する前に行ってください。

著者

Claude Opus 5（Anthropic）が単一のセッションで最初から最後まで作成しました — アーキテクチャ、実装、テスト、ドキュメントを含みます。人間はアイデアを指定し、制約（KDE Wayland、6 GB VRAM、「コンピューター操作より高速」）を設定し、結果をレビューしましたが、コードは記述していません。

このリポジトリに組み込まれたプラットフォームの知見は、先入観ではなく、ビルド中のマシンの実機調査から得られたものです。つまり、KWin が許可リストにない実行ファイルに ScreenShot2 を拒否すること、grim が KWin では動作しないこと、MCP クライアントがセッションバスを除去してしまうことです。これらはそれぞれ、判断を余儀なくされたコード内の箇所で文書化されています。

LICENSE は個人を著作権者として指名しておらず、その理由がそこに明記されています。

ライセンス

MIT。 LICENSE を参照してください。