rayl15/OpenVision

Problem Starting a fresh conversation topic mid-session currently means clearing context via the + button in the History tab — i.e. reaching for the phone. For a hands-free wearable, you should be able to say "let's change subject" without touching anything. Requested on the Product Hunt launch by @soneruludo (Soner Uludoğan): Would love a hands-free way to start a new conversation topic mid-session, like a short double-tap gesture on the glasses to clear context without needing to open the app on my phone. Proposed solution Two complementary triggers: Voice trigger (do first — self-contained, no SDK dependency) A phrase like "Ok Vision, new topic" / "start over" / "new conversation" that clears the current context. Should call ConversationManager.shared.startNewConversation() + ConversationContext.shared.clear() (same as the History "+" button), then optionally confirm ("Starting fresh"). Handle it in the command router (LocalAgent intent) or as a reserved command in VoiceCo

Part of the power-management roadmap in #36. Goal Reduce wasted work during Live video mode by adapting to scene content. Scope Skip near-duplicate frames (cheap frame-difference check before sending to the model) Lower frame rate when the scene is static; raise it when motion/detail warrants Configurable frame rate / resolution ceilings Prefer a single high-res still over sustained high-quality video where the task allows Pointers OpenVision/Managers/GlassesManager.swift — frame publishing OpenVision/Views/VoiceAgent/VoiceAgentView.swift — freshestGlassesFrame / live-video send loop Higher effort than #36's cleanup slice — good for someone comfortable with the streaming path.

Part of the power-management roadmap in #36. Goal Make OpenVision battery- and thermal-aware: automatically prefer lower-power behavior as battery drops or the device heats up. Why There is currently no reading of battery level or thermal state anywhere in the app. This is the highest-impact new capability from the proposal for real all-day wear. Scope (first pass) Read UIDevice.current.batteryLevel / .batteryState and ProcessInfo.processInfo.thermalState At low battery / high thermal: prefer a single snapshot over live video, shorten inactivity timeouts, avoid continuous streaming without confirmation A "Reserve mode" (voice-first, camera only on explicit request) below a configurable battery threshold Thresholds configurable in Settings, not hard-coded Out of scope for this issue: the full set of named power profiles (All-Day/Balanced/Performance) — those can follow once the sensing + auto-downgrade primitives exist. Pointers OpenVision/Models/AppSettings.swift — add thres

Part of the power-management roadmap in #36 (Stage 1). Goal Guarantee that every request-completion path releases all held resources: camera stream, microphone, speech recognition, network sockets/WebSockets, timers, frame buffers, and model-inference tasks. Why OpenVision already does snapshot-first "click-and-go" (camera stops right after capture) and has performFullStop(), conversation-inactivity timeouts, and background/GPU guards. But cleanup isn't verified as a single sweep across all exit paths, so a leak on one path (e.g. an error mid-stream) could leave the camera or a socket alive and drain battery. Paths that must all release resources Successful completion User cancellation / barge-in Inactivity timeout Error mid-request App backgrounding Glasses disconnection Repeated network failure Pointers OpenVision/Views/VoiceAgent/VoiceAgentView.swift — performFullStop(), stopLiveVideoMode(), capture flow (~line 620) OpenVision/Managers/GlassesManager.swift — startStrea

Problem Proposal: Battery-Aware Sensor Management and Power Modes Problem OpenVision’s live voice and vision capabilities make it possible to use Ray-Ban Meta glasses as a general-purpose AI assistant. However, frequent camera use, continuous video streaming, active microphone sessions, persistent network connections, and local model inference can increase battery consumption on both the glasses and the connected iPhone. For users who want to wear the glasses throughout the day, continuous sensing is not always necessary. Many requests can be handled through voice, conversation context, tools, or a single photograph without maintaining an active camera stream. The objective is to make OpenVision continuously available while avoiding unnecessary sensor, network, and compute activity. Proposed Solution Introduce battery-aware sensor management based on the following principle: «OpenVision should use the lowest-power combination of sensing, computation, and networking capable of comple