Prime Agent users can run a capable coding-agent runtime from a terminal today, but cannot select it as a provider in T3 Code. This issue proposes adding it as a first-party provider, built on Prime's dedicated prime-agent --mode rpc transport.
I have a working implementation and would open the PR(s) if maintainers want it. Filing first per CONTRIBUTING's Issues First rule, and because the repo notes it is not actively accepting contributions right now — so this is a check on appetite before any review time gets spent.
Why not ACP
The obvious path is a generic ACP bridge, and waiting for the ACP registry to make that a drop-in. That does not work here.
Three capabilities are absent from Prime's ACP surface itself:
- No authentication surface. ACP mode advertises nothing for auth, so the provider cannot tell "not installed" from "installed but unauthenticated" — the difference between showing an install hint and showing a login hint.
- No model discovery. The model picker would have no Prime entries to list, and would need a hardcoded guess that drifts with every Prime release.
- No session loading. ACP mode deliberately advertises no session loading, so resume and fork — both first-class in T3's other providers — have nothing to build on.
Beyond that, rich task state and interactive requests would be missing or rendered inconsistently through a thin wrapper or generic bridge. I am stating that as a gap in the bridge approach, not as a proven omission in the ACP protocol — I have not audited Prime's ACP spec for those two.
Prime's dedicated RPC mode exposes what the integration needs. So the choice is a specialized integration now, or a provider that is visibly worse than the others until ACP grows these capabilities upstream — which is not on any timeline I can point at.
That tradeoff is explicit in the design: RPC is the only runtime boundary, and T3's code never falls back to ACP — Prime hardcodes --mode rpc at both probe and session launch, there is no mode override in the settings contract, and an RPC bootstrap failure surfaces as an explicit error rather than switching transport. (That is a statement about this codebase; it says nothing about the external binary's own internals.) A silent fallback would quietly downgrade auth, model discovery, and session continuity while still claiming the provider works, which is worse than an unavailable provider with a reason.
Shape of the change
- Provider adapter over
prime-agent --mode rpc (LF-delimited JSONL), with a readiness probe that runs in a disposable isolated home/session namespace and never touches live auth or state.
- Version compatibility band: minimum supported
0.7.2; known-incompatible releases blocked by denylist before RPC ever launches; unknown newer versions usable only after RPC startup and a get_state probe succeed and the authenticated model catalog comes back non-empty, with a visible advisory. (There is no separately named handshake or capability-negotiation step — that sequence is the whole of it.)
- Ownership model: exact process/resource ownership with proof-before-action cleanup, single-writer lease arbitration, and no invented native IDs or fake cancellation.
- Queued/steering text excluded from durable intents, activities, logs, and telemetry.
Notes for maintainers
Two defects in this area are already fixed in my branch and are small and independently reviewable, if it is easier to take them separately from the larger provider work:
- The probe as shipped rejected the version string the real binary prints. It required a
prime-agent -prefixed version and read only stdout; the binary prints a bare version on stderr, so a correct install of the minimum supported release reported incompatible. Now accepts bare or prefixed, stdout first with stderr as fallback.
- The probe derived the child
TMPDIR with no length budget and never created it. Prime hosts its daemon on a Unix socket beneath TMPDIR, sun_path is capped at ~104 bytes on macOS, and os.tmpdir() is already ~49 bytes there — the derived path reached 70 bytes, the daemon could not bind, and every RPC request hung until the caller timed out. Measured on macOS against prime-agent 0.7.2: a 70-byte TMPDIR hangs, a 26-byte one answers in 1.4s; the probe went from a 20.5s timeout to ~1.9s. These are my own local measurements, not a committed benchmark.
Happy to split, resequence, or drop any of this depending on what you would actually merge.
Prime Agent users can run a capable coding-agent runtime from a terminal today, but cannot select it as a provider in T3 Code. This issue proposes adding it as a first-party provider, built on Prime's dedicated
prime-agent --mode rpctransport.I have a working implementation and would open the PR(s) if maintainers want it. Filing first per CONTRIBUTING's Issues First rule, and because the repo notes it is not actively accepting contributions right now — so this is a check on appetite before any review time gets spent.
Why not ACP
The obvious path is a generic ACP bridge, and waiting for the ACP registry to make that a drop-in. That does not work here.
Three capabilities are absent from Prime's ACP surface itself:
Beyond that, rich task state and interactive requests would be missing or rendered inconsistently through a thin wrapper or generic bridge. I am stating that as a gap in the bridge approach, not as a proven omission in the ACP protocol — I have not audited Prime's ACP spec for those two.
Prime's dedicated RPC mode exposes what the integration needs. So the choice is a specialized integration now, or a provider that is visibly worse than the others until ACP grows these capabilities upstream — which is not on any timeline I can point at.
That tradeoff is explicit in the design: RPC is the only runtime boundary, and T3's code never falls back to ACP — Prime hardcodes
--mode rpcat both probe and session launch, there is no mode override in the settings contract, and an RPC bootstrap failure surfaces as an explicit error rather than switching transport. (That is a statement about this codebase; it says nothing about the external binary's own internals.) A silent fallback would quietly downgrade auth, model discovery, and session continuity while still claiming the provider works, which is worse than an unavailable provider with a reason.Shape of the change
prime-agent --mode rpc(LF-delimited JSONL), with a readiness probe that runs in a disposable isolated home/session namespace and never touches live auth or state.0.7.2; known-incompatible releases blocked by denylist before RPC ever launches; unknown newer versions usable only after RPC startup and aget_stateprobe succeed and the authenticated model catalog comes back non-empty, with a visible advisory. (There is no separately named handshake or capability-negotiation step — that sequence is the whole of it.)Notes for maintainers
Two defects in this area are already fixed in my branch and are small and independently reviewable, if it is easier to take them separately from the larger provider work:
prime-agent-prefixed version and read only stdout; the binary prints a bare version on stderr, so a correct install of the minimum supported release reportedincompatible. Now accepts bare or prefixed, stdout first with stderr as fallback.TMPDIRwith no length budget and never created it. Prime hosts its daemon on a Unix socket beneathTMPDIR,sun_pathis capped at ~104 bytes on macOS, andos.tmpdir()is already ~49 bytes there — the derived path reached 70 bytes, the daemon could not bind, and every RPC request hung until the caller timed out. Measured on macOS againstprime-agent 0.7.2: a 70-byteTMPDIRhangs, a 26-byte one answers in 1.4s; the probe went from a 20.5s timeout to ~1.9s. These are my own local measurements, not a committed benchmark.Happy to split, resequence, or drop any of this depending on what you would actually merge.