You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Orca IDE now integrates prime-agent (launch + session history) — heads-up and two stability questions #808
Hi! I've implemented prime-agent support in Orca (an open-source agentic IDE that already hosts Pi and OMP): stablyai/orca#12935, currently in review with maintainer QA passed.
What Orca consumes, so you know which surfaces an integration now depends on:
launch contract: positional [message...] behind the documented -- separator; -p/--print and --mode json|rpc|acp|daemon recognized as non-interactive
PRIME_AGENT_CODING_AGENT_DIR (verbatim agent dir) and PRIME_AGENT_SESSION_DIR/legacy alias for locating sessions/
the session JSONL format (v3 tree headers, session/model_change/message records) for the session-history browser, including incremental append-parsing
prime-agent --resume <path|id> for resuming from history; ~/.prime/agent/skills for skill discovery; the npm entrypoint node_modules/prime-agent/dist/bundle/cli.js for process recognition
Two questions:
Do you treat the session-file format and the env/CLI contracts above as stable across minor releases? Any planned v4 format changes worth preparing for?
For a follow-up (live status in Orca's UI — the same thing we do for Pi via a managed extension in ~/.pi/agent/extensions), is the extension API from ~/.prime/agent/extensions the intended long-term surface, or is there a better hook for host-IDE integrations?
Happy to adjust the integration if any of these contracts are about to move.
Update with material context: the Orca integration (stablyai/orca#12935) has since been fully reviewed — the maintainer's verdict on the code is clean, with end-to-end QA passed — but the merge is now on hold explicitly pending the stability of the contracts this issue asks about (maintainer's comment):
Prime Agent is moving fast at the moment (~3 releases a week), and our integration leans on its launch, resume, and transcript contracts staying put. Supporting an agent is an ongoing commitment on our side, so I'd rather pick this up once the CLI surface settles.
So a statement on the two questions above — even a lightweight one, e.g. "session format v3 and the documented env/CLI surface are stable within 0.x; breaking changes get a migration note in release notes" — would directly unblock Prime Agent shipping as a supported agent in an IDE. Happy to adapt the integration to whichever surface you'd rather commit to.
Follow-up: the integration merged — prime-agent now ships as a supported agent in Orca as of stablyai/orca#12935 (in main, rolling out with the next release). Launch with prompt injection, process recognition, and session history (transcript indexing plus --resume by path) all work against the contracts listed above.
Notably, the Orca maintainers unblocked it by auditing your releases themselves rather than waiting on an answer here: across v0.7.0 → main, the CLI args parser and the session serializer are byte-identical — the release cadence lives in the RLM/daemon layer, not in the surfaces an IDE consumes. That empirical result is what carried the decision, together with the structural point that these are Pi's contracts under a rebrand.
That resolves question 1 in practice. Question 2 is now the live one, and it's concrete rather than hypothetical: the next step is delivering live agent status into Orca's UI, which for pi is done through a managed extension installed into ~/.pi/agent/extensions. The Orca side is explicitly holding that work because the extension API is the one surface they consider churn-exposed.
So, concretely: is ~/.prime/agent/extensions the surface you intend to keep for host-IDE integrations, or would you rather integrations hook in somewhere else? Even a short answer — "it's Pi's extension API and we track it", or "we plan to change X" — lets this get built on the right thing instead of guessed at. Happy to share what the pi-side extension does if that's useful context.
@sethkarten — sorry to tag you directly; you're clearly the one triaging here, and this is a small question with a v0.8-shaped deadline.
Context in the thread above: prime-agent now ships as a supported agent in Orca (stablyai/orca#12935, merged). The remaining piece is live agent status, which for pi is delivered by a managed extension installed into ~/.pi/agent/extensions. Orca is holding that work on one question: is ~/.prime/agent/extensions a surface you intend to keep for host-IDE integrations, or would you rather they hook in elsewhere?
One concrete finding while probing v0.7.1, which may be relevant to v0.8 either way: extensions load automatically from that directory and the API surface matches pi's (24 methods, session_start / before_agent_start / agent_start / agent_end all fire) — but sessionManager is not exposed, neither on the extension object nor in any event context. pi's extension API exposes it, and integrations use getSessionId() / getSessionFile() to bind a UI pane to the session it's showing. If that omission is deliberate, knowing so is enough — we'll design around it. If it's an oversight from the rebrand, it's a small delta with outsized value for anything embedding prime-agent.
Hi, thanks for taking the time to report this! Since open sourcing Prime Agent, we’ve received far more Issues than we can reliably triage and maintain. Rather than leave a large backlog that we cannot meaningfully work through, we’re closing the current Issue queue and moving to a discussion-first process.
We have established new contribution guidelines to help us continue iterating on Prime Agent and better manage contributions from the community. Going forward, GitHub Issues will be our maintainer work queue rather than the initial place for public reports and requests. Bug reports, feature requests, questions, and other feedback should begin in GitHub Discussions. Please read the full process documented in our contribution guidelines. Security vulnerabilities should continue to be reported privately according to our security policy.
While we’re closing this backlog, we’re still reviewing it at a high level to identify recurring bugs, useful ideas, and important problems that we should address ourselves. Thanks again for the time you put into this!
Activity
smwbev commentedon Aug 7, 2026
Update with material context: the Orca integration (stablyai/orca#12935) has since been fully reviewed — the maintainer's verdict on the code is clean, with end-to-end QA passed — but the merge is now on hold explicitly pending the stability of the contracts this issue asks about (maintainer's comment):
So a statement on the two questions above — even a lightweight one, e.g. "session format v3 and the documented env/CLI surface are stable within 0.x; breaking changes get a migration note in release notes" — would directly unblock Prime Agent shipping as a supported agent in an IDE. Happy to adapt the integration to whichever surface you'd rather commit to.
smwbev commentedon Aug 11, 2026
Follow-up: the integration merged — prime-agent now ships as a supported agent in Orca as of stablyai/orca#12935 (in
main, rolling out with the next release). Launch with prompt injection, process recognition, and session history (transcript indexing plus--resumeby path) all work against the contracts listed above.Notably, the Orca maintainers unblocked it by auditing your releases themselves rather than waiting on an answer here: across v0.7.0 → main, the CLI args parser and the session serializer are byte-identical — the release cadence lives in the RLM/daemon layer, not in the surfaces an IDE consumes. That empirical result is what carried the decision, together with the structural point that these are Pi's contracts under a rebrand.
That resolves question 1 in practice. Question 2 is now the live one, and it's concrete rather than hypothetical: the next step is delivering live agent status into Orca's UI, which for pi is done through a managed extension installed into
~/.pi/agent/extensions. The Orca side is explicitly holding that work because the extension API is the one surface they consider churn-exposed.So, concretely: is
~/.prime/agent/extensionsthe surface you intend to keep for host-IDE integrations, or would you rather integrations hook in somewhere else? Even a short answer — "it's Pi's extension API and we track it", or "we plan to change X" — lets this get built on the right thing instead of guessed at. Happy to share what the pi-side extension does if that's useful context.smwbev commentedon Aug 11, 2026
@sethkarten — sorry to tag you directly; you're clearly the one triaging here, and this is a small question with a v0.8-shaped deadline.
Context in the thread above: prime-agent now ships as a supported agent in Orca (stablyai/orca#12935, merged). The remaining piece is live agent status, which for pi is delivered by a managed extension installed into
~/.pi/agent/extensions. Orca is holding that work on one question: is~/.prime/agent/extensionsa surface you intend to keep for host-IDE integrations, or would you rather they hook in elsewhere?One concrete finding while probing v0.7.1, which may be relevant to v0.8 either way: extensions load automatically from that directory and the API surface matches pi's (24 methods,
session_start/before_agent_start/agent_start/agent_endall fire) — butsessionManageris not exposed, neither on the extension object nor in any event context. pi's extension API exposes it, and integrations usegetSessionId()/getSessionFile()to bind a UI pane to the session it's showing. If that omission is deliberate, knowing so is enough — we'll design around it. If it's an oversight from the rebrand, it's a small delta with outsized value for anything embedding prime-agent.kevinjosethomas commentedon Aug 15, 2026
Hi, thanks for taking the time to report this! Since open sourcing Prime Agent, we’ve received far more Issues than we can reliably triage and maintain. Rather than leave a large backlog that we cannot meaningfully work through, we’re closing the current Issue queue and moving to a discussion-first process.
We have established new contribution guidelines to help us continue iterating on Prime Agent and better manage contributions from the community. Going forward, GitHub Issues will be our maintainer work queue rather than the initial place for public reports and requests. Bug reports, feature requests, questions, and other feedback should begin in GitHub Discussions. Please read the full process documented in our contribution guidelines. Security vulnerabilities should continue to be reported privately according to our security policy.
While we’re closing this backlog, we’re still reviewing it at a high level to identify recurring bugs, useful ideas, and important problems that we should address ourselves. Thanks again for the time you put into this!