Support other agents' transcripts

[daaain]

I do feel a bit of regret naming the library so explicitly after Claude Code back in the days and sometimes wonder if we should support other agents' transcript formats. But maybe this is not a huge issue as Github supports redirects, though not sure about pypi.

I think the code is well structured and abstracted for implementing other parsers. I haven't used other agents enough though to know if they have very different concepts and use cases that might complicate the DAG and rendering. I did use Pi a bit to know that it's super customisable, but not sure how much the plugins would change the transcript? I guess they would need to to make the sessions resumable?

My biggest concern is that each of these agents are going quite fast and it's been challenging enough to keep up with Claude Code only. That said, most of the other ones are open source, so it might be possible to implement a semi-deterministic way to extract their transcript format and semantics.

[iansherr]

They all appear to be running roughly similar output/chat storage types, so the changes should hopefully not be too quick to keep up with. The provider abstraction is already clean, so we can add new providers relatively easy from here.

Personally, I like this idea because I find myself using many different CLIs, whether for subscription access reasons or playing with new tools. So, I see this repo as an opportunity to provide a connecting-glue tool between them. And it's relatively easy to lean on filtering to track or narrow scope when viewing if the archived logs suddenly become too unwieldy.

[cboos]

I used Antigravity a bit when it came out, and looked into its logs. It's a pretty straightforward, much simpler (linear) format.

I don't use it that much yet (and none of the others either, I admit), so I don't have a pressing need for an "antigravity-log" equivalent to claude-code-log yet. But when I thought about it, I was of the mind to restart from scratch for this one, rather than make claude-code-log more complex than it already is to support a simpler log format. But maybe there can be some synergy (reusing the output "formats"), or maybe I'm just wrong, and this is doable. I'll take a look at the PR sometime later. Thanks for the contribution, in any case!

[cboos]

So, to share my own impressions after the review of #225 and testing it on a few agy sessions: it's true there's a lot of room for improvements, but it's already useful, and the abstraction seems to be working. So, thanks for the PoC; it indeed shows that this can be a workable approach with minimal impact.