The machine that built the machine
LensLaber was developed entirely on a laptop from 2015. Not as a stunt, not as a talking point — it was simply the hardware available. There was no budget for a workstation, no cloud VM to offload inference to, no high-end GPU to paper over inefficiency.
The natural reaction would have been to work around those limits. The choice made here was the opposite: to treat them as the specification.
If automated detection and segmentation had to run locally on an i5-4200U with 8 GB of RAM, then the software had to be lean enough to actually make that work — not in a demo, but in a real annotation session, on a real 20,000-image dataset.
Development Machine — 2015
CPU
Intel® Core™ i5-4200U
1.60 GHz base · 2.30 GHz boost
RAM
8.00 GB
7.89 GB usable
GPU
NVIDIA GeForce 820M
980 MB · Intel HD Graphics (shared)
Storage
112 GB SSD
SanDisk
Runtime on this hardware
Your data never leaves your machine
Cloud annotation platforms make a quiet assumption: that your images are disposable, or at least shareable. Send them up, process them, get results back. Convenient — until you're working with proprietary industrial data, medical imagery, or anything that carries legal or competitive weight.
LensLaber is 100% offline by design. Not as a checkbox feature. The inference engine, the SAM integration, the augmentation pipeline — everything runs locally. No telemetry. No upload step hidden behind a loading bar.
This is not about being anti-cloud. It is about recognizing that for annotation work, the cloud is often a liability dressed as convenience.
"Absolute data privacy is not a selling point. It is a baseline that should never have required justification."
AI tools that don't demand a GPU
There is a certain irony in the annotation space: the tools most likely to require GPU acceleration are the ones you use to generate the data that trains the models that will eventually need GPUs. Somewhere in that loop, the cart got in front of the horse.
YOLO and SAM integration in LensLaber runs through ONNX Runtime — no PyTorch, no Ultralytics, no framework that drags in six gigabytes of dependencies. The inference that happens is real inference, not a stripped-down preview mode. It runs on the CPU, comfortably, on hardware from a decade ago.
That is a deliberate engineering position, not a limitation waiting to be lifted.
ONNX Runtime
No heavy framework dependencies. Just the model and the runtime, directly.
MobileSAM
Segmentation refined for CPU-first systems. Real masks, not approximations.
Bring your own YOLO
Load any YOLO ONNX weights. The engine is model-agnostic by design.
Semi-automation, full control
The annotation tools that over-automate tend to produce the same failure mode: the human stops paying attention, and the errors compound quietly. A model that is 95% accurate sounds impressive until you realize that across 10,000 images, that is 500 silent mistakes in your training data.
LensLaber treats automation as acceleration, not replacement. YOLO proposes. SAM refines. The false negative review flags what the model missed. But at every step, the annotator remains in the loop — not as an afterthought, but as the point.
Fast Mode, configurable shortcuts, context-aware tools — these exist to reduce the friction of human work, not to route around it.
The i3 test
At some point during development, LensLaber was tested on an Intel i3 with 4 GB of RAM. It worked. Not in a limited-feature mode, not with caveats — it worked. That became an unofficial benchmark: if something breaks the i3, it is a bug, not a hardware problem.
This matters because the global distribution of hardware is not centered on the latest MacBook Pro. Researchers in constrained environments, students, independent practitioners — a large portion of the people who would benefit most from capable annotation tooling are exactly the ones that existing tools ignore.
That gap is intentional to fill.
"The i3 test is not about supporting old hardware. It is about refusing to be lazy."
What beta actually means here
LensLaber is in public beta. That word gets overloaded, so it is worth being specific: the core workflows are stable and production-capable. The beta designation reflects honest uncertainty about edge cases, hardware combinations, and the roadmap, not about whether the software does what it says.
The 30-day trial window, the export limits — these are temporary calibration tools, not revenue mechanisms. They exist to get real feedback from real annotation workloads, so that future decisions are grounded in evidence rather than assumption.
If you use it and find something broken, that is useful. If you use it and find it works well, that is equally useful. Either way, the feedback shapes the next version directly.
Public Beta · Free to try
Run it on what you have.
Windows and Linux. No account. No cloud. Works on hardware from a decade ago.
VirusTotal clean · SHA-256 verified · 0 telemetry