Own-App visual AI terminal
Connect a visual input task to your own application and service.
Read the task brief →Submit your scenario ↗Global AI Eyewear Development Partner
Custom AI Eyewear Development
From Concept Design to Mass Production
Build an eyewear product around your users, your brand and your application. SmartXY connects product design, hardware, software and manufacturing in one development programme.
For brandsConsumer electronics companiesEnterprise customersOverseas channel partners
CHOOSE YOUR NEXT STEP
Start with the scope you need.
Standard SDK access, paid sample evaluation and platform branding each have their own request path. Only custom development opens the full development budget and engineering-resource questions. Package access, sample availability and commercial terms are confirmed for the selected configuration.
Standard SDK accessPaid sample evaluationPlatform branding / purchasingCustom development / integration
The Premium ODM NRE below applies to that highly customized programme. SDK changes, AI services, cloud use and ongoing support have separate scopes; standard SDK availability and licensing remain product-specific.
START WITH THE CUSTOMER TASK
Six ways to start with your customer task.
Use these task briefs to separate a standard-platform evaluation, software integration and a new architecture assessment. Requested capabilities require evidence for the selected configuration.
Camera-free lightweight HUD
Keep prompts in view; scope pure display and audio captions separately.
Read the task brief →Submit your scenario ↗First-person data capture system
Define a usable dataset and its acceptance process before choosing the capture architecture.
Read the task brief →Submit your scenario ↗Retail product for your brand
For regional brands and retail channels. Define the out-of-box App experience, language, service ownership, market approvals and after-sales responsibilities. An evaluation kit is not a finished retail offer.
Review the related scope →Submit your scenario ↗Industrial task and field operations
For enterprise teams and integrators. Scope inspection evidence, remote collaboration or site capture around the actual shift, network and safety rules. PPE fit and any new safety product require separate validation.
Review the related scope →Submit your scenario ↗Audio-only eyewear
For eyewear brands and voice-service teams. Start with calls, music or one voice task; assess the audio path, noise, fit and software service. Camera-free audio is a distinct choice from visual AI.
Review the related scope →Submit your scenario ↗These are customer requirements, not ready-to-order products. Existing model specifications and their delivery boundaries remain on the product pages.
DEFINE THE FIRST EVALUATION
Three task briefs for an engineering conversation.
Start with one task and record what is known, requested and still unverified. No evaluation result, interface access or commercial availability is implied.
Own-App visual AI terminal
- Who it is for
- Product teams and integrators with an existing App or a defined software partner, looking to add wearer-triggered visual input to a business task.
- First task
- Evaluate one event: request a photo or short clip, transfer it to the intended App or server, return an answer and record whether the user completed the task. Treat continuous streaming as a separate requirement.
- Required conditions
- Define the camera policy, the source and destination of images, prohibited data paths, App / server owner, supported host OS, network conditions, user consent and a versioned interface to test. Confirm commercial interface rights and ongoing software ownership separately from API access. Start with the minimum image data needed.
- Options to assess
- Photo or clip capture, optional audio or display feedback, phone-mediated or direct connectivity, and offline buffering. These are architecture choices for review, not a list of included features.
- Pending engineering validation
- Confirm SDK / firmware access on the actual build, capture and transfer reliability, background / locked-phone behavior, recovery after disconnection, end-to-end latency, thermal behavior and runtime under the requested workload. K900 is a camera-and-audio reference without an AR display; its partner live workflows do not establish a standard streaming SDK. C100 remains an EVT3 prototype and its camera-stream API release remains planned.
- Bring to the review
- A non-confidential task sketch, App / server diagram, event frequency or requested stream profile, required output, sample criteria and an integration owner. Ask for configuration and version evidence before choosing a sample.
Camera-free lightweight HUD
- Who it is for
- Teams needing glanceable instructions, prompts or captions where a glasses-mounted camera is unwanted or prohibited. Specify whether the policy also restricts microphones or other recording devices.
- First task
- For pure display, send one short prompt from the intended App and check readability and task completion. For audio captions, run a separate test from the permitted audio source through recognition and display.
- Required conditions
- Define camera restrictions, the display task, host / phone, text source, language, viewing environment and acceptance criteria. Audio captions also need a permitted audio path, recognition or translation service, network policy and a software owner.
- Options to assess
- Prompt-only or caption workflows, interaction controls, prescription fit, monocular or binocular requirements and accessory configuration. These are options for review, not configurations of one product. AR99 and AR99 MY are existing camera-free, phone-tethered display references; the selected App and service determine the workflow.
- Pending engineering validation
- Verify the actual display interface and permitted layout, text updates, target-language and right-to-left layout, latency, disconnection behavior, readability across eye positions, prescription lenses and lighting, comfort and runtime under the active workload. Camera-free does not imply offline captioning or an arbitrary graphics API.
- Bring to the review
- A sample prompt or script, pure-display versus caption choice, camera / microphone policy, language, host OS, work schedule, users and a clear pass criterion. Confirm accessory and software scope for the selected build.
First-person data capture system
- Who it is for
- Research, robotics and data teams that need first-person observations accepted by a downstream dataset or training pipeline. A consumer recording demonstration does not establish training-data suitability.
- First task
- Capture one representative session, export it to the intended pipeline and check usable records, metadata, timing, missing samples and the reviewer’s acceptance result. Define a failure as carefully as a successful capture.
- Required conditions
- Specify the downstream task, legal collection rights, capture modality, timebase, calibration needs, export schema, storage location, retention and data owner. Identify who accepts the dataset and how failures are counted.
- Options to assess
- Event or continuous capture, single or multiple sensors, a separate recorder, mounting or companion modules and local or network transfer. These require architecture review. Dual global-shutter cameras, hardware synchronization and any requested synchronization accuracy are unverified requirements, not existing platform capabilities.
- Pending engineering validation
- Measure actual inter-sensor timing error and drift, not just timestamp resolution or clock alignment; check dropped data, per-device calibration repeatability, recoverability, parseable exports and logs, downstream accepted-data rate, thermal limits and runtime at the specified resolution, rate and duty cycle. A requested shift duration or continuous-capture target is not verified endurance. XY-DC is a proposed reference architecture, not an orderable product SKU.
- Bring to the review
- A non-sensitive dataset schema, sensor and timing requirements, representative workload, annotation / acceptance plan, quantity by evaluation stage and engineering contact. Begin with a feasibility review before hardware selection.
01 / WHY SMARTXY
Why SmartXY
Shenzhen R&D brings the product and engineering disciplines together. Dongguan manufacturing connects that work to production preparation and delivery.
Industrial Design
Product identity, form, fit and brand expression.
Mechanical Design
Frame structure, hinge, assembly and serviceability.
Electrical Engineering
Electronics, power, sensors and connectivity.
Firmware
Device behavior, power management and updates.
SDK Integration
Versioned interfaces and application handover.
Mass Production
Manufacturing preparation, pilot builds and agreed quality gates.
Agree the product configuration, technical responsibilities, deliverables and acceptance criteria at each stage. Production starts after the required design, validation and commercial approvals.
02 / PLATFORM CHOICE
AI Eyewear Platform
Three platforms for different markets. Select the wearer experience first, then agree the hardware configuration and application integration.
A
Mass Market
AI Audio Camera Glasses
Camera and open-ear audio eyewear for consumer brands building everyday capture, listening and connected experiences.
- ≤45gReference configuration
- 8h AudioAudio playback
- Prescription Support
- Open-ear
- Camera Optional
- OTA
Confirm the reference configuration, fitted lens weight and audio test conditions for your project. Runtime varies with volume, calls, camera use and connectivity; 8h audio does not mean 8h video or continuous AI use. OTA scope is specific to the selected platform and firmware.
View the K900 reference product →B
Enterprise Applications
Enterprise AI Display Glasses
Bring useful information into the wearer’s field of view and connect it to an enterprise workflow.
- Translation
- Remote Assistance
- Training
- Industrial
Applications require the agreed software, host and network integration. Camera-free display models do not provide a wearer camera feed. Camera-and-display projects require a separately selected configuration and validation.
C
Fashion-first AI eyewear
Mimosa Female AI Eyewear
Eyewear for women and fashion-led brands, with the frame, fit and wearer experience at the center of the product.
- Luxury
- Lightweight
- Prescription
- Fashion
Coordinate frame design, materials, finish, prescription fitting and the chosen electronics. AR99-MY is a separate display product configuration; its optics, weight and battery figures do not transfer to Mimosa audio eyewear.
Explore the audio eyewear ODM scope →DEFINE A TASK TO EVALUATE
Two focused sample evaluations
Use one repeatable wearer task to agree the required result, configuration and evidence. These are evaluation briefs; reliability, application acceptance and delivery remain to be verified.
- 01
K900: recording and event review
Reference capability: still photos and local recorded video; no AR display. App control and interface access depend on the supplied build.
Evaluation scope: record a defined event, find the correct file and export it through the agreed app. Confirm formats, timestamps, transfer permissions, interruption recovery and the task's runtime. Event indexing, export integration and continuous streaming need separate interface evidence and scope.
Customer input: an authorized test scene, intended destination system, app/service owner and pass criteria.
K900：以可靠记录与事件回溯为验证任务。确认样机配置、文件定位与导出、时间信息、失败恢复及使用时长；这些任务结果均待实测，不代表标准 SDK 已开放连续视频流。
Review K900 capability and SDK boundaries → - 02
AR99: single-green text and prompts
Reference capability: camera-free, right-eye single-green information display with a paired phone and companion or partner app.
Evaluation scope: test a short caption or teleprompter task with the selected app. Confirm language, text layout, latency, readability, controls, connection recovery and runtime. Speech recognition, translation, content preparation and service costs belong to the agreed phone/app/service scope; arbitrary-canvas access requires interface evidence.
Customer input: a permitted script or speech sample, target language and phone, application owner and pass criteria.
AR99：以轻量单绿字幕或提词为验证任务。确认文字接口、目标语言、延迟、可读性、交互及断连恢复；语音识别、翻译和云服务责任需单列，待验证结果不写成量产承诺。
Review AR99 capability and SDK boundaries →
Record requirements and observed results separately. Do not put customer records, credentials or confidential commercial information into a public sample.
Download the blank task acceptance worksheet (English / 中文, TXT) ↓03 / ENGINEER FOR EVERYDAY USE
AI Eyewear Engineering Standard
Reliability Lab
Evaluate the mechanical, power and acoustic behavior of the selected design. Our reliability testing covers the following areas.
- 01
Hinge Test
Evaluate repeated opening, retention and mechanical wear against the agreed cycle and loading criteria.
- 02
Battery Test
Measure runtime, thermal behavior and power performance under the selected use profile.
- 03
Charging Test
Evaluate charging behavior with the selected battery, connector, case and power accessories.
- 04
Sweat Test
Evaluate sweat exposure and material resistance for the selected frame, coatings and interfaces.
- 05
Acoustic Test
Evaluate playback, voice pickup and sound leakage with the selected fit and acoustic setup.
The project test plan records the configuration, method, conditions, acceptance criteria and results. Test capability is not a claim that every product or configuration has passed the same test, and does not replace market-specific certification.
05 / CONNECT HARDWARE TO THE APPLICATION
SDK Platform
Four layers to define the software handover and integration responsibilities. Confirm the versioned package, interfaces and licensing per platform before development begins.
Hardware SDK
Device access and control
Pairing, capture, sensors, device events and update interfaces where supported by the selected hardware and firmware.
AI SDK
Application intelligence
Connect the chosen AI service and define audio, vision or display workflows. Confirm device, phone and cloud processing responsibilities.
Cloud SDK
Service connections
Scope authentication, cloud APIs, data transfer and service operation with the selected provider. Cloud usage and hosting are separately agreed.
Enterprise SDK
Deployment integration
Scope application integration, device-management requirements, access controls and fleet operations for the customer environment.
These layers describe integration scope, not a promise that every SKU exposes every interface. Source-code licensing, AI services, cloud hosting and long-term maintenance are agreed separately. C100 camera-stream APIs remain planned; its unchanged standard Android SDK/Demo policy remains separate.
Read the SDK evaluation checklist →START WITH THE PRODUCT YOU WANT TO BUILD
Your next AI eyewear programme starts with a clear brief.
Share the wearer task, target market, preferred platform, software team, pilot volume, timing and budget range. Define the required capture and output separately to check architecture fit. Name the proposed configuration, application owner, network environment and use schedule to clarify integration responsibility and operating conditions.
Separate what you need to observe on a sample from what you want changed for your product. For each requirement, agree the deliverable, test condition, pass criterion and responsible team. Record unknown results as open items; a successful demonstration closes only the question it tested.
Does a production platform mean my application is ready to ship?
Confirm three things for the configuration you intend to order:
- Hardware: the build, its development or production stage, and the evidence for that stage.
- Application: the wearer task, the software and host dependencies, and the agreed acceptance result. Include interface access when integration is required.
- Supply: the offered configuration, quantity, price and lead time, with a dated written confirmation.
Use the project brief to record your requirements and the evidence still needed. Assign an owner and a next step to each open item.
For context, Goertek's February 2023 announcement describes an AR2 reference design developed with Qualcomm. That historical design announcement does not establish acceptance of your application or availability for your current order.
AI eyewear project brief
Complete what you know and write “To confirm” where evidence is missing. Separate your requested outcome from a supplier-confirmed result. A desired delivery date is a requirement, not a confirmed lead time.
Describe input and output separately. Image capture and text prompts may both be required.
Fill in locally and print or save as PDF using your browser. Entries are not submitted or automatically saved; keep your own copy before closing.
This brief records requirements. It does not confirm stock, price, MOQ, NRE, certification, software rights or delivery timing. Supply terms require current written confirmation for the selected order; market-specific approvals require their own evidence.
Choose your next step: clarify the reference configuration, evaluate a sample, or scope a defined engineering change. Camera, audio and display describe product types; the change list determines which cooperation route to discuss.
Custom AI eyewear combines product definition, engineering and manufacturing. Compare an AI glasses ODM engagement with standard-platform OEM purchasing. Smart glasses manufacturer capabilities support the production stage; AR glasses development also needs optical and application validation. For an AI wearable ODM China project, define the target market, integration owner and acceptance plan from the start.
Related reading: Vanda’s personal OEM, ODM and JDM guide explores project scope and software handover. Discuss your configuration and purchasing requirements with SmartXY.