K900.
AI Camera + Open-Ear Audio Smart Glasses

No. K900 has no AR display. It is an AI camera + open-ear audio platform. AR99 is a camera-free AR display platform. For a standalone Android edge client with camera and dual-eye display, see C100: Android apps run on the glasses. Direct dual-band Wi-Fi reaches a cloud/private AI endpoint through a compatible router or phone hotspot. Alternatively, BLE carries image/audio to a phone app for VLM/LLM/cloud services, with results returning through the app and BLE for glasses audio playback and display. BLE mode and phone-hotspot use depend on the phone; LLM/VLM inference runs off-device. Start with two separate requirements: what the wearer must capture and how the wearer must receive the result. Identify the capture source and describe any visible prompt and when it must appear. Then evaluate that complete task on the proposed configuration; a camera, audio or display category alone does not establish application suitability.

Specified partner configurations support livestreaming workflows that transmit real-time video and audio over the internet. This does not confirm a continuous-stream interface in the standard K900 SDK. Confirm the hardware, firmware, app, service and network scope for the selected project.

Local device capture, audio and connectivity support a companion or partner application. AI inference runs in the selected phone application or connected service. Any model running locally, SDK interface, OTA update or third-party integration must be confirmed for the selected hardware and firmware build.

ID/CMF, frame materials (acetate / TR90 / titanium), mechanical architecture, charging ecosystem and companion software are all customizable through OEM, ODM or JDM engagement. For each requested change, identify what remains as delivered, what needs engineering, the responsible team and the acceptance evidence. Keep camera, audio and display product types separate from sample evaluation, standard customization and deeper development routes. Confirm deliverables and commercial scope after reviewing the change list; a feature request alone does not determine the engagement or confer source-code rights.

Yes. K900 has been in mass production since late 2024. It is an earlier-generation model. Current shipments mainly fulfill customer-specific ODM orders. OEM, ODM and JDM customization scope, engineering milestones and delivery schedules are agreed per project.

Product-specific SDK, app download and local app development requests route through the RFQ form so we can provide software and compliance context for your region.

Use a result measured for the task you need to complete. Audio playback, video recording and continuous AI use are different workloads; their runtime figures are not interchangeable.

Write a use schedule covering active work, waiting, connections and charging opportunities. Request a test on the proposed configuration with the start and stop conditions recorded. Agree the required operating duration before testing. If the available result uses a different workload, keep it as a reference and leave your own duration requirement unverified.

Before comparing figures from different models, identify whether each figure covers one charge or includes charging-case top-ups. Keep the workload, connected phone or service, software build and fitted configuration explicit. A supplier's maximum-duration claim is a reference for that stated scope; it does not establish the operating time of another model or your intended task.

For the proposed sample, agree the active-use schedule, charging opportunities, environment, battery condition and start/stop criteria. Record the actual operating duration, interruptions and repeat-test conditions. Keep a requirement unverified when no result matches that configuration and workload.

For a useful sample evaluation, specify the task, the longest uninterrupted operating period, permitted charging breaks, the fitted lenses and accessories, and the required phone or service connection. These details help identify which reference figures are relevant and which requirements still need evidence for the proposed configuration.

Use this brief to keep the decision concrete: “Required task: [ ]; uninterrupted operating period: [ ]; permitted charging breaks: [ ]; fitted configuration: [ ]; HW/FW/SDK/App versions: [ ]; test method and owner: [ ]; pass/fail criteria: [ ].” Leave unverified fields open. Completing this brief is a scoping step, not confirmation of runtime, sample availability or delivery terms.

Ask for the exact hardware, firmware, SDK and app configuration, test method, conditions, acceptance criterion and observed result. A laboratory capability statement is not evidence that the selected configuration has passed. A component result does not establish the assembled product's performance.

Connect each result to the decision it supports. A sample demonstration can answer a functional question while leaving endurance, recovery and production questions open. Record each required gap, its owner and the next evidence needed; unrelated passing checks do not close a critical gap. Production acceptance and market-specific certification require their own agreed evidence and approvals.

A feature announcement or a production-hardware label does not establish that the complete workflow is ready for your project. For each required function, record whether it is demonstrated on the proposed build, described but not yet tested, announced for future release, or still unverified. Record the supporting evidence and date; do not turn an expected software update into a delivery commitment.

Confirm the target country, language, phone OS, account and service access, together with the hardware, firmware, SDK and app versions. Demonstrate the full task and the behavior when a required connection or service is unavailable. Agree the deliverable, acceptance criteria and responsible party before including the function in the project scope. SDK access, a finished application, source-code rights and third-party services require separate confirmation.

Describe the one task that must work in the target environment and the result the user needs to receive. For each essential function, identify the proposed build, access conditions, evidence date, acceptance method and fallback when a connection or service is unavailable. If a feature is only announced, keep it outside the current delivery commitment until its availability and the required workflow are verified.

Use this confirmation prompt: “For [task] in [country/language/account/phone environment], the proposed [HW/FW/SDK/App versions] must produce [result]. Evidence: [ ]; acceptance criteria: [ ]; unavailable-service fallback: [ ]; confirmed interface and licence scope: [ ]; unresolved items and responsible party: [ ].” This is a requirements record, not a quotation or a statement that an interface has been released.