FlowLens

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.

On this page