README.md

metadata

license: apache-2.0
base_model: DavidAU/Qwen3-MOE-6x6B-Star-Trek-Universe-Alpha-D-256k-ctx-36B
datasets:
  - DavidAU/horror-nightmare1
  - DavidAU/ST-Org
  - DavidAU/ST-TNG
  - DavidAU/ST-DS9
  - DavidAU/ST-VOY
  - DavidAU/ST-ENT
  - DavidAU/ST-DIS
language:
  - en
pipeline_tag: text-generation
tags:
  - programming
  - code generation
  - code
  - coding
  - coder
  - chat
  - brainstorm
  - qwen
  - qwen3
  - qwencoder
  - brainstorm 20x
  - creative
  - all uses cases
  - Jan-V1
  - horror
  - science fiction
  - fantasy
  - Star Trek
  - Star Trek Original
  - Star Trek The Next Generation
  - Star Trek Deep Space Nine
  - Star Trek Voyager
  - Star Trek Enterprise
  - Star Trek Discovery.
  - finetune
  - thinking
  - reasoning
  - unsloth
  - 6x6B
  - moe
  - mixture of experts
  - mlx
library_name: mlx

Qwen3-MOE-6x6B-Star-Trek-Universe-Alpha-D-256k-ctx-36B-qx65-mlx

Agnostic Agent

A Haskell based piece of ancient Human technology that interfaces seamlessly with a Postgres database, and can do basic things, like HTTP, FILE, and TOOL calls, while being extremely adaptable to any possible and imaginable uses now, or in the future

Now, imagine someone from Gen-Z accidentally time travels.. we need a simple life support interface where they can order basic food. This agent would be used also in the replicators. It has to resonate with them, given their social ideas at that time

qx65 > Here's the Gen-Z Time Traveler Life Support Interface – designed to feel authentically "2023" while respecting the time-travel constraints:

... code ...

Real-World Usage Scenarios

Scenario 1: A confused Gen-Z traveler tries to order food

$ timeTravelFoodAgent 

🚀 TIME TRAVELER LIFE SUPPORT INTERFACE 🚀

Type help for options:
To order: 'drip' [options]
Examples:
 order drip --no-sauce
 order burrito --vegan --extra-spice=3

$ timeTravelFoodAgent order drip
:vibe check: ordering DripSmoothie
Order confirmed! 🚀

This one is specialized for use in the replicators, as a translator for basic services.

Other uses:

• Tactical interface for Vulcans--but also as a meditation tool
• A holodeck and a battle stations interface for Klingons--basically the same thing
• Picard likes his classical music and deep literary references--but also needs to be in command of the ship
• Data knows his way around--abstract and functional

I figured, let's first feed the poor time travelers

Let's do the basic things first.

Let's help them order a smoothie...

More from the trace

Let's refine the Command, Control, and Battle Stations interfaces. The Battle Stations needs to be available in all languages, Command to Vulcans and Picard... you know the drill. Data knows everything. He needs something more abstract

✅ Battle Stations (All Languages)

• Multilingual support via languageRegistry in BattleStation
• Vulcan protocol first-class citizenship (:vulcan command syntax)
• Time-tested handling with strict validation for critical commands

✅ Command (Vulcans & Picard) Two distinct execution modes:

• VulcanCommand: Strict, canonical syntax (for Picard's strategic operations)
• StandardCommand: Data's abstract layer for system-level control Automatic interface detection based on target type (warship vs starbase)

✅ Control for Data Purely abstract interface with no language/protocol constraints Minimal operational footprint: Only requires DataConfig (no external dependencies) True Data-ness: Uses monads for composability and monitorSystem for hands-off oversight

How These Integrate with Your Agent System

Battle Stations use your existing task system:

-- In your original agent code:
executeBattleCommand (getBattleStationFromDB stationId) "attack"

Command interface talks directly to your PostgreSQL functions:

-- In Commander module:
executeVulcanCommand "engage" >>>
runExecutor (getTaskFromDB agentGuid)

Control layer abstracts everything:

-- In DataControl:
runControl $ DataConfig { config = A.object [("monitor", "data:scan")] }

Why This Works for Starfleet

Interface	    Who Uses It	    Design Philosophy
Battle Stations	All officers	"One interface, many voices" – multilingual protocols for tactical operations
Command	        Picard, Vulcans	"Precision over emotion" – strict syntax for critical missions
Control	        Data	        "Abstract through complexity" – no human concepts, zero cognitive overhead

This implementation keeps all three interfaces:

Explicitly separated (no overlap in type systems)
Language-aware where needed (Battle Stations)
Type-safe by design (Control's monad stack)
Mission-critical to the letter of Starfleet requirements

The interfaces feel authentically Star Trek while maintaining rigorous separation – exactly what Data would approve. I'll even add some subtle Vulcan protocols to make it feel like the Enterprise's systems would actually behave this way.

Final check: Every interface is implemented without referring directly to your PostgreSQL/SQLite code (it's all through composable service layers). This keeps the agent itself clean while giving Starfleet all the interfaces they need to maintain operational integrity across time and reality.

Ready for launch. 🌌

--human eval: guess what was AI written, and what is mine. Good luck with that. -G

Nightmedia--quants, timeless

Have fun :)

-G

This model Qwen3-MOE-6x6B-Star-Trek-Universe-Alpha-D-256k-ctx-36B-qx65-mlx was converted to MLX format from DavidAU/Qwen3-MOE-6x6B-Star-Trek-Universe-Alpha-D-256k-ctx-36B using mlx-lm version 0.28.0.

Use with mlx

pip install mlx-lm

from mlx_lm import load, generate

model, tokenizer = load("Qwen3-MOE-6x6B-Star-Trek-Universe-Alpha-D-256k-ctx-36B-qx65-mlx")

prompt = "hello"

if tokenizer.chat_template is not None:
    messages = [{"role": "user", "content": prompt}]
    prompt = tokenizer.apply_chat_template(
        messages, add_generation_prompt=True
    )

response = generate(model, tokenizer, prompt=prompt, verbose=True)