{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicbl6jk3nhiq7jn4qaf2b26wpstetrjm74kwkg7z2pu74y4stosx4",
    "uri": "at://did:plc:pgryn3ephfd2xgft23qokfzt/app.bsky.feed.post/3mhprb7jtx3b2"
  },
  "path": "/t/how-to-make-2-ai-vtubers-talk-to-eachother-in-vtube-studio/174490#post_7",
  "publishedAt": "2026-03-23T00:07:19.000Z",
  "site": "https://discuss.huggingface.co",
  "tags": [
    "GitHub"
  ],
  "textContent": "Based on the software’s specifications, that should probably work.\n\n* * *\n\nYour current direction is sensible.\n\nThe strongest part is this: **make token cross-use impossible** , keep **different ports** , and remove as much “fallback” behavior as you can. VTube Studio expects tokens to be reused, but the token is tied to the `pluginName` and `pluginDeveloper` that created it. If those do not match later, auth fails. The official docs also show the normal pattern is persistent per-client token storage rather than ad hoc token swapping. (GitHub)\n\n## What I would keep\n\nKeep this as your main plan for now:\n\n  * terminal 1 → `8001` → `MouthOpen`\n  * terminal 2 → `8002` → `HyoriMouth`\n  * separate token files\n  * separate plugin identities\n  * no token fallback to the other file\n\n\n\nUsing different ports is the clean part here. VTube Studio starts on `8001` by default and moves to `8002`, `8003`, and so on for additional instances, so separate ports already isolate the two VTS windows. (GitHub)\n\nFixing the API popup issue on terminal 1 was also important. If the permission popup is not working, auth flow can fail before any mouth logic matters. The docs explicitly say the plugin requests permission through that popup, and users can revoke permission later from the plugin list. (GitHub)\n\n## One adjustment\n\nWith **different ports** , I would still consider starting with this first:\n\n  * terminal 1 → `8001` → `MouthOpen`\n  * terminal 2 → `8002` → `MouthOpen`\n\n\n\nThen move terminal 2 to `HyoriMouth` only after the routing and auth are stable. The reason is simple: different ports already give you instance separation. `HyoriMouth` is not needed for port-level isolation. It is only useful if you want different rig behavior on Hyori’s side. Also, custom parameters are plugin-owned and get deleted if that plugin’s permission is revoked. (GitHub)\n\nSo `HyoriMouth` is a valid **second step**. I would not make it the first stabilization step unless you already know you need custom rig logic. (GitHub)\n\n## Your “same port later” idea\n\nYes. That later test is **technically valid** if you intentionally use **one VTS instance** and keep strict ownership:\n\n  * terminal 1 → `8001` → `MouthOpen`\n  * terminal 2 → `8001` → `HyoriMouth`\n\n\n\nThat works because VTS allows multiple connected plugins, and the restriction is per-parameter: only one plugin can control a given parameter in normal `\"set\"` mode, but different plugins can control different parameters. Custom parameters are explicitly supported. (GitHub)\n\nSo your logic is right here:\n\n  * terminal 1 never touches `HyoriMouth`\n  * terminal 2 never touches `MouthOpen`\n\n\n\nIf you obey that rule, the same-port design is reasonable to test later. The main warning is that same-port means same VTS instance, so now you are debugging shared-instance coordination and custom-parameter lifecycle in addition to auth. That is why it is a later experiment, not the best cleanup target while your codebase still has conflicting paths. (GitHub)\n\n## What I would change in your code first\n\nRemove any logic that can do any of these:\n\n  * try the other terminal’s token file\n  * silently switch ports\n  * silently switch parameters\n  * request a fresh token before trying the saved one\n  * let one terminal write both mouth params\n\n\n\nThose are the exact kinds of mistakes that create “works on accident” behavior. The official docs are strict about stable token reuse, matching plugin identity, and one-plugin-per-parameter in `\"set\"` mode. (GitHub)\n\n## The safest order from here\n\n  1. **Freeze identities**\n\n     * terminal 1 has one plugin name, one token file, one port\n     * terminal 2 has one plugin name, one token file, one port\nThis matches the VTS auth model directly. (GitHub)\n  2. **Stabilize on separate ports**\n\n     * get `8001` and `8002` clean first\nThat is the officially supported multi-instance pattern. (GitHub)\n  3. **Use plain`MouthOpen` first if possible**\n\n     * only switch terminal 2 to `HyoriMouth` if you still need it\nThis avoids extra custom-parameter state while debugging. (GitHub)\n  4. **Only then test same-port later**\n\n     * one instance\n     * different parameters\n     * strict ownership\nThis is valid, but it is a separate architecture choice. (GitHub)\n\n\n\n## Bottom line\n\nYour current instincts are good.\n\n  * **Separate token files** : keep that.\n  * **Different ports** : keep that.\n  * **No possible token switching** : absolutely do that.\n  * **Terminal 2 using`HyoriMouth`**: valid, but better as a second step after the two-port setup is stable.\n  * **Same-port later with`MouthOpen` + `HyoriMouth`**: safe enough to experiment with later, as long as it is intentionally a one-instance design and each terminal owns only its own parameter. (GitHub)\n\n\n\nThe shortest practical recommendation is: **lock down token identity and ports first, stabilize there, then add`HyoriMouth`, then test same-port later if you still want it.**",
  "title": "How to make 2 ai vtubers talk to eachother in vtube studio?"
}