This is good, I like it!! I've been mostly working with Claude and Chatgpt for separate stuff, however sometimes one of them is stuck and I could definitely use this to start a session with the other one and see if it figures it out.
Have you tested to see if there was any degradation happening when switching from one model to the other ? I mean some must be inevitable (maybe not!), but how much?
Nars here, one of the co-founders. With longer sessions, the receiving agent sometimes decides to compact it. But the whole transcript still exists and is accessible
If I were you I would look into maybe like analyzing sessions across harnesses? I’m not sure, some way to leverage this shared schema work that is not syncing
Because syncing is trivially solved by just telling the agent to keep a work journal in markdown
We do that, and it's really the point of the portability work. Once every harness's sessions live in one schema, you can manage and search all of them in one place.
The markdown journal is a fair way to do it, and a popular one. It has a couple of limits though.
A journal comes out of a prompt, so it records one way of looking at the session. Whatever that prompt didn't ask about is gone, and you usually find out which detail you needed much later. But the raw session still has it.
Being able to unify the schema lets you do things notes can't. You can continue a teammate's session on your own machine, or pick up a claude.ai conversation in Claude Code or Codex. The new agent gets the transcript: all the decisions in the trajectory, not a summary of it.
To say what the author said in another way- thats a garbage approach and completely misses the point. Sure, you can completely destroy the session by distilling it into a markdown- but thats like explaining what you did yesterday, vs having an immutable log of what you did yesterday.
I was thinking about doing this. If we treat ChatGPT like your local llm server, you basically open up a browser session, intercept all traffic and stick a local OpenAI compatible rest server that mutilates your input upstream through the ChatGPT ui, and then intercepts downstream and pushes it out your server.
API call to server
Then
Server leverages chrome plugin to send your llm call through the plugin , through the ui, wait for response , intercept, repackage and reroute it back out as a server response.
Then that $20 sub stretches to all uses cases for a developer.
How would they know? Only if you use a coding harness, but one could write their own harness with less obvious system prompts.
I’m not encouraging one do this. I mostly route between the free models on OpenRouter and OpenCode free models, and I mostly write simple apps where I can casually oversee even a small model and get awesome results.
But if you are out there spending 200 dollars a month, consider a few hacks, because that’s just overpriced. We are developers after all, they aren’t supposed to be able to trick us :)
Edit:
Piracy, with the above , would look like a universal server that routes between all provider UIs. That means the end user doesn’t even give a shit which provider it goes to, serious token usage, serious theft.
Someone could make this , I suppose. In a way, commodification is a clean solution to the inevitable theft. It’s better it just be so darn cheap and ubiquitous.
That's a clever idea, and a different direction from where we are right now. Today it only goes one way, from chat into your coding agent.
The case I hit all the time is that an idea strikes on my commute, so I pull out my phone and start brainstorming in the Claude app. By the time I'm home I've done the research and chased down the tangents in that conversation. I open my laptop, use Skillsync to continue it in Claude Code, and start on the implementation.
Cool! Over here we mean portability in a different sense: being able to continue a session in another agent as if the entire conversation history was there the whole time. You should not get locked into one agent simply because you built up a conversation history + memory with that agent
Also curious, do you further process the synced files on dropbox at all? how are you using them today?
In my experience 95% of the session transcript I don't care about.
But there are some that I want to keep and maybe come back one month later.
Usually it's not even engineering-related. Maybe doing some research on visas, relocation.
But sometime also doing project research and sometime I want to come back to the same topic 2 month later(because new things came up) and I want my new agent to go and read prior conversation.
Yeah understandable, with skillsync you can choose for it to proactively tell you about past work that's related to what you're doing or just access all your past sessions via mcp. It's like being a musician that has the record button on the whole time for when the crazy idea strikes
Since I only support Pi natively, your solution will make it possible for codex/claude/etc. users to discover their conversations in my app. Will definitely include this as workaround for making codex, claude and other sessions available for discovery.
The only thing that seems to be missing is synching but I have a workaround for that but it won't be near realtime. For example, Pi changes are usually a second or less behind the Pi session log.
With txcript, it will probably be 5 seconds which is fine since the use case will mostly revolve around discovery, organizing and inspection.
Any word on when you'll add support for antigravity? I often switch between harnesses and models and subscriptions, both for work and personal stuff, this is an awesome idea. One thing I do that I don't think you have support for is running sessions on different machines. Do you have support for, or do you plan on adding support for, syncing across machines?
This looks nice! I tried to tackle the same problem with https://usecontinuo.dev (writing my own translation layer) - but Skillsync looks much more powerful.
This is really cool, especially in a world where you're using Claude as a workhorse, but want to be able to bring the entire session context into Codex so you can draft communications with full context but without Claude-isms. (You can train Claude to spawn e.g. a Codex session, but Codex wouldn't know what to ask for from the broader context, beyond the prompt Claude gives it.)
And shipping sessions to colleagues is critical as well. My team relies heavily on a homegrown /resume skill that forces the harness to read every part of a Claude Code JSONL into context, letting us merge colleagues' sessions into our own.
What I thought this might be from the title, though, is a separate but related problem. The more semi-technical people in a company who start to use agentic systems, the more likely they are to create a vital playbook as a "skill" - but one not designed for easy tracking in a repository, that relies on local state, references their name, references other skills and rules that they've developed for their own work, etc. Cleaning these, figuring out what should be promoted across a team, figuring out when someone makes an update whether that's something that deserves human review, syncing across people who haven't used git/pull requests before - it's a big challenge that's highly context-dependent. If skills are the place where guardrails exist, "who watches the watchmen?"
There's an interesting duality here, because a colleague being able to ship a session where they iterated on such a skill, to a colleague who can understand the context of their change, is incredibly valuable. But it still relies on a human in the loop, and doesn't scale as a result. I think there's a really interesting design space here.
Yes the name is a giveaway, that's how we started out. We wanted to make it easy for non-technical people to collaborate with technical ones. git pull does bring in some friction here. Skillsync can be used as a shared skills library out of the box. Once someone updates a skill, it hot-reloads and make the latest version available to everyone instantly
Curious about your /resume skill. You said merge, so are you pulling a colleague's session into one you already have open? We only do the other direction today, where you reopen their session and continue from it. I'd love to know which one your team reaches for more.
Yea, it's Claude Code only, but it runs some Python to turn the JSONL into markdown (importantly, with full tool inputs/outputs) then instructs the session to load every single line of that markdown, which Claude Code will do in chunks.
Certainly we're often resuming the session directly as a handoff, and it works for that, albeit with some context overhead for the markdown reads (though arguably we could just put the JSONL in the session folder and resume it natively). But if both you and a colleague have done independent investigation on the same project, it also makes "mind melds" possible, including their temporary scripts and unmerged changes - just begin the resumption within one's own session.
keeping tool_results help the agent figure out what is being referred too. But, as you said we also faced the problem of context overhead from reading markdown that's why we made continue into a cli command instead.
the mind meld thing sounds interesting, it sounds like git merge but for the transcripts
> because a colleague being able to ship a session where they iterated on such a skill, to a colleague who can understand the context of their change, is incredibly valuable
This is interesting, I've noticed some teams where the power users (usually the ones creating most of the skills) ship an additional skill to help users update their existing skills. This 'update' skill asks them questions to understand the user's context before actually updaing the skill
this is awesome! i’ve been working on a tool for cross-harness integration tests - https://dynobox.xyz - and one of the hardest parts has been writing adapters for each harness since their transcript formats are all so different.
really excited to check out txcript… a shared translation layer could make my life sooo much easier!
Very cool! I created something similar (with the same name), but in 2 tools. One to share skills (skillsync) and another to share context (contextsync).
I like to create a design with one model, sync it to another and iterate on it, then potentially go to another to apply/implement.
Love this. Easily the most annoying thing about modern Agent development across Claude, Codex, etc. One nit: You don't auto-discover "archived" chats from Codex. They have to be unarchived and the app restarted before being found.
I'll add support for this. On another note, if you know what the issue is, our core is open and I would love for you to contribute: https://github.com/skillsynchq/txcript
Good idea. I’m working on something similar, but for regular AI chats: https://www.vinaa.ai/. Portability and organization are just as important for these conversations, since they become a personal knowledge base you may want to revisit years later.
I went the opposite way, and I think it's worth mentioning the cost of that choice. My conversation doesn't carry over. Only what a session explicitly recorded does. This includes decisions, open questions, verified items, and what's left to do. Anything that wasn't recorded is gone, and that's a real loss, not just a small part of the process.
I went with this approach because the transcript doesn't go into a file; it goes into another live session, which messes up its flow. We've already talked about this a bit when we were discussing "how to make reading Markdown cheaper." My answer was different: don't bring it over at all. The next session doesn't need to know how we got there—it just needs to know what we decided and what we've actually verified.
I don't think we've talked about this in this thread yet. Portability is all about a session that's already wrapped up. I often have two sessions open at the same time. One is building an endpoint, and the other is the screen that calls it. They need to ask each other before both build on different assumptions. Moving the transcript around won't fix this. What's needed is a message, not a copy.
I made a small open-source layer for this: a mailbox and a "walkie-talkie" for sessions in the clients you've already opened - https://github.com/automatis-tools/agents-can-communicate. It doesn't transfer memory and doesn't detect discrepancies on its own. The session has to check for those things.
I agree that the next session wants conclusions, not the whole transcript. What I've seen working with people on this is that a summary only has what the summarizer prompt asked for, and what they need from an old session changes depending on what they're doing when they go back to it. With the full session still around, they can just ask it again.
Porting is also cheap, since it's just a format conversion. Getting a new session back up to speed from notes usually isn't.
Concurrent sessions is a separate problem, and I agree that a message is the right shape there. Where portability helps is that different harnesses are good at different things, so you can start a task in one and move it to another that's better at the next part, without starting over.
bcorigliano | 15 hours ago
Have you tested to see if there was any degradation happening when switching from one model to the other ? I mean some must be inevitable (maybe not!), but how much?
[OP] cat-whisperer | 15 hours ago
Narsagna | 15 hours ago
bcorigliano | 12 hours ago
pjm331 | 15 hours ago
Because syncing is trivially solved by just telling the agent to keep a work journal in markdown
[OP] cat-whisperer | 15 hours ago
The markdown journal is a fair way to do it, and a popular one. It has a couple of limits though.
A journal comes out of a prompt, so it records one way of looking at the session. Whatever that prompt didn't ask about is gone, and you usually find out which detail you needed much later. But the raw session still has it.
Being able to unify the schema lets you do things notes can't. You can continue a teammate's session on your own machine, or pick up a claude.ai conversation in Claude Code or Codex. The new agent gets the transcript: all the decisions in the trajectory, not a summary of it.
agentdev001 | 14 hours ago
Narsagna | 14 hours ago
general_reveal | 15 hours ago
API call to server
Then
Server leverages chrome plugin to send your llm call through the plugin , through the ui, wait for response , intercept, repackage and reroute it back out as a server response.
Then that $20 sub stretches to all uses cases for a developer.
deadbabe | 14 hours ago
general_reveal | 14 hours ago
I’m not encouraging one do this. I mostly route between the free models on OpenRouter and OpenCode free models, and I mostly write simple apps where I can casually oversee even a small model and get awesome results.
But if you are out there spending 200 dollars a month, consider a few hacks, because that’s just overpriced. We are developers after all, they aren’t supposed to be able to trick us :)
Edit:
Piracy, with the above , would look like a universal server that routes between all provider UIs. That means the end user doesn’t even give a shit which provider it goes to, serious token usage, serious theft.
Someone could make this , I suppose. In a way, commodification is a clean solution to the inevitable theft. It’s better it just be so darn cheap and ubiquitous.
[OP] cat-whisperer | 14 hours ago
[OP] cat-whisperer | 14 hours ago
The case I hit all the time is that an idea strikes on my commute, so I pull out my phone and start brainstorming in the Claude app. By the time I'm home I've done the research and chased down the tangents in that conversation. I open my laptop, use Skillsync to continue it in Claude Code, and start on the implementation.
podviaznikov | 15 hours ago
i do the same for apple notes and imessage. so very portable
https://apps.apple.com/us/app/exporter-notes-to-markdown/id6...
Narsagna | 14 hours ago
Also curious, do you further process the synced files on dropbox at all? how are you using them today?
podviaznikov | 13 hours ago
In my experience 95% of the session transcript I don't care about.
But there are some that I want to keep and maybe come back one month later.
Usually it's not even engineering-related. Maybe doing some research on visas, relocation.
But sometime also doing project research and sometime I want to come back to the same topic 2 month later(because new things came up) and I want my new agent to go and read prior conversation.
Narsagna | 9 hours ago
sdesol | 14 hours ago
https://github.com/gitsense/chat/tree/readme-scale-knowledge
Since I only support Pi natively, your solution will make it possible for codex/claude/etc. users to discover their conversations in my app. Will definitely include this as workaround for making codex, claude and other sessions available for discovery.
[OP] cat-whisperer | 14 hours ago
you can use that internally for this
sdesol | 14 hours ago
The only thing that seems to be missing is synching but I have a workaround for that but it won't be near realtime. For example, Pi changes are usually a second or less behind the Pi session log.
With txcript, it will probably be 5 seconds which is fine since the use case will mostly revolve around discovery, organizing and inspection.
marknutter | 14 hours ago
[OP] cat-whisperer | 13 hours ago
Narsagna | 13 hours ago
yoavfr | 13 hours ago
Narsagna | 9 hours ago
btown | 13 hours ago
And shipping sessions to colleagues is critical as well. My team relies heavily on a homegrown /resume skill that forces the harness to read every part of a Claude Code JSONL into context, letting us merge colleagues' sessions into our own.
What I thought this might be from the title, though, is a separate but related problem. The more semi-technical people in a company who start to use agentic systems, the more likely they are to create a vital playbook as a "skill" - but one not designed for easy tracking in a repository, that relies on local state, references their name, references other skills and rules that they've developed for their own work, etc. Cleaning these, figuring out what should be promoted across a team, figuring out when someone makes an update whether that's something that deserves human review, syncing across people who haven't used git/pull requests before - it's a big challenge that's highly context-dependent. If skills are the place where guardrails exist, "who watches the watchmen?"
There's an interesting duality here, because a colleague being able to ship a session where they iterated on such a skill, to a colleague who can understand the context of their change, is incredibly valuable. But it still relies on a human in the loop, and doesn't scale as a result. I think there's a really interesting design space here.
[OP] cat-whisperer | 13 hours ago
Curious about your /resume skill. You said merge, so are you pulling a colleague's session into one you already have open? We only do the other direction today, where you reopen their session and continue from it. I'd love to know which one your team reaches for more.
btown | 12 hours ago
Certainly we're often resuming the session directly as a handoff, and it works for that, albeit with some context overhead for the markdown reads (though arguably we could just put the JSONL in the session folder and resume it natively). But if both you and a colleague have done independent investigation on the same project, it also makes "mind melds" possible, including their temporary scripts and unmerged changes - just begin the resumption within one's own session.
[OP] cat-whisperer | 12 hours ago
the mind meld thing sounds interesting, it sounds like git merge but for the transcripts
Narsagna | 13 hours ago
This is interesting, I've noticed some teams where the power users (usually the ones creating most of the skills) ship an additional skill to help users update their existing skills. This 'update' skill asks them questions to understand the user's context before actually updaing the skill
bhkdotdev | 13 hours ago
really excited to check out txcript… a shared translation layer could make my life sooo much easier!
sean-regents | 13 hours ago
bhkdotdev | 13 hours ago
Narsagna | 12 hours ago
swyx | 12 hours ago
Narsagna | 12 hours ago
voiceeh | 12 hours ago
I like to create a design with one model, sync it to another and iterate on it, then potentially go to another to apply/implement.
Narsagna | 12 hours ago
solfox | 12 hours ago
[OP] cat-whisperer | 12 hours ago
[OP] cat-whisperer | 12 hours ago
solfox | 12 hours ago
solfox | 11 hours ago
[OP] cat-whisperer | 11 hours ago
sujee | 10 hours ago
Narsagna | 9 hours ago
bb-connor | 7 hours ago
Narsagna | 7 hours ago
bks | 6 hours ago
vira28 | 7 hours ago
1. It's tightly integrated with Pi 2. Creates context automatically from sessions 3. No external dependencies - sqlite and numpy
Narsagna | 6 hours ago
mmykola87 | 5 hours ago
I went with this approach because the transcript doesn't go into a file; it goes into another live session, which messes up its flow. We've already talked about this a bit when we were discussing "how to make reading Markdown cheaper." My answer was different: don't bring it over at all. The next session doesn't need to know how we got there—it just needs to know what we decided and what we've actually verified.
I don't think we've talked about this in this thread yet. Portability is all about a session that's already wrapped up. I often have two sessions open at the same time. One is building an endpoint, and the other is the screen that calls it. They need to ask each other before both build on different assumptions. Moving the transcript around won't fix this. What's needed is a message, not a copy.
I made a small open-source layer for this: a mailbox and a "walkie-talkie" for sessions in the clients you've already opened - https://github.com/automatis-tools/agents-can-communicate. It doesn't transfer memory and doesn't detect discrepancies on its own. The session has to check for those things.
[OP] cat-whisperer | 4 hours ago
Porting is also cheap, since it's just a format conversion. Getting a new session back up to speed from notes usually isn't.
Concurrent sessions is a separate problem, and I agree that a message is the right shape there. Where portability helps is that different harnesses are good at different things, so you can start a task in one and move it to another that's better at the next part, without starting over.