How to make 2 ai vtubers talk to eachother in vtube studio?

Hmm… When multiple programs need to communicate with each other, I think it’s better to use either a separate server process or a separate port in general.

Of course, there are cases where this isn’t feasible due to specific constraints—such as when opening an external port is difficult or when you want to conserve VRAM—but…

Separating them results in a cleaner implementation and makes it easier to coexist with other services.

---

Yes. Technically possible , but only if both terminals are talking to the same VTube Studio instance on 8001. In VTube Studio, port 8001 is one websocket server. If another VTS instance is already using that port, the next instance moves to 8002, then higher. So terminal 1 -> 8001 and terminal 2 -> 8001 means both terminals are controlling the same VTS window , not two separate VTS windows. (GitHub)

That means your design

• terminal 1 → 8001 → MouthOpen
• terminal 2 → 8001 → CustomMouthParam

can work only as a one-instance design. VTS explicitly allows plugins to create custom parameters and to feed data into either default or custom parameters. Those parameters then become inputs for the loaded model and any loaded Live2D items in that same instance. (GitHub)

So the real answer is:

• two VTS windows : use 8001 and 8002
• one VTS window : same port is possible, but the second terminal must control a different parameter , not the same one. (GitHub)

Will the two terminals interfere with each other on the same port?

They can , but not automatically. VTS allows multiple plugins to be connected at once. The API even reports connectedPlugins in StatisticsResponse, so multiple clients on one instance are a supported case. The interference problem is not “same port” by itself. The real rule is that only one API plugin can write to one parameter at a time in normal "set" mode. If plugin A controls MouthOpen and plugin B controls CustomMouthParam, that is fine. If both touch MouthOpen, VTS returns an error. (GitHub)

So for your one-port idea to work safely, you need all of these to be true:

• terminal 1 only sends MouthOpen
• terminal 2 only sends YourCustomParam
• neither terminal ever writes the other parameter
• your model or model-plus-item mapping is rigged so one character responds to one input and the other responds to the other input. (GitHub)

Would this cause more or less issues than what you have now?

For your current situation , I think it would usually cause more issues , not fewer. That is because you add another moving part: the custom parameter itself. Custom parameters must be created first, their names must be unique, and VTS will reject creation if a parameter with that name was already created by a different plugin. VTS also stores custom parameters in custom_parameters.json, and if a plugin’s authentication is revoked, the custom parameters created by that plugin are deleted. (GitHub)

So same-port plus custom mouth is valid, but it is more fragile than two cleanly separated instances. It adds:

• socket sharing
• plugin coordination
• custom parameter lifecycle
• rigging complexity. (GitHub)

About your token files

Using two token files is the correct direction. That reduces one major failure mode compared with a single shared token file. But it does not prove tokens are no longer part of the problem. The official API says you only need to obtain a token once and reuse it, and later authentication will fail unless pluginName and pluginDeveloper exactly match the values used when the token was created. Wrapper libraries reflect this by making persistent token storage a built-in feature. (GitHub)

So with two token files, the likely auth mistakes become:

• terminal 1 reads terminal 2’s file by mistake
• you changed pluginName
• you changed pluginDeveloper
• reconnect logic requests a fresh token instead of reusing the saved one
• one terminal created the custom parameter, but later a different plugin identity tries to manage it. (GitHub)

That means your current issue could still be on your side , even with two token files. Two files reduce risk. They do not eliminate bad identity matching or bad reconnect logic. (GitHub)

The mouth behavior problem is probably not only tokens

There is another rule that matters a lot here: if you want VTS to keep respecting your plugin’s parameter value, you have to resend that parameter at least once every second. If you stop, the parameter is considered lost and falls back to whatever controlled it before, or to default. That often looks like “it worked for a bit and then broke.” (GitHub)

So if your setup works briefly, the cause could be:

• auth mismatch on reconnect
• wrong token file used
• the terminal stops sending updates often enough
• both terminals touch the same parameter
• the custom parameter disappeared because the plugin permission was revoked. (GitHub)

My recommendation for your exact case

If you want the lowest-risk design , keep the two-instance layout:

• terminal 1 → 8001 → MouthOpen
• terminal 2 → 8002 → MouthOpen

That is simpler because each VTS instance already has its own MouthOpen, its own websocket port, and its own model context. (GitHub)

If you want the same-port design , do it only when you truly want one VTS instance. Then use:

• terminal 1 → 8001 → MouthOpen
• terminal 2 → 8001 → HyoriMouth or similar custom param

and keep the plugin identities stable, the token files separate, and the parameter ownership strict. That can work, but it is the more delicate setup. (GitHub)

My blunt answer is:

• Possible : yes
• Cleaner than two instances : no
• Likely to reduce your current problems : probably no
• Could the issue still be your implementation even with two token files : yes. (GitHub)

The most likely stable path is still two VTS instances, two ports, two token files, same standardMouthOpen, with each terminal tied to one port and one plugin identity. (GitHub)

---

Recommended default

Use two VTube Studio instances and keep the mouth parameter simple:

• terminal 1 → VTS instance on 8001 → MouthOpen
• terminal 2 → VTS instance on 8002 → MouthOpen

That matches how VTube Studio handles plugins. The API starts on 8001 by default, and if that port is already taken by another VTS instance, the next instance uses 8002, then higher. Each running VTS instance also has its own instanceID. (GitHub)

My reason for recommending this as the default is simple: it keeps instance routing , auth , and mouth control separated. Same-port designs are possible, but they add more moving parts. (GitHub)

---

Hard rules

1. Freeze plugin identity

For each terminal, pick one pluginName and one pluginDeveloper and do not change them casually. VTube Studio requires those values to match the ones used when the token was first requested, or authentication fails. (GitHub)

Good example:

• terminal 1: Goober Mouth Driver / YourName
• terminal 2: Hyori Mouth Driver / YourName

Bad example:

• changing the plugin name every test run
• using the same token with a different plugin name later (GitHub)

2. One terminal, one token file

You are already using two token files. Keep that. Store them separately and never let one terminal read or overwrite the other terminal’s file. Wrapper libraries are built around this exact idea: VTubeStudioJS exposes persistent token getter and setter hooks, and pyvts explicitly reads and writes a token file for reuse. (GitHub)

Good example:

tokens/
  goober_8001.token
  hyori_8002.token

3. Request the token once. Reuse it after that.

VTube Studio says you only need to obtain the token once. Later sessions should authenticate with the saved token instead of requesting a new one every time. Re-request only when authentication fails because the token is invalid or permissions were revoked. (GitHub)

4. Treat “same port” as “same VTS window”

If both terminals connect to 8001, they are both controlling the same VTube Studio instance. That is not a two-instance layout. If you want true separation between two VTubers, use 8001 and 8002. (GitHub)

5. One parameter, one owner

Only one plugin can set a given parameter at a time in normal "set" mode. If two plugins try to control the same parameter, VTS returns an error. This applies to both default and custom parameters. (GitHub)

That means:

• safe: terminal 1 controls MouthOpen, terminal 2 controls HyoriMouth
• unsafe: both terminals control MouthOpen in "set" mode (GitHub)

6. Keep the mouth alive

If you control a parameter through the API, VTS requires you to resend that parameter at least once every second. If you stop, the parameter is considered lost and control falls back to whatever was controlling it before, or to default. (GitHub)

For mouth animation, that means:

• send updates continuously while speaking
• stop only when you want control to fall back
• do not assume “I sent one mouth-open value, so it will stay there” (GitHub)

7. Verify the loaded model before sending mouth values

Use CurrentModelRequest after connecting. It tells you whether a model is loaded and returns modelName and modelID. You can also subscribe to ModelLoadedEvent instead of polling. (GitHub)

Safe rule:

• connect
• authenticate
• confirm the expected model is loaded
• only then start sending mouth values (GitHub)

8. Do not add custom mouth parameters until auth is stable

Custom parameters are valid, but they are tied to plugin ownership. VTS stores them in custom_parameters.json, and if that plugin’s permission is revoked, the custom parameters created by that plugin are deleted. They remain referenced in models, but they turn red until recreated. (GitHub)

So custom parameters are fine when the system is stable. They are a bad first fix when auth and reconnect logic are still unreliable. (GitHub)

9. Check rig mapping before blaming the API

If the parameter appears to move but the mouth does not behave correctly, check the VTS model config. Expressions, animation, and physics can override visible motion. The model settings docs are the place to verify this. (GitHub)

10. If you use audio routing, isolate the input

VTube Studio’s voice lipsync uses the selected microphone input, not magic global sound detection. Its lipsync docs recommend keeping the VTS cutoff low and putting a noise gate before the audio reaches VTS. That means separate virtual cables can be clean if each VTS instance listens to its own dedicated input. (GitHub)

---

Safe layout for the two-instance design

This is the safest layout for you.

terminal 1
  pluginName: Goober Mouth Driver
  pluginDeveloper: YourName
  token file: tokens/goober_8001.token
  target port: 8001
  target model: WAFFLE LOVING GOOBER
  parameter: MouthOpen

terminal 2
  pluginName: Hyori Mouth Driver
  pluginDeveloper: YourName
  token file: tokens/hyori_8002.token
  target port: 8002
  target model: hyori
  parameter: MouthOpen

Startup flow:

1. connect to assigned port
2. authenticate with that terminal’s saved token
3. if auth fails, request a new token and overwrite only that terminal’s token file
4. call CurrentModelRequest
5. confirm expected model
6. stream MouthOpen while speaking
7. on disconnect, reconnect to the same port and reuse the same token (GitHub)

---

Safe layout for the same-port custom-parameter design

Only use this if you intentionally want one VTS instance.

terminal 1 -> 8001 -> MouthOpen
terminal 2 -> 8001 -> HyoriMouth

Rules for this design:

• terminal 1 never touches HyoriMouth
• terminal 2 never touches MouthOpen
• the custom parameter is created once and by a stable plugin identity
• the model mapping is rigged so each character responds only to its intended input
• both terminals still need their own token files and stable plugin identities (GitHub)

This works, but it is more fragile than the two-instance design because you are adding custom-parameter lifecycle and shared-instance coordination on top of the existing auth rules. (GitHub)

---

What your two token files do and do not prove

Using two token files is good. It removes one big failure mode: accidental sharing of one token file across two clients. Wrapper libraries strongly suggest this kind of persistent, per-client token storage. (GitHub)

But two files do not prove the issue is no longer auth-related. You can still break authentication by:

• reading the wrong file
• changing pluginName
• changing pluginDeveloper
• requesting a new token when you should reuse the old one (GitHub)

So with two token files already in place, the likely causes become:

• identity mismatch
• wrong port
• wrong model loaded
• two clients touching the same parameter
• mouth updates not being resent often enough
• custom parameter ownership or deletion if you went that route (GitHub)

---

Do / do not

Do

• use 8001 and 8002 if you want two truly separate VTS windows (GitHub)
• keep one stable plugin identity per terminal (GitHub)
• keep one token file per terminal (GitHub)
• verify the loaded model before starting mouth control (GitHub)
• resend mouth values continuously while speaking (GitHub)

Do not

• share a token file between terminals (GitHub)
• change pluginName or pluginDeveloper after the token exists (GitHub)
• let two terminals control the same parameter in "set" mode (GitHub)
• switch to custom parameters before auth and reconnect logic are stable (GitHub)

---

My concrete recommendation

For your case, the safest practice is:

1. stay with two VTS instances
2. keep standardMouthOpen on each
3. keep two token files
4. freeze each terminal’s plugin identity
5. verify the model after connect
6. continuously resend mouth while that terminal’s TTS is speaking

I would only move to same-port plus custom mouth parameter if you explicitly want one VTS window and are willing to manage the extra fragility that comes with plugin-owned custom parameters. (GitHub)