Built a Chrome extension to stop re-explaining project context to AI every 20 prompts (Need brutal feedback)

Nice framing. I’d make the handoff an explicit artifact with a small schema: decisions (with source and timestamp), constraints, open questions, and next actions. For multi-model work, I’d ask the next model to acknowledge which items it used and flag conflicts rather than silently merging them. I’d also keep extraction local and make permissions, export, and delete obvious; even chrome.storage.local deserves a clear threat model. A diff/restore view would make automated summaries much safer to trust than a single “current state.”

This is a persistent bottleneck. Injecting context manually breaks the engineering workflow entirely.

From an architecture standpoint, how are you handling the token limits when the project context grows over time? At Scorvia Studio, when we build custom internal AI tools, we rely on local vector stores so the context is retrieved dynamically based on the prompt, rather than forcing a massive static context block every single time.

Also, for B2B use cases, passing proprietary project data through a browser extension to external APIs can be a major compliance issue. Have you considered allowing users to point the extension to local LLMs running on their own hardware to protect sensitive codebases?

Brutal version, from someone who lives in long AI sessions.

Losing context is the failure you designed for, and it is the visible one. The worse one is carrying forward context that has stopped being true. Your three buckets will faithfully preserve a decision that was reversed forty prompts later, and the fresh session will treat it as settled.

We had this week. I wrote a confident conclusion into our project notes, that a particular account did not exist. It did. Had the correction not happened in the same session, the next one would have inherited the wrong version, arriving looking exactly like established fact.

So you need a fourth state: superseded. A decision that was made then overturned, kept visible alongside what replaced it. That is the thing a fresh model cannot reconstruct and the thing a summary most wants to smooth away.

Second, show what you dropped, not just what you kept. When one of our sessions compacted, a specific value fell out of the summary and nobody knew until it was asked for later. Silent omission is harder to catch than a wrong entry.

One addition I'd test is provenance on each extracted item: quoted directly, inferred, or unresolved, plus a timestamp. That keeps an old assumption from looking like an active constraint during a handoff. For evaluation, compare the generated state with what the user later corrects and track omissions separately from false positives; a compact state that is trustworthy beats a complete-looking one that quietly invents certainty.

This solves a huge pain point. The 'context tax' when switching between models/sessions is super real.

A 1-click Markdown copy sounds great for cross-tool handoffs (e.g., jumping from Web UI to CLI). One quick feedback on Extraction Accuracy: sometimes key architectural decisions are implicit in the code snippets rather than explicitly stated in chat. Does it capture code context well, or strictly prose?

Definitely going to test the Chrome extension!

I definitely recognize the “context tax.” For longer projects, I also need AI to remember constraints and things we’ve already tried and rejected, not just decisions and next steps. Have you considered adding an “Already Tried” section?

The pain sounds real for power users. Do testers actually use the generated project state repeatedly across sessions, or is manually pasting context still easier when the stakes are high?