- Ox Alpha performance combines coding ability, sustained reasoning, and production-oriented agent workflows.
- Throughput is listed at 23 tokens per second for the primary provider and varies by measurement window.
- Latency is reported at 5.30 seconds P50 on the provider view, with broader dashboard averages also available.
- Reliability reached 99.99% uptime and 99.51% availability across the reported three-day period.
- Best fit includes software engineering, visual-context tasks, and long-horizon automation.
Ox Alpha Performance Overview
Ox Alpha is a reasoning model built for coding, sustained agentic work, complex problem solving, and production workloads. Its performance profile is broader than a single speed score: response quality, context capacity, tool reliability, and multimodal handling all affect how useful it is in practice.
The model was released on August 20, 2026, and is presented as a stealth model operated by an anonymous third-party provider. OpenRouter routes requests to that provider but does not claim ownership or development responsibility. The model is listed at no token cost during the reported preview period.
| Metric | Reported result | What it means |
|---|---|---|
| Context window | 1M tokens | Suitable for large repositories, long documents, and extended task histories |
| Provider count | 1 provider | Requests are forwarded directly without a routing choice |
| Provider throughput | 23 tok/s | Listed P50 throughput for the primary provider view |
| Provider latency | 5.30 s | Listed P50 round-trip latency |
| Tool-call error rate | 2.27% | Reported average tool-call failure rate |
| Cache hit rate | 81.72% | Reported provider cache performance |
| Three-day uptime | 99.99% | Percentage of the period with at least one provider responding |
| Three-day availability | 99.51% | Percentage of requests successfully served |
Video Highlights:
- A one-shot coding demonstration attempts to build a voxel-style Minecraft-like environment from scratch.
- Creative mode is shown as more usable than the tested survival flow.
- The generated demo includes crafting, animated pigs, caves, tools, fall damage, music, and mining interactions.
- Freezing and runtime errors appear during movement and later world interactions.
- The demonstration is useful as a practical capability example, not a standardized benchmark.
The most important conclusion is that Ox Alpha shows promise for ambitious coding tasks while still requiring validation. Its large context window and multimodal positioning are strong advantages, but observed freezes and tool errors make monitoring essential for unattended work.
Treat dashboard metrics and practical demonstrations as complementary evidence. The dashboard measures service behavior, while a one-shot build reveals how the model handles an open-ended task under pressure.
Throughput, Latency, and Reliability
Ox Alpha performance data should be read in terms of measurement scope. The provider panel lists 23 tokens per second and 5.30 seconds of P50 latency. The broader OpenRouter dashboard reports separate percentile averages across all locations and a three-day window.
Those figures are not necessarily contradictory. A provider-specific P50 and an all-location percentile average can use different samples, time ranges, traffic conditions, and aggregation methods. For planning purposes, use them as indicative ranges rather than fixed guarantees.
| Measurement view | Throughput | Latency | Scope |
|---|---|---|---|
| Provider listing | 23 tok/s | 5.30 s P50 | Primary provider view |
| P50 dashboard average | 36 tok/s | 3.38 s P50 | All locations, reported dashboard sample |
| P75 dashboard average | 49 tok/s | 7.16 s P75 | Higher-latency requests included |
| P90 dashboard average | 60 tok/s | 14.39 s P90 | Slower request tail |
| P95 dashboard average | 69 tok/s | 22.35 s P95 | Extended response delays |
| P99 dashboard average | 85 tok/s | 51.16 s P99 | Long-tail behavior |
For interactive coding, P50 latency is the most noticeable figure because it reflects a typical request. For automation, P90 through P99 matter more. A workflow that performs many sequential calls can be affected by occasional slow responses even when the median feels responsive.
End-to-end latency is also higher than basic request latency because it can include generation, tool execution, application processing, and additional round trips.
| End-to-end percentile | Average latency |
|---|---|
| P50 | 16.65 s |
| P75 | 31.24 s |
| P90 | 61.69 s |
| P95 | 93.22 s |
| P99 | 235.27 s |
The reported uptime and availability are encouraging for a preview model. However, availability below the uptime figure shows why those measurements should remain separate. A service may respond during nearly the entire monitoring period while still producing failed requests or upstream errors.
Do not size an unattended agent around median latency alone. Add retries, timeouts, checkpointing, and clear recovery states for slower or failed requests.
Coding and Agentic Workload Fit
Ox Alpha is explicitly positioned for software engineering, sustained agentic tasks, and production-oriented workloads. That makes repository-scale work a central part of its identity rather than an optional feature.
The model’s 1M-token context window can be valuable when a task involves many files, extensive logs, design documents, or a long sequence of prior decisions. Large context does not automatically guarantee correct reasoning, so teams should still provide focused prompts, meaningful file boundaries, and test-driven feedback.
Repository Analysis
- Large context capacity
- Useful for cross-file relationships
- Review outputs before merging
Long-Horizon Tasks
- Supports extended planning
- Better suited to staged execution
- Use checkpoints between phases
Production Workflows
- Designed for operational workloads
- Monitor errors and latency
- Keep human approval for risky changes
Visual Context
- Accepts image and video input
- Can combine text with visual evidence
- Validate interpretations independently
A practical workflow should separate planning from execution. First, ask Ox Alpha to inspect the repository and identify dependencies. Next, request a limited implementation with explicit acceptance criteria. Finally, run tests, inspect the diff, and ask for targeted corrections rather than a broad rewrite.
| Workload | Expected advantage | Recommended control |
|---|---|---|
| Codebase investigation | Large context can reduce repeated file loading | Summarize findings before editing |
| Multi-file refactor | Sustained task handling may help preserve intent | Apply changes in small batches |
| Bug diagnosis | Reasoning and log analysis are relevant strengths | Reproduce the issue before changing code |
| Test generation | Coding focus supports test-oriented prompts | Run tests independently |
| Agent automation | Long-horizon design fits multi-step workflows | Add retries and human checkpoints |
| Visual debugging | Image and video input expand evidence sources | Confirm visual conclusions with code or logs |
The practical voxel-world demonstration supports the idea that Ox Alpha can attempt complex coding projects from a high-level prompt. It produced several recognizable systems, including crafting, movement, environmental elements, tools, mining, animation, and music. At the same time, freezes and a runtime error appeared, showing why generated software still needs debugging and incremental verification.
Use Ox Alpha for analysis, implementation drafts, refactoring plans, and test creation. Keep execution observable, and require tests or review before accepting production changes.
Multimodal Input and Practical Testing
Ox Alpha is documented as accepting text, images, and video as input while returning text. This makes it relevant to tasks that combine source code with screenshots, interface recordings, diagrams, or product demonstrations.
Multimodal performance should be tested with concrete evaluation sets rather than broad assumptions. A useful test includes a known image or video, a question with a verifiable answer, and a scoring method that distinguishes observation from inference.
Define the Evidence
Choose a small set of screenshots, diagrams, or short videos that represent the task your team actually performs. Record the expected facts before sending the prompt.
Add Structured Instructions
Ask Ox Alpha to separate visible observations, uncertain conclusions, and recommended actions. This makes visual errors easier to identify.
Compare Against Ground Truth
Check names, locations, states, measurements, and code references against trusted data. Do not treat a confident answer as proof of accuracy.
Measure Workflow Value
Record response time, correction count, tool failures, and the amount of manual review required. Compare the complete workflow, not just the first answer.
For software teams, visual context can support UI regression analysis, diagram interpretation, bug triage, and documentation review. For agent builders, it may allow a single task to combine repository context with screenshots or recorded behavior.
The practical demonstration also illustrates an important testing principle: a model can generate many visible features while still failing under state changes. Movement freezes, interaction issues, or late-stage runtime errors may not appear during a brief first inspection. Testing should therefore include repeated actions, reloads, state transitions, and error recovery.
| Test area | Suggested check | Success signal |
|---|---|---|
| Image understanding | Identify interface elements or diagram labels | Correctly separates visible facts from guesses |
| Video understanding | Describe actions and state changes | Tracks sequence without inventing events |
| UI debugging | Compare expected and actual screen states | Produces testable troubleshooting steps |
| Code plus visuals | Connect a screenshot to relevant files | References the correct implementation area |
| Long sessions | Continue a task across multiple turns | Preserves constraints and prior decisions |
Image and video support expands the input format, but it does not remove the need for ground-truth checks. Use visual prompts as evidence, not as an automatic source of truth.
Setup, Monitoring, and Evaluation Checklist
OpenRouter provides an OpenAI-compatible API path for Ox Alpha using the model slug stealth/ox-alpha. The quick-start flow requires an OpenRouter API key, an environment variable, and a request that names the model. Streaming can be enabled when an application needs incremental output.
The model is listed at zero input and output cost in the supplied pricing data. Because it is a preview operated by a third party, teams should still review the applicable Stealth Model Terms and data-handling conditions before sending sensitive material.
Create an API Key
Generate an OpenRouter API key and store it as an environment variable such as OPENROUTER_API_KEY. Avoid placing credentials directly in source files.
Select the Model
Set the request model to stealth/ox-alpha. Use the OpenRouter-compatible endpoint or an SDK that supports the documented request format.
Enable Streaming When Useful
Add streaming when your interface benefits from partial output. For batch jobs, non-streaming responses may simplify collection and logging.
Add Operational Controls
Configure request timeouts, retry limits, logging, output validation, and checkpoints before allowing the model to perform extended agentic work.
Review the Result
Run tests, inspect file changes, validate tool output, and approve only the modifications that satisfy the original acceptance criteria.
The Ox Alpha API and provider page on OpenRouter contains the current model slug, pricing display, provider metrics, parameters, and quick-start examples. It also identifies the model as third-party operated and explains the preview terms.
Performance Review Checklist:
- Confirm the request uses the stealth/ox-alpha model slug
- Track latency at P50, P90, and P99 where possible
- Measure tool-call failures and retry behavior
- Test large-context prompts with representative repositories
- Validate image and video answers against known evidence
A strong evaluation should compare task completion quality with operational cost in time and review effort. The listed token price is zero, but engineering time spent correcting errors remains part of the real workflow cost.
Start with read-only analysis and code suggestions. Expand permissions only after Ox Alpha meets your accuracy, latency, and recovery requirements on representative tasks.
Ox Alpha Performance FAQ
Q: What does Ox Alpha performance measure?
It includes coding and reasoning capability, throughput, latency, tool-call reliability, context capacity, multimodal input support, uptime, and availability. No single metric describes the full model experience.
Q: Is Ox Alpha free to use?
The supplied OpenRouter pricing page lists zero input and output token prices for the reported preview. Availability, limits, and terms can change, so check the current provider page before building a dependency.
Q: How fast is Ox Alpha?
The provider view lists 23 tokens per second and 5.30 seconds of P50 latency. A broader dashboard view reports different percentile averages, including 36 tokens per second and 3.38 seconds at P50, so results depend on the measurement scope.
Q: Is Ox Alpha suitable for production agents?
It is designed for production workloads and sustained agentic work, but preview status, one-provider hosting, tool-call errors, and long-tail latency require safeguards such as retries, monitoring, checkpoints, and human review.
Ox Alpha has a strong profile for coding and long-horizon tasks, but observed demonstrations and preview metrics should be validated against your own workload before production adoption.