OX Alpha model: three routes, one useful test

Why it matters

A free coding model becomes interesting when it helps finish work you can actually review and maintain. EarnixLab’s scissor lift experiment is a useful starting point because the output has visible constraints: the platform must move, the arms must stay connected, and the controls must keep working throughout the motion. A screenshot can only tell you part of that story.

The access details have changed since the August recording. As checked on November 6, 2026, OpenRouter identifies OX Alpha as Z.ai’s GLM-5.3-Flash. The uncertainty about its developer was part of the preview period. The current page also says the provider retained prompts and completions from that offering without using them for training. Official OX Alpha page.

My adoption criterion would be the time needed to reach a reviewed result. Waiting, fixing errors and understanding generated code all belong in that calculation. The demonstration belongs to the channel; this draft does not claim an independent reproduction. What follows adds a repeatable evaluation method so you can judge the model against your own development work.

Key points

• 0:34 The channel introduces a model aimed at coding and extended agent tasks. That positioning suggests suitable experiments, but it still needs to be tested against explicit requirements.
• 1:37 The first access route places Cline inside VS Code. Its practical appeal is keeping the agent’s edits and the developer’s review in the same working environment.
• 2:42 The presenter chooses the highest reasoning effort setting. Record that choice when reproducing the experiment: different settings can change both latency and results.
• 3:14 The scissor lift request includes a meaningful constraint: its arms must remain connected while the platform moves. That makes the task suitable for checks at multiple slider positions.
• 3:47 The second route uses OpenRouter’s API. This separates model access from the coding interface and makes it possible to build an evaluation into your own application.
• 4:19 API key creation includes an optional spending limit. Leaving that field blank does not establish free access or remove request quotas; these are separate controls.
• 5:24 The third route uses the OpenCode application. The setup shown removes some initial configuration work, while the model catalog and offer terms still need a fresh check.
• 6:29 The presenter inspects the generated simulation. Movement, joints and visual detail provide useful evidence, but the inspection shown leaves room for systematic checks and code review.
• 7:32 The channel reports roughly ten minutes of generation from one request. That describes a single run; it does not establish repeatability or the effort required to maintain the result.

How to apply

Check access to the OX Alpha model first

Start with the current service pages rather than relying on the model picker shown in the recording. Preview names and promotional offers can change. OpenCode’s documentation currently lists GLM-5.3-Flash Free as a limited-time offer, providing a current route to experiment without assuming permanent unlimited access. OpenCode model availability and terms.

Pick one route initially. Cline fits an editor-centered workflow; OpenCode offers an application-based starting point; OpenRouter suits a custom integration. Once you start comparing models, keep the client unchanged. Changing the model, permissions and interface together makes the results harder to interpret.

For API access, create a dedicated experimental key, keep it outside your repository and set a spending ceiling you are comfortable with. Check request quotas separately. OpenRouter documents credit limits, budget limits and rate limits as distinct mechanisms. An uncapped key does not bypass the other controls. OpenRouter limits documentation.

Write the acceptance criteria before generating code

For the lift experiment, I would use this evaluation sheet:

| Criterion | Proposed check | | --- | --- | | Connections | Inspect joints at 0%, 25%, 50%, 75% and 100% slider positions | | Geometry | Confirm that each rigid arm keeps the same length | | Interaction | Operate the height control with a mouse and keyboard | | Execution | Start from a fresh checkout and inspect console errors | | Maintainability | Request a small change and review the resulting diff |

The geometry has a useful invariant. If a rigid arm has length L, with horizontal endpoint separation d and vertical separation h, then d² + h² should remain equal to L². A scene can look plausible while stretching its parts to conceal incorrect joints. Checking the invariant makes the requirement more precise than asking whether the animation looks convincing.

You can also replace the 3D scene with a task closer to your work. A CSV importer using synthetic records is a good example: specify valid inputs, malformed rows and the expected error messages. The evaluation remains useful because success is defined before the output arrives.

Give the agent something reviewable to deliver

Here is a proposed prompt for reproducing the lift task:

Build an interactive scissor lift in Three.js with a height control. Keep arm lengths constant and connected endpoints coincident throughout the motion. Include keyboard controls, startup instructions and an explanation of the geometry. When finished, list the checks you actually ran and the checks that still require manual inspection.

This is an evaluation prompt, with no independently measured outcome presented here. It adds deliverables that make review easier. You still need to verify any claim that the agent ran a check successfully.

Work in a disposable project with synthetic content. Give the agent the permissions needed for that task, and inspect proposed commands and file changes. This also keeps the experiment reproducible: the next candidate should receive the same starting files and requirements.

Count review time alongside generation time

Set a fixed allowance, such as fifteen minutes of execution and two correction rounds per candidate. Record the model identifier, provider, date, reasoning setting, waiting time and your own review minutes. If consistency matters, run three attempts from the same starting state. Treat a single attempt as exploration rather than a reliable performance estimate.

Then request a small follow-up: display the current height and accept a numeric height input. Check whether the agent preserves the original motion, changes only the necessary files and explains the implementation. This follow-up adds evidence about maintenance that the first visual result cannot provide.

My threshold for adoption would be meeting the acceptance criteria while reducing total implementation, correction and review time against the existing workflow. Keep that decision scoped to the kind of task you tested. If the free offer ends, the same measurements can help you decide whether paid access still saves enough effort. The lasting result is an evaluation you can reuse whenever another coding model arrives.