In April 2026, AskUI published a comparison piece framing the choice in visual automation as if it were already decided. Deterministic, image-based automation tools are presented as a legacy paradigm — useful for nostalgia, limited by screen resolution, blocked on headless execution, helpless on mobile, doomed to be replaced by LLM-piloted agents that “understand” the interface rather than match pixels against it.
I read AskUI’s article carefully. It is well-written, and the SEO will travel. It is also, on most of its load-bearing claims about OculiX, factually wrong — by several major and minor releases.
The intent of this post is not to attack a competitor. The intent is to factualize, calmly and in writing, what OculiX 3.0.4 actually does in 2026, so that a buyer reading both pieces side by side can make a decision on observable facts rather than on the carefully cropped excerpt AskUI chose to publish.
Before going into claim-by-claim correction, let me name the two paradigms fairly, because they are not the same shape and they do not serve the same constraint.
Deterministic visual automation
A script written in code. A pattern stored as an image. A matcher that decides, by pixel comparison, whether the pattern is on screen. Same input, same output, every time. No model, no token, no cloud round-trip in the hot path. Auditable end to end.
LLM-piloted agentic automation
A natural-language instruction. A multimodal model that interprets the screen and decides what to click. Same input, plausibly similar output, never bit-for-bit reproducible. Behavior changes when the model version changes. Token-billed by the round trip. Auditability is a research topic.
These two paradigms are not interchangeable in any professional QA practice. The deterministic paradigm produces reproducible artifacts on demand: production regression, compliance-grade audit trails, air-gapped perimeters, every test that must produce the same artifact today, tomorrow, and in three years on a different machine. The agentic paradigm, by construction, cannot — and a QA team optimizing for trust, audit and reproducibility cannot rationally adopt it as its primary engine. This is the position I have publicly defended on LLM non-determinism applied to automation: selling a non-reproducible autonomous execution as a test product is a professional fault, not an acceptable trade-off.
AskUI’s piece nonetheless claims that the agentic paradigm is the inevitable successor to the deterministic one, and bolsters that framing with claims about the deterministic side that are either out of date by two minor releases, true of one tool but extended to another by amalgam, or simply incorrect. It is the combination of the two — a wrong strategic framing and a wrong technical assessment — that makes the present response necessary.
Let me go through each claim.
AskUI describes OculiX as “a development build called OculiX 3.0.1 […] also available with VNC support, Android ADB control, PaddleOCR integration, and additional scripting languages”.
What is actually shipping in June 2026:
| Item | Reality |
|---|---|
| Current stable | OculiX 3.0.4, released and downloaded by close to a hundred organizations in production |
| Next major | OculiX 4.0, scoped, in active development, targeted for mid-2026 |
| Deployments | Fortune 500, APAC enterprises, defense sector — observable through Scarf usage telemetry |
| OCR engine | Tesseract embedded statically via Legerix, self-contained, no PaddleOCR dependency in stable |
Calling OculiX a “development build” in AskUI’s comparison written for a 2026 audience is not a small inaccuracy. It tells the reader that the alternative they are evaluating is unstable, when the opposite is true. The choice of version number “3.0.1” in AskUI’s piece appears to refer to a release from a previous quarter; their comparison was published months later, after several stable releases had shipped.
AskUI asserts that headless execution is “not supported” and that “a real, unlocked screen is required”.
This is true of SikuliX run locally, on the laptop in front of a developer. It is not true of OculiX in the configuration most production teams actually deploy.
OculiX ships a remote VNC architecture, documented and supported, where:
This is the production deployment used by the majority of OculiX deployments at scale. It is not headless in the strict sense of “no framebuffer ever rendered” — that would be physically incompatible with pixel matching as a paradigm. It is headless in the sense the buyer actually cares about: the test does not block the operator’s screen, the test runs unattended in CI, the test does not require a human to be logged in physically in front of the test machine.
AskUI extends a true limitation of SikuliX local-mode execution to all image-based automation, which is misleading. OculiX moved past this limit several years before their comparison was written.
This is the same architectural confusion as claim 2. In a local OculiX session — same as in a local AutoIt, AutoHotKey, or pyautogui session — the mouse and keyboard belong to the running script. This is intrinsic to driving a desktop UI, regardless of vendor.
In a VNC session OculiX deployment, the test runs in a separate framebuffer on a separate VM. The developer’s mouse and keyboard are not contested. This is exactly what production teams running visual regression at scale ask for, and it is exactly what OculiX provides. AskUI frames this as a categorical limit of image-based automation; in practice, the limit was lifted years ago by the architecture of how the tool is deployed.
OculiX 3.0.4 ships a persistent locator cache mechanism, embedded inside the PNG files used as patterns. Each pattern’s last successful match coordinates are stored as a private ancillary PNG chunk (oPLx), preserved by every standard image tool, survived by git clone, and read by OculiX on the next cold-start invocation.
The measured impact on a five-year-old i3 laptop, in a strict cold-start configuration mimicking a CI environment, is a ×6.5 speedup on the find operation: from a 502 ms baseline down to 77 ms median. On modern hardware the absolute numbers shrink but the relative speedup stays at ×6 to ×8.
This is documented in detail in my benchmark post from May 2026, with the methodology, the harness, and the raw numbers.
AskUI’s claim that OculiX has “no execution caching capability” was published after the feature shipped and after the benchmark was public. It either reflects a research process that did not look at the changelog, or a deliberate omission of an inconvenient counter-example.
OculiX 3.0.4 ships first-class Android support, exposed through ADB, with device selection by serial, idempotent wake/unlock via KEYCODE_WAKEUP, and parallel multi-device farms. This has been the case for several minor releases.
The interface is documented, the code is in the public repository, and the test cases that exercise it are in the test suite. A simple git log --grep android on the public repository surfaces the recent commits introducing the per-serial device selector and the wake decoupling.
AskUI’s 2026 comparison claims OculiX has “no mobile support” — this is either months out of date or deliberately reads a single old branch. Either way, it is wrong about the stable release a buyer would actually download today.
This claim is technically true of the naive form of template matching — the form practiced by image-based tools in 2010. It is not true of OculiX’s Finder.java implementation in 2026, which cascades five matching modes:
| Mode | Strategy | Tolerance |
|---|---|---|
| 1 | Standard template match | None — fast path for exact match |
| 2 | DPI-aware rescale | Resolution and scaling differences between capture and target |
| 3 | Gaussian-blurred match | Antialiasing, subtle color variation |
| 4 | Grayscale-converted match | Color theme drift |
| 5 | Multi-scale brute force | 0.5× to 2× scaling, last resort |
A pattern captured on a 1920×1080 screen at 100% scaling and matched on a 2560×1440 screen at 125% scaling is the exact case mode 2 was designed to handle. The matcher does not “break”; it changes strategy and finds the pattern. This has been in the codebase for years.
Presenting the 2010 limitation as if it still defined the 2026 state of the tool is a common debate trick: pick the worst version of the position you are arguing against, and treat it as if it were the only one. AskUI’s article uses this exact move.
This is not stated literally by AskUI, but it pervades the structure of their piece: the deterministic column is presented as a list of limitations, the agentic column as a list of capabilities.
The honest framing is the inverse, depending on the buyer’s constraint:
What deterministic gives you
Bit-for-bit reproducibility. Same script, same input, same output, today and in three years. Zero per-execution cost. Air-gap operation, no cloud dependency in the hot path. Auditable failure: when a test fails, the trace tells you exactly why. Survives the model version churn that disrupts LLM-piloted suites every quarter.
What agentic gives you
Faster initial authoring, at the cost of artifacts that are not reproducible. Tolerance to UI drift, at the cost of silent passes when the model misinterprets the screen. Natural-language interfaces, at the cost of nobody being able to debug the test when it fails. Per-execution billing, indefinitely. None of this is a fair trade for professional QA.
A QA team protecting a payment terminal under fiscal audit needs the left column. A growth team smoke-testing a marketing landing page can probably afford the right column. Pretending either category is the universal answer is selling the buyer a paradigm rather than helping them solve a problem.
Beyond the technical claims, the two paradigms differ in their economic shape, and the difference matters more than the comparison acknowledges.
| Dimension | OculiX 3.0.4 | LLM-piloted alternative |
|---|---|---|
| Commercial-use terms | MIT, unlimited, code public | Non-commercial on free tier, paid plans required for production |
| Pricing transparency | Free, no plan to upgrade | Plans not publicly disclosed, contact-sales gating |
| Hot-path cost per test | Zero — local CPU | Token-billed inference per round trip |
| Cloud dependency | None in default deployment | Cloud agent OS, hosted inference hub |
| Air-gap suitability | Native | Requires self-hosted enterprise plan, custom contract |
| Self-hosted at scale | Default mode | Enterprise tier only |
| Auditability of runs | Per-byte deterministic | Subject to model and prompt drift |
For a buyer running a hundred thousand test executions per day, the per-token inference cost of the agentic model is not a rounding error. It is a recurring operational expense that grows with usage. The deterministic alternative has zero such expense: the script runs on the runner that the buyer was going to provision anyway, and the matcher uses the CPU cycles that would otherwise be idle.
For a buyer in a regulated industry — banking, defense, healthcare, manufacturing under traceable quality control — the air-gap and audit requirements are not negotiable. A tool that requires a cloud inference hub does not even reach the evaluation phase. A tool that runs entirely on-premise under MIT open-source terms clears that gate by construction.
AskUI’s comparison glosses over both of these, framing pricing as “starts free” and air-gap as “available in enterprise”. A buyer who reads only the marketing surface might conclude the difference is small. A buyer who looks at the contracts and the deployment architecture will conclude otherwise.
The agentic paradigm is routinely defended on four use cases. I do not consider any of them a valid justification for professional QA — I list them so we can see why.
In none of these four cases do cloud inference billing, dependence on a model version that will change, or loss of reproducibility become acceptable for a test base meant to last years. AskUI is a real and well-executed product within its space; the space itself is simply not that of professional QA, regardless of vendor.
The point that follows is not about AskUI specifically. It applies to any editor — whatever the brand, whatever the marketing copy — who proposes a token-billed inference model on a cloud-only platform for an activity whose nature is high-volume, repeated, and budget-constrained. QA is precisely that activity.
Let me lay out the structural mismatch.
QA is, by its very purpose, an exercise in volume:
Multiply by the number of teams, by the number of products, by the number of environments, by the number of replays needed for flaky-test analysis. A serious QA practice in a mid-to-large organization performs hundreds of thousands of test executions per day. That is not pathological scale. That is the normal floor.
Now overlay a per-inference pricing model on this volume.
| Concrete scenario | Inferences per day | Cost trajectory at typical inference pricing |
|---|---|---|
| Small team, daily smoke | ~5 000 | Manageable in year 1, scales linearly |
| Mid-size product, PR + nightly + canary | ~50 000 | Becomes a visible budget line |
| Enterprise QA practice across multiple products | ~500 000 | Becomes a board-level conversation |
| Compliance-grade replay for audit reconstitution | ~1 000 000 | Becomes a deal-breaker |
The QA leader who chooses a per-inference pricing tool inherits a structural problem with two opposing pressures:
To control cost
The team is pushed to test less — skip the canary, drop the nightly, narrow the regression scope. Cost is contained at the expense of coverage.
To keep quality
The team is pushed to spend more — keep coverage intact, accept the linear bill, escalate to procurement when the line crosses the threshold. Quality is contained at the expense of budget.
The two pressures converge on a budget ceiling that arrives faster than the maturation of the practice.
No per-execution fee
A regression suite that runs ten times today and a hundred times tomorrow consumes ten and a hundred times the runner minutes the organization was already paying for. The vendor is not involved in the marginal cost.
Marginal cost ≈ CPU seconds
Each additional test execution costs the price of an additional second of CPU time on a runner that was already provisioned. The QA practice can mature without renegotiating any contract.
This is the structural reason most regulated industries — banking, defense, healthcare, manufacturing under traceable quality control — have never adopted a per-token cloud automation primary engine, and will not. It is not a question of trust or maturity. It is a question of arithmetic.
Abstract arguments about pricing models are easier to dismiss than concrete numbers. Let me put real volumes on the table.
Before the numbers, what the editor service actually covers. The OculiX engine is free; the editor service is an optional flat-fee engagement layered on top for buyers who want a private channel, response-time commitments, named contacts, or vendor-of-record status. Three packages, three flat prices that do not scale with the buyer’s QA volume:
| Tier | What it covers | Typical fit |
|---|---|---|
| Small Team support (~12 – 15 k€/year) | Private email channel, response < 5 business days, bug prioritization, roadmap access | Single team running OculiX in production, wanting a private channel without overhead |
| Premium editor service (~35 – 70 k€/year) | Everything in Small Team + hotline on agreed slots, response < 1 business day, quarterly review, direct roadmap influence | Mid-size product team where automation is on the critical path, multiple stakeholders |
| Enterprise editor service (~90 – 180 k€/year, volume discount above 150 k€) | Everything in Premium + named engineer, response < 4 business hours, contractual SLA, on-call windows for critical releases, vendor-of-record status (audit-defensible) | Enterprise QA practice with regulatory exposure, multi-product or multi-entity scope |
What each level explicitly excludes: custom feature development (separate engagement, billed per feature), endless time-and-materials work (the engagement is flat-priced — the editor carries the delivery risk, not the buyer), and 24/7 coverage outside named critical windows. The buyer always knows what they pay for; the editor always knows what is committed.
The structural point: at any tier, the price is flat for the year regardless of how many tests the buyer runs. A team that doubles its test volume next year pays the same. A team that quadruples it pays the same. The line item is predictable for budget review, which is exactly what the inference-billed alternatives cannot offer.
With that understood, the three buyer scenarios.
| Tool / model | Year 1 cost | 3-year cumulative | Cost behavior |
|---|---|---|---|
| mabl (Team plan + extra exec minutes) | ~12 000 – 15 000 € | ~36 000 – 45 000 € | Linear with execution minutes |
| testRigor (Pro tier, ~5 000 steps/month) | ~6 000 – 10 000 € | ~18 000 – 30 000 € | Linear with test steps |
| Applitools Eyes / Autonomous (Growth) | ~6 000 – 25 000 € | ~18 000 – 75 000 € | Linear with Test Units |
| AskUI (subscription + token Hub) | Not publicly disclosed — contact sales | Same shape — linear with volume | Linear with inference calls |
| OculiX OSS | 0 € | 0 € | Constant |
| OculiX OSS + Small Team editor support (optional) | ~12 000 – 15 000 € | ~36 000 – 45 000 € | Constant — flat editor engagement |
At this scale, the cheapest line is OculiX OSS at zero euros, full stop. For buyers who want a private channel, response-time commitments, bug prioritization, and roadmap access, the OculiX Small Team editor support package sits in the same price band as the cheapest competing offers — and stays flat as the buyer’s QA volume grows, instead of scaling with executions. The OSS engine alone is enough for many teams; the editor support is a bonus, not an obligation.
| Tool / model | Year 1 cost | 3-year cumulative | Cost behavior |
|---|---|---|---|
| mabl (Enterprise, custom) | ~40 000 – 80 000 € | ~120 000 – 240 000 € | Custom-quoted, linear with usage |
| testRigor (Enterprise, near-unlimited steps) | ~60 000 – 100 000 € | ~180 000 – 300 000 € | Custom-quoted enterprise |
| Applitools Enterprise | ~50 000 – 100 000 € | ~150 000 – 300 000 € | Custom-quoted enterprise |
| AskUI (subscription + heavy inference) | Not publicly disclosed — contact sales | Same shape — linear with volume | Linear with inference calls |
| OculiX OSS | 0 € | 0 € | Constant |
| OculiX OSS + Premium editor service (optional) | ~35 000 – 70 000 € | ~105 000 – 210 000 € | Constant — flat editor engagement |
At 1 000 executions per day, the competing tools start to look like operational expenses with their own line in the budget review. OculiX OSS still costs zero. The OculiX Premium editor service starts at 35 000 € per year — below the entry point of every competing enterprise tier in this band — with hotline, response within one business day, quarterly review, and direct roadmap influence. The price stays flat whatever the QA volume grows to. Doubling the suite next year keeps the OculiX line at the same number; the competing alternatives scale linearly with usage.
On a three-year horizon, the gap is no longer marginal. OculiX Premium accumulates to ~105 000 – 210 000 € over three years. Mabl Enterprise accumulates to ~120 000 – 240 000 €. testRigor and Applitools accumulate to ~150 000 – 300 000 €. AskUI does not publish prices, so I won’t fabricate a cumulative — what is observable from their model is that it scales linearly with inference volume, which at 250 000 executions per year compounds the gap mechanically. Even at the upper bound of the OculiX Premium range, the total stays below the entry of testRigor and Applitools and at the bottom of mabl Enterprise. At five years and at ten years, the gap widens further — because the OculiX line is flat and the competing lines are not.
| Tool / model | Year 1 cost | 3-year cumulative | Cost behavior |
|---|---|---|---|
| mabl / testRigor / Applitools (Enterprise+, custom) | ~200 000 – 500 000 € | ~600 000 – 1 500 000 € | Custom-quoted, linear with usage |
| AskUI (full inference Hub at 2.5 M executions) | Not publicly disclosed — contact sales | Same shape — linear with volume | Linear with inference calls |
| OculiX OSS | 0 € | 0 € | Constant |
| OculiX OSS + Enterprise editor service + volume discount (optional) | ~180 000 – 250 000 € | ~540 000 – 750 000 € | Constant with volume discount |
At 10 000 executions per day, the gap is no longer a comparison — it is a categorical statement about which paradigm scales economically. OculiX OSS costs zero. OculiX with full editor service plus volume discount is still well under what a buyer would pay for the inference-based alternative even before counting the cloud lock-in.
There is a temptation, reading the tables above, to view the OculiX Premium or Enterprise editor service as just another vendor lock-in line item. It is not, and the structural difference matters.
The OSS engine runs without it
OculiX is MIT, the binaries are public, the documentation is on the site, the community channel is open. A team can adopt OculiX, run it in production for ten years, and never pay the editor a euro. This is not theoretical — many of the close-to-a-hundred deployed organizations do exactly that.
The editor service is a flat engagement
When a team chooses to engage the editor, they pay a flat annual price for SLA, named engineer, vendor-of-record status, roadmap influence, and migration support. The price does not scale with the number of tests they run. They can quadruple their QA volume next year without renegotiating.
The exit is real
At the end of an engagement, the team keeps their entire codebase, their patterns, their CI pipelines, their automations. There is no proprietary format to extract from, no cloud hub to migrate off, no token bill that survives the contract. The OSS engine runs the same the day after the contract ends as the day before.
The model is Red Hat, not SaaS
Red Hat does not charge per CPU cycle on Linux. Confluent does not charge per Kafka message. Sonatype does not charge per Nexus artifact resolved. OculiX does not charge per test execution. The editor sells engagement and support around a free engine — the proven OSS-plus-services model.
A buyer who reads only the per-tool price table might frame the choice as “free vs paid”. That framing misses the point. The choice is: pay per usage forever, or pay nothing and engage the editor only if and when the buyer values doing so. The decision is reversible. The cost ceiling is knowable. The exit is a git pull away.
The honest framing for a buyer evaluating visual automation in 2026 looks like this:
These four questions are observable. The buyer can answer them without depending on a vendor’s marketing narrative. They do not require choosing between “legacy” and “future”; they require recognizing that QA is engineering, and that engineering does not negotiate reproducibility.
OculiX 3.0.4 is, in 2026, the most complete deterministic visual automation runtime available under MIT open-source terms. It runs on Windows, macOS including Apple Silicon, and Linux. It supports Android. It runs in VNC sessions for remote and parallel execution. It persists its locator cache in a portable form that survives git clone and CI runners. It is used in production by close to a hundred organizations across regulated industries. The code is on GitHub. The open-source terms are irrevocable. The next release is scoped and public.
If the buyer’s constraint is reproducibility, audit, air-gap, or zero per-execution cost, OculiX is the answer. If the buyer’s constraint is assisted exploration with systematic human validation, what they are looking for is an assistant — not a test engine. Confusing the two with QA automation is a linguistic abuse the market will eventually correct. Either way, the choice should be made on facts about the current state of each option — not on a 2024 snapshot of one tool extended into a 2026 article about another.
I publish the data I can verify. I link to AskUI’s article that prompted this one so that any reader can check both sides for themselves. The repository is open. The benchmark methodology is public. The architecture is documented. There is no hidden layer to negotiate access to.
That is the difference open-source MIT terms actually make.
Honest comparison
Rankings that conclude OculiX is the wrong tool for a given use case, supported by accurate technical claims. Buyer guidance toward a competitor when the competitor genuinely fits better. The market matures when comparisons are factual — and OculiX has nothing to fear from an honest one.
Systematic misrepresentation
Version numbers misrepresented by multiple stable releases. Shipped features described as absent. Limitations of an unrelated tool attributed to OculiX. Deployment architectures ignored despite being publicly documented. This is a different category and is treated as such.
Legal remedies preserved
The maintainers preserve every legal remedy available in our jurisdictions: misrepresentation, misleading comparative advertising, defamation when the threshold is reached, and the moral rights attached to the authorship of the code.
Dialogue is the first move
These remedies are not exercised as a first response. The preferred path is dialogue, correction, and right-of-reply — this post is itself the public correction offered amicably. Escalation happens only when the pattern persists and the offered correction is ignored.
Universal, not targeted
This is not a warning addressed to any specific competitor. It is a position that applies to anyone, today or in the future, who chooses to compete with OculiX through fabrication rather than through honest technical and economic argument.
MIT protects the user, not the misrepresentation
The MIT terms grant unrestricted rights to use, modify and redistribute the code. They do not strip the maintainers of legal personhood, reputational interests, or the protections French and European law extends to honest economic actors.
Repository: github.com/oculix-org/Oculix
Benchmark referenced: Storing spatial memory in a PNG (May 2026)
Source article responded to: AskUI vs SikuliX (April 2026)
