Limitations
Honest current boundaries and the trade-offs behind them.
Current limits
- No Linux support.
- No always-on wake word.
- No autonomous computer control.
- No broad desktop-agent behavior.
- One clarifying follow-up turn per invocation.
- Primary-screen capture is used for reliability.
- Screenshot content is not automatically redacted before provider calls.
- Public production distribution still needs signing, notarization, and release credentials.
Why these limits exist
FlowLens is optimized for a polished, believable product slice rather than the widest possible feature matrix.
The project invests in:
- a reliable hotkey-to-answer loop
- a clean overlay
- live matrix visualization
- setup validation
- encrypted secret storage
- a stable structured response contract
- clear privacy boundaries
- packaged-app lifecycle
instead of spending that time on:
- full cross-platform support
- long conversation state
- deeper automation
- active-window capture heuristics
- IDE-specific integrations
- local-only multimodal inference
What this means for users today
FlowLens is best understood as a fast intervention tool. It is good at short, context-aware help inside an existing desktop workflow. It is not yet a persistent agent, a full automation framework, or a private local-only assistant.
What this means for maintainers
The current boundaries are useful. They keep the codebase testable and the product explainable. Future work should deepen the same loop before expanding into broader desktop automation.