Version 0.1.0: How do I add multiples of the same Provider from the ACP Registry?

[AshleyJackson]

I've just updated to 0.1.0 which now supports Factory Droid through the ACP Registry, however it seems like I can only add one Instance of this provider?

My thought would be that we'd want to be able to add multiple instances of the same ACP? e.g. Account # 1, Account # 2, etc... if we're paying for multiple accounts, or One for Work, One for Personal?

Is there a way to achieve this in 0.1.0? Or will this need a feature request?

Thanks in advance.

[FelixFangX]

Not through the registry search in 0.1.0. It intentionally shows an agent you've already configured as "Added" and disables the button (see isConfiguredAcpRegistryAgent, used in AcpRegistrySearchStep.tsx).

What should work is Settings → Providers → Add provider → Local ACP command. Point it at the same executable and arguments the registry instance uses, and give it its own name. Each instance has its own environment variables.

One caveat from the ACP provider docs: sign-in is stored in the agent's own credential store, and "adding another instance does not guarantee a separate account". So for two Droid accounts you'd need to keep them apart on Droid's side, e.g. via API keys in each instance's env. Proper multi-instance support for registry agents sounds like a good feature request.

[AshleyJackson]

Thanks for the info dump @FelixFangX.
That helped point me in the right direction to add another provider.

After going through your steps listed, I get an error where it can't create an ACP Test session.

I don't believe simply adding another ACP works via your instructions?

Running in Windows BTW, and the other instance of Droid works perfectly.
The install of Droid is relatively new (New Laptop), not old.

Do you have any other ideas as to what could be causing this?

[FelixFangX]

@AshleyJackson that one's on me. I said to use the same arguments as the registry instance but never wrote them out, and the registry card doesn't show them. @shurkanTwo has it right: with Arguments empty, t3code starts plain droid, which is the interactive TUI and not ACP, so the test session can't be created.

On the Personal instance keep Executable as droid and use Add argument three times:

exec
--output-format
acp

One value per row. exec --output-format acp in a single row fails the same way. Keep FACTORY_API_KEY under Variables like you have it. (The registry entry itself runs exec --output-format acp-daemon, both work.)

To check it, refresh the provider. If the status changes to "could not complete authentication", the launch is fixed and it's down to the key. Once it shows models you're good. I tried the empty, single-row and three-row versions against droid 0.244.0 here, and only the three-row one gets through the ACP handshake.

If it still fails on Windows, run where.exe droid in PowerShell. If you get a droid.cmd (npm install), t3code won't run it because local commands start without a shell, so put the full path to droid.exe in Executable instead (Factory's installer puts it at C:\Users\<you>\bin\droid.exe). Another option is to skip the local command: Add provider, Enter manually, agent ID factory-droid, name it Personal, then add the key under its Variables. Only the registry search list blocks duplicates, so that gives you a second copy of the same Droid setup your Work instance uses.

[shurkanTwo]

For the test-session error in your follow-up, there is a concrete missing piece in the screenshot: the executable is droid, but Arguments is empty. Droid needs to be started in ACP mode.

Keep the executable as droid and add these as three separate argument rows:

1. exec
2. --output-format
3. acp

That launches droid exec --output-format acp, which is the command in Factory's official ACP configuration. For API-key authentication, Factory documents FACTORY_API_KEY in that instance's environment. T3's Local ACP command documentation confirms that each argument goes in its own row; the executable field should not contain the whole command line.

Then retry the provider check. This addresses the missing ACP startup arguments; it doesn't establish that the second account is authenticated correctly. If the test session still fails, the provider/server error output would help narrow down the next problem.

[shurkanTwo]

@AshleyJackson did the three separate argument rows (exec, --output-format, acp) get the second Droid instance working? If so, could you mark the reply that solved it as the answer? That makes it easier to find for the next person setting up multiple ACP instances.