Feature Request: Support for Remote Agent SDKs (OpenAI Codex/Assistants, Anthropic Agent SDK)

[Sudarsh1010]

Hello Maintainers,

Context

I am right now playing around with rust and gpui to build mvp on coding agents harness. and was looking to use rig as backbone for agent orchestration.

While investigating the ecosystem, I noticed a gap between the TypeScript ecosystem and what rig currently offers.

In the typescript ecosystem, there's native support for connecting Managed/Remote agents via their official sdks:

• OpenAI
• Claude

These SDKs allows developer to leverage existing subs, where agent loop happens on the provider's side.

Proposal

Does it make sense for rig to support these "Remote Agent" workflows?

Ideally, I would love to see a generic interface where I can interact with these hosted agents just as easily as I interact with a standard chat model in rig. Currently, to use these features, I have to bypass rig entirely and use the raw provider SDKs.

Thanks for the great work on this library.
If this feature aligns with rig, I am happy to contribute on this.

---

related discussions:
#1034 (they are trying to replace rig for claude agent sdk, but I am trying to propose a feature)

[gold-silver-copper]

Thanks for the proposal.

Today Rig’s core abstractions are built around local orchestration over a CompletionModel plus Rig-managed tools/context. We don’t currently have a first-class abstraction for provider-hosted / remote agent runtimes where the agent loop, session lifecycle, permissions, tracing, and tool execution live on the provider side.

So the main issue is not the transport itself, but the runtime model. Supporting this cleanly would likely require new groundwork in Rig around things like:

• remote sessions / runs
• provider-managed streaming/event models
• permissions / approvals
• tracing / artifacts
• hooks that operate on remote agent lifecycle events rather than the current local tool-loop hooks

Because of that, I don’t think this fits neatly into the existing CompletionModel / local Agent abstractions today.

That said, the use case makes sense. The most practical near-term path would probably be:

1. wrap an external/hosted agent as a Rig Tool, or
2. prototype this as an integration crate / experimental crate first

That would let us validate the API shape before committing to a new core abstraction in rig-core.

If you’re interested in contributing, I think an integration-crate prototype would be the best place to start. In particular, it would be useful to see what the minimal common surface actually is across providers (session/run, input, streaming events, final output, cancellation, etc.).