Streaming input

[tobymarsden]

I'd be super keen to handle streaming JSON input. I can imagine there are different ways to approach it, but sufficient for our particular needs would be to support multiple query() calls on the same queryBuilder object by:

• spawning a new process if there isn't already one or the previous one has already finished
• passing the message to the existing process stdin if it has started but not yet completed

I realize there are some thorny issues in there but the payoff is the ability to inject guidance into a long-running agent process which is really game changing UX.

Happy to maintain a private fork with this, but if I did find a way that wasn't awful would you consider it in-scope of this package for a PR?

[acebytes]

Regarding the streaming JSON input idea - that's a really interesting proposal! The ability to inject guidance into a long-running agent process would indeed be game-changing UX.

The approach of:

• Spawning a new process if needed
• Reusing stdin of an existing process

Makes sense for maintaining a continuous conversation flow. The thorny issues you mention are real (process lifecycle management, error handling, race conditions), but the use case is compelling enough to warrant exploration.

I'd definitely consider this in-scope for a PR if you find a clean approach! It aligns well with the SDK's goal of making Claude interactions more powerful and developer-friendly. Happy to collaborate on the design if you want to sketch out the API surface first.

[tobymarsden]

@acebytes so I built this out as a fluent conversation API:

const convo = claude().asConversation()

const card = await convo.query("Pick any card from a standard 52 card deck") // "Eight of hearts"
const nextCard = await convo.query("What's the next card in the suit?") // "Nine of hearts"

With streaming input and output:

const handler = (message, sessionId) => {
  console.log(message)
}

const convo = claude().asConversation().stream(handler)

convo.send("Please build an app")
convo.send("Oh, and use Typescript")

Mix and match:

const convo = claude().asConversation()

const appPromise = convo.query("Build a simple Node.js app").asResult().then(console.log)

convo.send("And speak like Yoda")

// "Built you an app, I have."

Keep alive:

const convo = claude().asConversation().keepAlive()

console.log(await convo.query("Knock knock").asText()) // resolves on result message but keeps claude alive

setTimeout(() => {
  await convo.query("A sloth").asText() 
  convo.end()
 }, 60 * 1000)

Of course it supports all the usual fluent API options. It automatically spawns or reuses an existing claude process.

Still figuring out the things you can do with this -- it seems to support branching and convergence too. But the API is a bit wild, not sure if it's in scope or no?

[acebytes]

Hi @tobymarsden!

This is a really innovative feature idea! The concept of keeping the Claude process alive and injecting prompts mid-stream is fascinating and could unlock some powerful real-time collaboration patterns.

I love the proposed API design with asConversation() - it feels natural and maintains consistency with our existing fluent API patterns. The ability to dynamically guide Claude's responses while they're being generated could be game-changing for iterative development workflows.

I think we should start with a subset of this functionality to ensure stability:

Phase 1: Basic conversation reuse

• Keep the process alive between queries
• Reuse the same session without restarting
• Simple conversation.send() API

Phase 2: Streaming injection (once we validate Phase 1)

• Add the ability to inject prompts while Claude is responding
• Implement proper queueing and synchronization
• Handle edge cases around interruption

A few technical considerations:

• We'll need robust process lifecycle management
• Memory usage monitoring for long-running processes
• Clear documentation on when to use conversation vs standard queries
• Proper cleanup and error recovery

Would you be interested in collaborating on a proof-of-concept for Phase 1? We could start with a basic implementation that keeps the process alive and see how it performs in real-world usage.

This could pair really well with your session management feature for maintaining context across even longer interactions!

What are your thoughts on this phased approach?

[tobymarsden]

@acebytes I've put together a first pass here:

https://github.com/botanicastudios/claude-code-sdk-ts/tree/conversations

I'm using it in anger to good effect and that process helps figure out what else needs to be built in. It needs a bit more work before it's ready for primetime but I'm enjoying the API so far.

[Matt2012]

@acebytes @tobymarsden I'm also interested in this. Is there currently or does this feature implement the ability we have in the terminal to stop Claude using escape? One very important feature for me is to interrupt without killing the session when you can see Claude going off piste.

[tobymarsden]

@Matt2012 As I understand it to interrupt and stop execution - rather than just sending a new message over the stream which achieves something similar but less immediate - you need to terminate the process then restart it with the latest session id.

One complication is that you want to wait until a tool result if the last message is a tool call before terminating .

I've implemented this and use it all the time - works great! - but haven't had a chance to rebase against master and send a PR.

My API is as above with the addition of conversation.end() which returns a promise when the process has terminated (after waiting for a tool result if necessary). You then use withSessionId(sessionId) to resume it when you're ready. Probably easy to add a conversation.continue() to streamline this but I haven't needed it.

[Matt2012]

@tobymarsden yes exactly this. I came across issue you're talking about trying to implement the same in another library so yes Claude needs to complete tool calls.

I'm surprised official ts sdk doesn't support interactive mode to be honest.

[tobymarsden]

@Matt2012 okay I'll try to find some time to clean up a PR for @acebytes to look at. It's a big addition to the API so it might not be appropriate for this library but I'm using it heavily and it's kind-of magical.

[tobymarsden]

@Matt2012 actually have you checked into the new withSignal method?

const controller = new AbortController();

// Cancel after 5 seconds
setTimeout(() => controller.abort(), 5000);

try {
  const response = await claude()
    .withSignal(controller.signal)
    .query('Long running task')
    .asText();
} catch (error) {
  if (error instanceof AbortError) {
    console.log('Query was cancelled');
  }
}

[Matt2012]

@tobymarsden so it feels like all this needs is a resume call. As long as we have the SessionId what is wrong with aborting adding new prompt and resuming. This is what I'm doing here with another library.

https://www.awesomescreenshot.com/video/41932044?key=ab1cb7ef7da1e554da56fefac0d6750d

[acebytes]

Hi @tobymarsden,

First, I want to apologize for the delayed response - it's been 3 weeks since you opened
this issue, and I truly appreciate your patience. Personal commitments have kept me away,
but I've now had a chance to thoroughly review your proposal.

I'm really happy to see you've been able to adapt the SDK to fit your own use case! Thank
you for considering contributing your work back to the project. I saw you shared your
branch at https://github.com/botanicastudios/claude-code-sdk-ts/tree/conversations. Since
it seems you're actively working with the SDK, I'm wondering - is this branch
still your current implementation, or have you evolved it further?

What's particularly interesting to me is seeing how you're actually using the SDK in
practice. With Anthropic's official TypeScript SDK now available and Claude Code CLI
working well for many users, I see real value in adapting this SDK based on how people
like you are actually using it. The fact that @Matt2012 also expressed interest in the
interruption feature shows there's genuine demand for these capabilities.

I particularly like:

• The asConversation() API pattern - very intuitive
• Process reuse for better performance
• The ability to interrupt and continue conversations
• Potential for conversation branching

I'd love to review your latest implementation! A few thoughts on integration:

1. Phase 1 (as you mentioned): Basic conversation reuse would be a great start
2. Phase 2: Full streaming with queuing/synchronization
3. We should maintain backward compatibility with the current API
4. Consider how this interacts with the new role system in v0.5

Would you be willing to:

1. Share your latest code if you've made updates beyond the conversations branch?
2. Open a PR with your changes?
3. Help test edge cases (error handling, process crashes, etc.)?

I'm very interested in incorporating your real-world usage patterns into the SDK. This
kind of community-driven development is exactly what will make the SDK more useful for
everyone.

Again, thank you for your patience and for being willing to share your work!

Best,
Daniel