Thanks for the welcome on launch day! Appreciate the warm reception an insightful questions. A few clarifications on the most common asks + some onboarding updates:
Pricing: https://scritty.dev/#pricing - self serve individual and team pilot licenses are now live!
Personal Pilot (direct): https://buy.stripe.com/00weV56jD...
Team Pilot (direct): https://buy.stripe.com/4gM00b4bv...
Enterprise (k8s/managed deployments) isn't self serve as it needs a bit of setup on our side, so please reach out directly and we'll get you going
Personal + Team, you're up and running in under 5 minutes on the embedded backend -- install the binary, drop in your license key, and go.
You can also hook up your own backend (qdrant/pgvector/chroma/weaviate), and our team is happy to help with that or point you at the docs.
Enterprise is our hybrid and fully air gapped options; this has variable setup time, driven mostly by your security posture, networking, and existing infrastructure. Assuming right internal resources are engaged with our onboarding team, it's typically stood up and validated within one work day.
scritty
We built scritty because we got tired of agents making me repeat myself.
Deep into a problem on Claude, we'd hit the usage limit mid thought or debugging, so then we would go over to Copilot which is now a new empty session, so we'd bring it up to speed by pasting context back in. Hit that wall and then do the same thing on Codex. Run that one dry and off to Antigravity. Burn that out and don't want to wait for limit refreshes so switch to running local Ollama and repeat. Same project the whole way, and every switch turns into the same tedious, token-wasting chore: copy+pasting old conversation, dropping in screenshots, jamming as much as you can into the prompt and hoping for the best.
So we built a terminal they all run inside. It sits where every one of them already is, captures the conversation as it happens, and turns it into one searchable memory that carries across every switch.
You run any AI CLI inside scritty. It detects what agent is running from the process itself, tags every exchange with the provider, and indexes it locally into an embedded vector store (swappable if you already run qdrant, pgvector, chroma, or weaviate). Search is hybrid and fully offline. Then it exposes that knowledge base over an MCP server and a CLI, so your agents can query their own and each other's past turns, and you can query it as you work.
Two things we use every day:
- prompt.toml: Because I own the terminal, I can write my rules once and scritty injects them into every message before it reaches whichever agent is running, plus that vendor's own rule file. Markdown files with rules are great, but their relevance is prone to decay, whereas this is in the agent's face every turn (or toggle it off when you don't need/want it).
- Phone sync: same terminal session is live on my phone as a PWA. I start something at my desk, walk away, and pick it up on my phone, both ends in sync. My favorite part.
It is local-first and paid. Personal is $19.99/mo and runs entirely on your machine with no cloud account; there is a free 14-day pilot and no permanent free tier. Your agents already keep memory, but it is locked in each vendor's box and metered when you reach back into it; scritty's lives on your machine and is free to query, offline. One agent gives you a searchable memory of your own work; every agent you add shares the same corpus. It scales to teams as a shared enforcement layer and a federated, access-controlled, auditable knowledge base, with a per-org control plane for members, billing, seats, audit, license, SSO and SAML, which is a part I really care about coming from regulated environments (banking, healthcare, public sector). Sessions are private by default and you opt into what gets shared. And because capture is at the terminal and not inside any vendor, the agent vendor is swappable: Claude this quarter, Codex or Antigravity the next, nothing lost and no data migration, because the knowledge base is yours and agents rotate through it.
There's a 3:09 demo on the site. The whole point is I never start cold again: whoever I'm working with (agent or dev team) can pull up everything the last one already figured out. Happy to answer anything.
The immutable-transcript plus redact-at-share-boundary split makes sense, but the local index still holds plaintext secrets at rest — so any agent or MCP client with read access to the data dir (or a synced backup) can pull an old key straight out of search. Is there any at-rest encryption on the local store, or is the model explicitly 'your disk is the trust boundary'? And can the session-to-project scope widening be gated per MCP client, so one agent can't request the whole corpus?
scritty
@hi_i_am_mimo both are covered and they're two halves of same trust boundary.
at-rest: it's not "your disk is the trust boundary." there's opt-in at rest encryption on local store one switch, pointed at a passphrase you hold (env var or OS keychain, never written to config). whole local store is encrypted, both layers, not just transcript:
relational transcript + keyword index: page-level AES-256, each page authenticated with HMAC so tampering is detectable, key stretched from passphrase via PBKDF2.
vector index: XChaCha20-Poly1305 authenticated encryption, key derived via Argon2id. both from same passphrase. so old key buried in history isn't readable by another process, MCP client, or synced backup without it. it's fail closed so if passphrase absent, store refuses to open rather than silently falling back to plaintext.
scope gating: yes, per client. MCP access is by scoped token so you can hand an agent a token bound to specific session (or set), and a session scoped client can't widen to whole corpus; cross corpus read is refused for that token, not silently honored. "one agent asking for everything" isn't something it can do unless you mint it that scope.
tl;dr - trust boundary is passphrase + token scope, not filesystem. redaction is still separate, share boundary concern but encryption is what protects local copy.
@scritty_dev Shared memory for agents is such a practical problem. Are you seeing devs use this mainly for context persistence or also for knowledge discovery between different agent runs?
scritty
@clquek great question, it really depends on the dev and their workflow (or team workflow) single agent devs will lean more on the context persistence and RRF retrieval for lexcial/semantic recall whereas multi agent users/teams utilize this more for not just knowledge discovery/sharing but also an often overlooked key layer in continuity so that their different agent runs are seamless vs manual clunky transfer/hand-offs
The context loss between agents is real and nobody talks about it
enough. I've been using Claude Code heavily and the moment you hit
a usage limit mid-session the mental overhead of rebuilding context
somewhere else is brutal — you spend the first 10 messages just
catching the new agent up instead of actually solving the problem.
The MCP angle is the part that makes this different from just
"searchable logs." Agents querying each other's past turns rather
than starting cold is a genuinely different model. Curious how the
retrieval quality holds up on longer sessions — does it surface
the right past context or do you find yourself still needing to
manually point it at the right conversation?
Also the prompt.toml injection is underrated. Maintaining consistent
rules and persona across agent switches without copy-pasting is
something I'd use daily.
scritty
@l_build appreciate this! retrieval quality question is the real one cause searchable logs alone aren’t enough. under the hood it’s hybrid keyword + vector retrieval over captured exchanges, exposed back to agents over MCP, so the goal is to surface the few prior turns that actually matter instead of making you reconstruct the session by hand. it might seem counter-intuitive but I let the retrieved results shape the context in the prompt vs try to shove all (what I deem) relevant context in myself
The case I would test hard is stale or wrong memory, not just recall. If one agent records a bad debugging hypothesis and another agent asks about the same repo tomorrow, can I mark that capture as superseded or incorrect so it stops being retrieved?
For coding agents, I would want each memory hit to show source session, repo/branch, timestamp, and whether it was later contradicted. Local storage is a good default, but stale local facts can still send the next agent down the wrong path.
scritty
@tang_weigang agreed bad memory can be more dangerous than no memory. there are levers like provenance, relevance/confidence decay, and mark_noise to demote bad hits, but I wouldn’t claim there’s an explicit “superseded/contradicted” the idea is the substrate improves upon itself dynamically via these tools rather than hard deletes.
The part that sells me is that it sits as the terminal the agents already run in and captures passively — the 'bring the new session up to speed' dance is exactly the tax I want gone. Since captures stay local, does secret/token redaction happen at capture time, or does raw terminal output (API keys, env dumps) land in the searchable index as-is? And when an agent pulls context back over MCP, is retrieval scoped per-project/repo, or does it serve the whole corpus so unrelated work bleeds into the prompt?
scritty
@hi_i_am_mimo 1.) no capture-time redaction raw output lands as-is, but it's all local/no-telemetry, and I'd rather redact at share boundary (encrypted sidecar) than rewrite actual transcript as I treat it as immutable. that said I will happily roadmap this as a native feature vs relying on user. my methodology is a DRY wrapper around the same code for CLI and MCP so both you and your agent(s) can do it. 2.) auto-injected context is session-scoped by default, so unrelated work doesn't bleed in; widening to project/global is opt-in, and the hard "never mix" boundary is separate tenants/data dirs.
This tracks. The wall I hit doing hybrid retrieval over raw terminal exchanges is that tool output, the file dumps and stack traces, dominates the keyword side and matches great while carrying zero reasoning, and the actual 'why' lives in the model prose the vector side catches. Ended up down-weighting tool-output spans so the small budget didn't get eaten by noise that scored relevant. Do you tag span type at capture, or leave it to the ranker?
scritty
@dipankar_sarkar bingo. tool output matches great on keyword and carries zero 'why' cause reasoning lives in prose the vector side catches. down weighting after the fact works but you're making ranker rederive span type on every query (which is wasteful and query order dependent) so we tag at capture. content gets classified into normal/thinking/tool-call by structural parsers + noise pass that strips tui chrome and pure status/tool call rows before they ever hit index. so span type is a stored property, not a per query guess. the ranker then does query specific part signed EMA down rank on explicit noise marks and axis-aware decay, on top of corpus that's already typed.
split we landed on was capture decides what a span is (stable, structural); ranker decides what it's worth for this query (dynamic, feedback driven). trying to do first job in ranker is the budget eaten by noise problem you hit cause you can't cheaply re-classify at query time, so you end up hand weighting. tag once, up front, and small budget goes to reasoning instead of stack traces.
The cross-tool angle hides a mismatch I keep hitting: memory written by one model's sense of what mattered, read back by a different one. A summary of Claude's own debugging reasoning isn't always legible to Codex, which had a different plan for the same repo. You mentioned raw turns stay the source of truth, which is the right call, so the pressure moves to retrieval budget: what's the cap on turns pulled per query? Pull back 15 old sessions and you've rebuilt the exact context wall you're routing around.
scritty
@dipankar_sarkar correct. so retrieval budget is intentionally small not “replay 15 sessions.” goal is a few high-signal exchanges/chunks so you don’t recreate same context wall you were trying to escape. agreed on model mismatch point too: codex should read claude’s raw exchange text, not claude’s self-summary of what mattered. raw turns stay source of truth; summaries are a derived helper.
how does it actually capture the conversation from agents like Codex and Copilot, do you have to wrap the calls or does it hook into the terminal session itself?
scritty
@beyzaokhan works by being the terminal the agents run inside, not depending on vendor API(s). scritty detects active agent from process itself, captures exchanges in that terminal session, tags by provider, and indexes them locally. important to me because I wanted memory layer upstream of vendor lock-in and avoid dependency on things like spinners that are subject to UI updates making detection at 1 level down brittle at best