We launched here on Monday. The comments were less about the pitch and more about trust: how does this decide what my agent sees, and what happens to that decision when my code moves. So that is where the week went.
You can now mark the files and symbols that always matter, in secondos.yml or from the dashboard if you never open a terminal. The part worth caring about is what happens after that. Every sync re-checks each pin against the map it just built, and a pin pointing at a deleted path or a renamed symbol gets reported instead of quietly ignored. If a symbol was renamed, it looks through that file's own exports and asks whether buildGrap became buildGraph.
Then the ranking question, which is the one I expected to get. A pin only breaks a tie here. It cannot outrank a better match. We measured that on our own repo before turning it on: ten queries, three pins, two results moved by one position, top result never changed. Boosting the score was the easy version and it would have pushed correct answers down to promote a file somebody flagged last month for an unrelated reason.
Memory got the same treatment. It answered what happened, one event at a time, and that turned out not to be the question anyone had. There is now a diff that opens with the net move, plus three ways to find what you should delete: never recalled, low confidence, and stale since the code moved.
Honestly the local-first thing is huge, but I think a visual diff or timeline of what the memory actually knows about my project would be super helpful. Like, basically let me see what it's "remembering" and tweak or prune it. Otherwise I'm just trusting a black box with my whole codebase, you know
@animationstudio This is exactly the thing we didn't want to hand-wave, so it shipped: the dashboard has a Memory tab that lists every memory with the source badge (which tool and which session wrote it), and you can edit any line in place, delete it, or bulk clear. Every memory keeps its own history, so a bad edit is restorable.
The timeline is the part I think you're describing. It doesn't show syncs, it shows how the memory changed: what was learned, what replaced an older belief (with the replaced text struck through), and what went stale because the code it was anchored to moved. "This was true, then the code moved" is two events on the feed, not one.
There's also a gate before any of that. By default nothing enters memory without you accepting it from the proposal inbox. Auto-accept exists but it's opt-in per project. Stale detection is automatic too, a memory bound to a symbol that disappeared gets flagged rather than quietly kept.
What's not there yet is a visual diff of the code map itself between two points in time. That's the honest gap.
Really cool idea, the local-only memory layer is a smart angle. One thing that would make it way more useful for me: a way to manually mark certain files or sections as "important" so the AI prioritizes those when rebuilding context, instead of relying purely on heuristics about what changed. Would help with projects where the core architecture rarely changes but still matters every session.
@marlon_babbitt Straight answer: there's no explicit "pin this file" yet. It's a real gap and it's on the list.
Two things get partway there today. Memories can be scoped to a file or a symbol rather than the repo, and an anchored memory scores higher on trust than a floating note, so it surfaces first. And prime, the tool the agent calls at session start, returns the conventions and architecture decisions index regardless of what the last diff touched. So the "core architecture rarely changes but matters every session" case is handled by memory rather than by change heuristics, which I think is the case you're describing.
What's missing is you being able to say it directly instead of it being a side effect. Would you want it at file level ("always load these paths"), or at memory level ("this note is never dropped from the session opener")? That answer changes what we build.
The ~5x less reading angle is interesting since re-reading whole projects every session is a big chunk of coding-agent token cost. How does SecondOS expose its memory across different agents—does it hook in at the tool level (Claude Code, Cursor) or sit in front of the model endpoint?
@tian_yi1 Tool level, and deliberately not in front of the model endpoint. We never want your traffic or your API key passing through us.
Concretely it's an MCP server, in two flavors: a local stdio one that runs on your machine, and a hosted remote one for cloud agents. secondos init writes the config for Claude Code, Cursor, VS Code, Windsurf and Claude Desktop. About 22 tools, but the ones doing the work are prime (orient once at session start: conventions, decisions, gotchas, plus a one-line map headline), recall for a topic, search_codebase, who_uses and impact_of for the call graph, and what_changed_since.
That's where the reading reduction comes from. The agent calls prime once and recall per topic instead of walking the tree to rebuild what it already established yesterday.
Because it resolves the project from the repo you're in rather than from which tool asked, the same memory shows up in Claude Code and Cursor without doing anything twice. There's a second path too: after a session ends we can passively read the local transcript (Claude Code, Codex, Cursor) and distill decisions out of it, so the memory gets written without anyone remembering to write it.
Saved so much time on my last session, it actually remembered where I left off across two days without me re-explaining anything. The local-only thing is a nice bonus.
@dominic_ko That's the exact moment we built it for, the two-day gap where you'd normally re-explain everything. Thanks for saying so. Which tool were you in, Claude Code or Cursor? Curious whether the pickup felt as good across a tool switch as it did across days.
Pazi
Congrats on launching SecondOS! One memory for a codebase across AI tools is a genuinely exciting direction. Cheering you on and wishing you a fantastic launch! 🚀