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

Based on the software’s specifications, that should probably work.

Your current direction is sensible.

The 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)

What I would keep

Keep this as your main plan for now:

• terminal 1 → 8001 → MouthOpen
• terminal 2 → 8002 → HyoriMouth
• separate token files
• separate plugin identities
• no token fallback to the other file

Using 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)

Fixing 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)

One adjustment

With different ports , I would still consider starting with this first:

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

Then 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)

So 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)

Your “same port later” idea

Yes. That later test is technically valid if you intentionally use one VTS instance and keep strict ownership:

• terminal 1 → 8001 → MouthOpen
• terminal 2 → 8001 → HyoriMouth

That 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)

So your logic is right here:

• terminal 1 never touches HyoriMouth
• terminal 2 never touches MouthOpen

If 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)

What I would change in your code first

Remove any logic that can do any of these:

• try the other terminal’s token file
• silently switch ports
• silently switch parameters
• request a fresh token before trying the saved one
• let one terminal write both mouth params

Those 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)

The safest order from here

1. Freeze identities

   • terminal 1 has one plugin name, one token file, one port
   • terminal 2 has one plugin name, one token file, one port

This matches the VTS auth model directly. (GitHub) 2. Stabilize on separate ports

 * get `8001` and `8002` clean first

That is the officially supported multi-instance pattern. (GitHub) 3. Use plainMouthOpen first if possible

 * only switch terminal 2 to `HyoriMouth` if you still need it

This avoids extra custom-parameter state while debugging. (GitHub) 4. Only then test same-port later

 * one instance
 * different parameters
 * strict ownership

This is valid, but it is a separate architecture choice. (GitHub)

Bottom line

Your current instincts are good.

• Separate token files : keep that.
• Different ports : keep that.
• No possible token switching : absolutely do that.
• Terminal 2 usingHyoriMouth: valid, but better as a second step after the two-port setup is stable.
• Same-port later withMouthOpen + 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)

The shortest practical recommendation is: lock down token identity and ports first, stabilize there, then addHyoriMouth, then test same-port later if you still want it.