Skip to content
OYYO

OYYO Native Models

OYYO is building its own intelligence.

OYYO Native Models are the proprietary intelligence family being developed specifically for OYYO. They are designed to work with OYYO Memory, tools, agents, language intelligence, business artifacts, policy and the OYYO Core Runtime across local, private, hybrid and hosted environments where hardware permits.

For investorsOYYO Core Runtime

Independent when required. Collaborative when useful.

Native AI, portable execution, hardware awareness, memory integration, tool use, provenance and business context by design.

Last updated,

Why native models

Why build another model family when powerful models already exist?

Because OYYO is not being built to become a front end for somebody else's intelligence.

External models are useful. They can be excellent. OYYO is designed to use them when they improve a task and policy allows it. But a complete intelligence platform should also have an independent native path.

OYYO Prompt Knowledge and OYYO Memory are being designed to provide task instructions and context from maintained knowledge, approved corrections, procedures and source backed project information.

That means OYYO can optimize its own intelligence for the way OYYO actually works, persistent memory, structured output, tools, agents, business artifacts, multilingual intelligence, hardware portability, policy profiles and controlled execution.

The goal is not isolation. The goal is control over the complete product.

Family architecture

One model is not the answer to every device and every job.

The OYYO model family is being designed as a set of capability and hardware classes. Parameter bands are engineering targets, not marketing promises, and can change as benchmark, efficiency and deployment evidence improves.

  • OYYO Nano

    Indicative target class, approximately 1B to 4B parameters

    Ultra light local intelligence for constrained hardware, edge environments and background tasks where RAM, latency and power matter most.

    Low memory use, low power, fast startup, practical local execution, lightweight classification, extraction, routing and background intelligence.

  • OYYO Mini

    Indicative target class, approximately 7B to 9B parameters

    Everyday local OYYO intelligence for laptops and desktops.

    General assistance, multilingual work, structured output, practical tool use, business tasks and strong capability within realistic local hardware limits.

  • OYYO Core

    Indicative target class, approximately 14B to 32B parameters

    Primary professional and enterprise portable intelligence.

    Stronger reasoning, coding, multilingual intelligence, tool use, long context work, business analysis, artifact creation and more demanding agent workflows.

  • OYYO Max

    Indicative target class, approximately 70B class and or efficient Mixture of Experts architecture

    Highest capability workstation, server, enterprise and hosted OYYO intelligence.

    Advanced reasoning, complex execution, large context, heavy synthesis, enterprise workloads and high capability specialist collaboration.

  • OYYO Code

    Specialist model direction for software engineering, repository intelligence, debugging, terminal work, code generation, review and controlled technical execution.

  • OYYO Vision

    Specialist multimodal direction for screenshots, documents, images, visual context and future vision workflows.

  • OYYO Growth

    Specialist direction for business research, market intelligence, positioning, marketing, growth strategy, content and commercial workflows.

These classes describe the intended OYYO model family and engineering target ranges. They do not mean that public weights for every tier are already released. Final size and architecture decisions are benchmark driven.

Parameters explained

4B. 8B. 32B. 70B. What does the B actually mean?

B means billions of model parameters. A 4B class model contains roughly four billion parameters. A 32B class model contains roughly thirty two billion.

But bigger does not automatically mean better for every job. A larger model can require more memory, more compute, more power and more time. A smaller model can be dramatically faster and cheaper if it is strong enough for the task.

OYYO therefore does not treat parameter count as a quality score. The real question is, what is the strongest qualified intelligence that can complete this task on this hardware, under this policy, with the required quality and latency?

  • Capability per GB of memory
  • Capability per watt
  • Task success rate
  • Latency
  • Time to first token
  • Throughput
  • Context capability
  • RAM and VRAM requirement
  • Reliability
  • Tool execution quality
  • Language quality
  • Business task completion

The best model is not always the biggest model. It is the right model for the job.

Model selection

OYYO should understand the machine before asking the user to understand the model.

OYYO is being engineered so model and runtime selection can consider the actual environment rather than forcing every user into one hardware profile.

  1. Physical RAM and available RAM
  2. VRAM and unified memory
  3. CPU architecture and vector capabilities
  4. GPU and NPU backend availability
  5. Memory bandwidth
  6. Thermal and power limits
  7. Storage and model load time
  8. Available quantization
  9. Requested context length
  10. Latency and throughput objective
  11. Task class
  12. Required quality
  13. Privacy policy
  14. Organization policy

OYYO selects the strongest qualified model and configuration that fits the task, the device and the policy.

Current status. OYYO 0.2 is CPU first and already exposes normalized hardware capability information. Real accelerator probing, adaptive offload planning and AutoTune belong to the OYYO 0.3 Adaptive milestone.

Local, private and cloud

The same OYYO concept, wherever intelligence needs to run.

  • OYYO Local

    Run compatible OYYO native models on owned hardware for private, offline and latency sensitive work.

  • OYYO Private

    Deploy inside organization controlled infrastructure where data boundaries and operational control matter.

  • OYYO Cloud

    Use hosted OYYO native capability for managed scale and heavier workloads.

  • OYYO Intelligence

    Combine OYYO native models with another OYYO tier, OYYO specialists, additional approved local models or selected external cloud models when useful.

The runtime remains responsible for context, memory, policy, permissions and workflow state.

Independence

The independence test.

Disconnect all external model providers. Can OYYO still do the work?

A release intended to represent independent OYYO intelligence must pass this question for its declared capabilities.

The test is not whether OYYO can call an external API. The test is whether OYYO can continue to perform its core intelligence, memory, tool, artifact and agent workflows using an OYYO native model when external model providers are disabled.

This is a core product principle.

Collaboration

Independence does not mean isolation.

OYYO can still use the best additional intelligence available when it improves the outcome and the policy allows it.

  1. Another OYYO model tier
  2. An OYYO specialist model
  3. An approved local third party model
  4. An approved external cloud model

The OYYO Runtime remains the controlling system for memory, context, policy, tools, permissions and final workflow state.

Why OYYO models are different

The model is being designed for the system around it.

Typical standalone model experience

OYYO target architecture

Intelligence source

One provider or manually selected model.

Intelligence source

Native OYYO intelligence first, with optional collaboration across other qualified models.

Deployment

Usually defined by the provider or model package.

Deployment

Local, private, hybrid and cloud paths are part of the platform architecture.

Hardware

The user often chooses model size and settings manually.

Hardware

The runtime is being designed to choose the strongest qualified configuration that fits the real device and task.

Memory

Conversation history, project context or external retrieval added around the model.

Memory

Persistent cumulative organizational knowledge is a first class platform layer with provenance, corrections, versions and permissions.

Tools and actions

Tool use depends on the host application.

Tools and actions

Tools, connectors, agents, approvals and execution policy are part of the OYYO runtime architecture.

Policy

Service policy is normally defined by the model provider.

Policy

Public OYYO Cloud follows OYYO policy, organizations can apply organization policy profiles, and local deployments can expose configurable user profiles where permitted.

Provenance

Varies by provider and host application.

Provenance

Provenance is designed into model packages, runtime execution and generated outputs.

Qualification

Often summarized by public benchmark leaderboards.

Qualification

Candidates are qualified on real business execution, tools, agents, language, memory, artifacts, security, reliability and hardware efficiency before promotion.

Commercial experience

Some systems expose token, credit or consumption balances to the user.

Commercial experience

The customer model is designed around monthly plan, tier and user or seat subscriptions, not a falling token or credit balance.

Model and platform features vary across providers. This comparison describes the OYYO product architecture and common standalone model patterns, not a claim that every external platform behaves the same way.

Release gate

An OYYO model does not become official because the name sounds good.

Every official OYYO native or OYYO qualified model release must pass a release process designed around identity, provenance, compatibility, quality and operational safety.

  1. 01

    Identity

    Exact model family, architecture, revision and tokenizer identity.

  2. 02

    Rights and provenance

    Applicable rights, source lineage and transformation records.

  3. 03

    Cryptographic integrity

    Artifact hashes, package hashes and reproducible identity.

  4. 04

    Hardware compatibility

    Declared CPU, GPU, NPU, RAM, VRAM and runtime requirements.

  5. 05

    OYYO Benchmark

    Reasoning, business execution, coding, tools, agents, language, artifacts, memory, multimodal and hardware efficiency.

  6. 06

    Reliability and security

    Malformed input testing, failure behavior, repeatability and operational robustness.

  7. 07

    Quantization validation

    Measure the quality impact of deployment optimizations instead of assuming smaller artifacts behave identically.

  8. 08

    Policy qualification

    Verify behavior under the declared OYYO, organization or local policy profiles.

  9. 09

    Model card

    Publish intended use, capabilities, limitations and release specific facts where public.

  10. 10

    Human acceptance

    A human review remains part of promotion.

Measure first. Promote second.

OYYO Benchmark

A model can win a benchmark and still be wrong for the job.

OYYO Benchmark exists to answer a more practical question. Can this model and runtime reliably complete real work on the hardware, latency, memory and security constraints where OYYO needs to run?

  • General reasoning
  • Business execution
  • Coding and terminal work
  • Tools, agents and MCP
  • Documents and artifacts
  • Language intelligence
  • Memory and temporal knowledge
  • Multimodal capability
  • Growth and marketing work
  • Security and reliability
  • Hardware efficiency

Metrics stay visible individually rather than hidden behind one attractive score. When verified data is available OYYO can publish task success rate, quality, repeatability, time to first token, tokens per second, end to end latency, RAM, VRAM, model load time, context, CPU fallback behavior, recovery behavior, hardware utilization and energy use where measurable.

The OYYO BenchmarkBenchmark methodology on GitHub

Memory integration

OYYO models are being built to work with memory, not pretend the prompt is the whole world.

OYYO Memory is designed to provide a durable knowledge layer across conversations, projects, documents, decisions, corrections and outcomes.

The runtime can assemble the relevant context for a model while preserving permissions and provenance. Native model quality is therefore not evaluated only on isolated prompts. It is evaluated as part of the complete OYYO work system.

Language intelligence

Translate meaning, not vocabulary.

OYYO Language Intelligence is designed around intent, emotion, register, company terminology, slang, culture, relationships and context.

The native model programme includes multilingual reasoning and semantic translation as explicit capability targets. Corrections can feed a persistent translation memory with provenance and priority, so the system can learn the preferred language of the organization over time.

Policy profiles

One model does not need one permanent policy profile for every environment.

OYYO separates the intelligence architecture from the effective deployment policy.

  • Public OYYO Cloud

    Runs under centrally defined OYYO public policy.

  • Organization deployment

    Can apply organization and user policy profiles within the OYYO platform and applicable legal constraints.

  • Local deployment

    Can expose configurable user policy profiles where product configuration and applicable requirements permit.

The effective policy also controls tools and actions, not only model responses.

Commercial model

Intelligence should feel available, not like a meter running down.

OYYO is being designed around predictable monthly plans based on product tier and users or seats.

Customers should not need to watch a token or credit balance decrease every time they use intelligence. OYYO can still measure compute, tokens, storage, bandwidth and tool usage internally for engineering, optimization, capacity and cost control. Those operational metrics are not intended to become the main customer experience.

Public engineering

Public enough to verify the direction. Private enough to protect the technology.

OYYO is proprietary technology and is not open source. The public OYYO Models repository documents selected family targets, model metadata structures, compatibility records, provenance expectations and release qualification rules.

Private architecture research, training recipes, datasets, model transformation methods, checkpoints and proprietary runtime internals remain confidential.

Last updated,

Think. Create. Execute.

Native intelligence, measured before it is promoted.

OYYO Native Models, OYYO Core Runtime and OYYO Benchmark are moving forward in parallel in Dubai.

For investorsOYYO Core Runtime