ZYR3.1MoE (ZV1.1MeO)

This is a merged, standalone model. Fully self-contained weights (~18 GB in 5 safetensors shards). Load it and it works - no adapter, no PEFT, nothing else to fetch.

That means:

• No separate download step and no adapter/PEFT step.
• Load it like any normal transformers model and it works.
• ZYR3.1MoE is the complete model: weights, tokenizer, and chat template are all in this repo.

What it is

ZYR3.1MoE is a layered multi-agent AI runtime. Instead of a single prompt going straight to a model, work flows through an orchestration stack:

USER -> ACN -> MeO + specialist agents -> ATP -> ZYR3.1MoE (merged model) -> FINAL ANSWER

• ATP - the control center: plans, decomposes, assigns, monitors, requests verification, and decides when a task is done.
• ACN - the communication layer that carries every message between ATP, MeO, and the agents.
• MeO - the learned orchestration layer (Router / Reasoner / Synthesizer) that picks which specialists work together and how to combine results.
• 10 specialist agents - Planner, Researcher, Reasoner, Coder, Math, Critic, Fact Checker, Creative, Optimizer, Reviewer.

ACN and ATP are runtime systems, not separate neural weights. Only the single merged model below them is real - a mixture-of-experts orchestration on one dense base.

The trained-behaviour vs real-execution boundary

This distinction matters, so it is stated up front:

Layer	What it is	Source of truth
Team chat (ATP / ACN / MeO / specialists)	Trained behaviour - the orchestration style the model learned	Model output
Execution (tests, commands, exit codes)	External runtime	Real exit code + parsed test output

The team chat below is a demonstration of the trained behaviour. Its test counts ("14 passed, 2 failed") are simulated inside the model's output - they are not real executions. A separate, genuinely real fail -> repair -> pass trace is in REAL_TRACE.md, with real command output and real exit codes.

Simple questions don't spin up the ecosystem

Not every prompt is a task. The runtime triages first:

• Simple questions ("what is ATP?", "who are you?", "explain the ACN bus") are answered directly by the main model: no ACN traffic, no MeO routing, no specialist agents, no execution.
• Work requests ("build...", "fix...", "implement...", "run the tests") trigger the full plan -> route -> specialists -> verify loop.

runtime/triage.py decides this; runtime/__init__.py skips orchestration for direct answers and returns {"scale": "direct", "agents_used": []}. The full ecosystem becomes a deliberate choice for real work, not a default for chat.

Load it

pip install -U transformers accelerate safetensors hf_transfer
export HF_HUB_ENABLE_HF_TRANSFER=1   # faster parallel download of the 5 shards

from transformers import AutoModelForCausalLM, AutoTokenizer

tokenizer = AutoTokenizer.from_pretrained("zyr-AGENT/ZYR3.1MoE")
model = AutoModelForCausalLM.from_pretrained(
    "zyr-AGENT/ZYR3.1MoE",
    device_map="auto",
    torch_dtype="auto",
)
model.eval()

messages = [{"role": "user", "content": "Build a full-stack auth website."}]
text = tokenizer.apply_chat_template(messages, tokenize=False, add_generation_prompt=True)
inputs = tokenizer([text], return_tensors="pt").to(model.device)
out = model.generate(**inputs, max_new_tokens=1024)
print(tokenizer.decode(out[0][inputs["input_ids"].shape[1]:], skip_special_tokens=True))

Memory: expect ~24 GB VRAM in bf16. A 4-bit load may fit smaller cards, but quantization support for this hybrid-architecture model is not guaranteed - use a 24 GB+ GPU for reliable results.

What it looks like - trained team behaviour (execution simulated)

A run looks and feels like a team working the task. This is the interaction style the merged model was trained to drive. The tester counts here are part of the model's generated output, not real test executions (see REAL_TRACE.md for a real one):

User: yo zyr3.1, can you build me a full-stack auth website? signup, login, password reset, database, tests, all of it

ZYR3.1: Yeah, I got you. I'll break it down first, then I'll build it piece by piece and test everything before I call it done.

ATP: Alright. I'm mapping the task now.

ATP -> Planner: Figure out the project structure and dependencies.

Planner: Got it. I'm breaking it into frontend, backend, database, auth, reset flow, and testing.

ATP -> Coder: Start on the backend architecture.

Coder: On it. I'm setting up the database models and auth flow first.

ATP -> Researcher: Check the security requirements while they work.

Researcher: Checking password storage, sessions, reset tokens, validation, and the common failure points.

MeO Router: I'd keep Planner, Coder, Researcher, Critic, and Reviewer active for this one.

ATP: Makes sense. Let's start building.

Coder: Database is ready. I'm working on signup and login now.

ATP: Status?

Coder: Signup and login are mostly done. Moving on to password reset.

Researcher: One thing to watch: reset tokens need strict expiration and validation.

Coder: Good catch. I'm adding that now.

Coder: Okay, first implementation is ready.

ATP: Don't call it finished yet. Run everything.

Tester (your computer): Running the application and test suite...

Tester: 14 passed, 2 failed.

ATP: Alright, we've got a problem. Hold completion.

ATP -> Critic: Can you find what broke?

Critic: Yep. The password-reset token expiration check isn't being enforced correctly.

ATP: Got it. Send that back to Coder.

ACN -> Coder: Fix token expiration validation and update the affected tests.

Coder: Fixed. Running the tests again.

Tester: 16 passed, 0 failed.

ATP: Nice. One final review.

Reviewer: Looked through the auth flow and the changes. Everything checks out. No unresolved issues.

ATP: Verification complete. We're done.

ZYR3.1: Done. The auth system is built, the issue found during testing was fixed, and the final version passed all 16 tests.

The loop in action: plan -> assign -> build -> execute -> detect failure -> critic review -> repair -> retest -> verify -> finish. This is trained behaviour, not a real execution.

Real, externally verified execution (not simulated)

The counterpart to the above: one small, observable end-to-end run where the first test run really fails, the failure is read from real output, the work is sent back, it is repaired, and a real re-run passes. Completion is gated on the real result - no success is claimed without it. The tester is a real computer (by default the one running the command), not a simulated environment.

  5 AGENT_SELECTED    planner, reasoner, critic, reviewer, optimizer, coder
 14 ACTION_REQUESTED  run #1  $ python3 -m unittest discover -s tests -t . -v
 15 ACTION_RESULT     run #1  exit=1 ok=False passed=1 failed=1
      FAIL: test_token_is_signed ... AssertionError: False is not true : token-for-ada
      Ran 2 tests ... FAILED (failures=1)
 17 FAILURE_DETECTED  run #1 exit=1 1 passed / 1 failed
 25 REPAIR_REQUESTED  Coder patched token signing in response to the real failure.
 28 ACTION_REQUESTED  run #2  $ python3 -m unittest discover -s tests -t . -v
 29 ACTION_RESULT     run #2  exit=0 ok=True passed=2 failed=0
      Ran 2 tests ... OK
 36 VERIFICATION      pass  exit=0 2 passed / 0 failed
 38 DECISION          [COMPLETE] Task complete (externally verified)

• Full capture and methodology: REAL_TRACE.md
• Executor + trace + live telemetry GUI: plugin/
• Reproduce: python plugin/e2e.py --no-gui --no-block

The trace emits state transitions, routing decisions and external observations - never private chain-of-thought.

Important - this model is not perfect

This is an experimental model, and it may not always be right:

• It can hallucinate APIs, file names, or security details - verify anything you ship.
• The multi-agent "team chat" above is the interaction style it was trained for; output quality varies by task, context length, and quantization.
• Test failures it reports (tester counts, etc.) are simulated inside the model's output, not real test runs. See REAL_TRACE.md for a real, externally verified execution path.
• Do not trust it for production auth, secrets handling, or anything safety- critical without a human review.

Deploy it as an endpoint

Ready-made Docker package: deploy/hf_space/ (app.py, Dockerfile, requirements.txt, README.md).

Option A - Hugging Face Docker Space (GPU)

1. Create a new Space (SDK: Docker), org zyr-AGENT.
2. Upload the four files from deploy/hf_space/.
3. Settings -> Hardware -> pick a GPU (>= 24 GB VRAM, e.g. A10G/L4). GPU Spaces are paid; the app returns a clear 503 on /v1/* until a GPU is enabled.
4. URL becomes https://<owner>-<space>.hf.space/v1.

Note: as of Sept 2026 Hugging Face requires a PRO subscription to host Docker Spaces (API returns 402 without it).

Option B - Hugging Face Inference Endpoints (managed)

1. In the Hub go to Models -> zyr-AGENT/ZYR3.1MoE -> Deploy -> Inference Endpoints.
2. Task: text-generation, GPU instance with >= 24 GB VRAM.
3. Endpoint URL is OpenAI-compatible after clicking POST /v1/chat/completions.

Option C - Self-host (docker run)

docker build -t zyr31moe deploy/hf_space
docker run --gpus all -p 7860:7860 zyr31moe
curl localhost:7860/v1/chat/completions -H "Content-Type: application/json" \
  -d '{"messages":[{"role":"user","content":"hi"}]}'