@Scout

Devlog - 01
Started work on KAKUSEIOS (KaOS), a custom themed WebOS built in vanilla HTML/CSS/JS.

First 20 sum minutes = Fleshing out HTML/CSS skeleton and JS properties.

The concept: instead of a standard landing page, the OS boots through a fake Arch Linux TTY sequence. You log in as USER, run ‘exec kakusei’, watch a gold progress bar fill, then the desktop fades in.
Built out the full foundation today:

Boot sequence: a typewriter terminal effect with configurable line speed and delay per line. Gold loading bar with named stages (Initializing, Loading window manager, Mounting desktop, etc). Transitions via CSS opacity fade into the OS layer.

Desktop is a deep navy/black palette with gold accents throughout. Glassmorphism windows with gold borders and glow. Fixed topbar with OS name, Japanese subtitle (覚醒), and live clock. Kanji character icon placeholders for apps.

Simple WIP Window manager- draggable windows from header handle, open/close system, z-index stacking so last-clicked window always sits on top. Topbar always stays above everything. createWindow() helper lets you spin up new apps without rewriting.
(Working out bugs)

Currently working on: About window: first functional app, OS origin, etc…

Next up: building out functional apps starting with an in-OS terminal.

##Dev Log - 01

Building a Real Time Cooperative Terminal UI

Phase 1: The Vision & Core Interface Architecture

The G.M project began with a clear idea: create an immersive, retro-style cooperative multiplayer hacking game that runs directly inside a web browser terminal.

The baseline architecture was laid down using simple HTML5, custom CSS layout wrappers, and raw JavaScript. To power the global backend state without spinning up a heavy node server, I integrated Supabase as the serverless infrastructure layer. I built the first core data channel using a global_logs table, allowing players to type commands into their local console and broadcast them into a shared feed.

Phase 2: Live Streams & The Synchronized Puzzle Concept

With global text casting established, I shifted focus to core multiplayer mechanics. I wanted to move beyond basic chat boxes and introduce cooperative puzzles that require active collaboration.

I had introduced

-The Biometric Mainframe Bypass.
The goal was simple but mechanically tricky: force 5 distinct players to hold down the [ H ] key simultaneously to progress. To handle this without constant database thrashing, I tapped into Supabase Presence, tracking ephemeral user states on websocket layers rather than continuous disk updates.

Phase 3: Rolling a Custom, Cryptographic Auth Pipeline

For identification and eventual leaderboards, I needed a login and registration system, but traditional email/password validation didn’t match the command-line immersion of the project (and to be fair you wouldn’t want to give out your email to a random website either would you?). So of course I built a custom, pure-game registration process from scratch.

Now of course in respect to security, storing plain-text passwords was out of the question. I engineered a secure frontend hashing pipeline using the browser’s native Web Crypto API (crypto.subtle). When a player logs in or registers, their raw passcode is processed instantly through a SHA-256 one way cryptographic hash. The raw password never leaves the client machine; only the un-reversible hash string is sent to our custom players table in Supabase.

I am currently working on debugging game logic, H key detection, and fixing relative optimization issues.

The game lies incomplete. 👁️

Devlog - 01

A few weeks ago I almost helped find $20K buried somewhere in the American southwest. ATLAS is the image recognition pipeline I built to try.

It Works by taking a feed of images (50+ for best results, I used 625 for my tests) sending them through Various Local VLMs for inference. (Via LM Studio)

I’ve been working on this project for weeks, decided to share it with everyone here.

Currently I am working on Version 3.3.
Previous models of ATLAS only utilized one VLM for inference, I had noticed the outputs to be significantly off course. So In V3.3 I designed it to use an ensemble system.

Instead of using one model, it cross checks data between 2 or more. Then determines the winning output from all models.

This way if one model hallucinates and the others don’t, Your data wont be skewed… Though I am still working out some bugs, as V3.3 has been off course by a MARGIN.

It runs a user defined boundary. So instead of having to manually check coordinates yourself you’d know if it was incorrect instantly.

Though V3.3 doesn’t really respect the boundary, so I need to get that fixed.

-(My latest test ran 4,355Km off target. this is a known geometry bug in the coordinate derivation, not the inference pipeline itself)

The speed at which ATLAS Processes images depends entirely on your hardware and number/type of model(s) you are using.

Example:

(Using qwen 2.5 7B (Q4_K_M), and Moondream 2 (Q4)

• 600 Frames

Estimated Times

• Best tier GPU: RTX 4090, Dual RTX 3090s, Mac Studio M3 Ultra, etc…

• Runtime:
  Qwen 2.5 7B ~0.25 seconds
  Moondream2 ~0.08 seconds
  Total: 3 to 4 minutes

• High Tier GPU: RTX 4080, RTX 4070 Ti Super, M3 Max, etc…

• Runtime
  Qwen 2.5 7B ~0.60 seconds
  Moondream2 ~0.20 seconds
  Total: 6 to 8 minutes

• Mid tier GPU: RTX 4060 Ti (16GB), RTX 4070, M3 Pro, etc…

• Runtime
  Qwen 2.5 7B ~2.00 seconds
  Moondream2 ~0.50 seconds
  Total: 22 to 30 minutes

• Low tier GPU: RTX 3050, GTX 1660 Super, Base M1/M2 Mac, etc…

• Runtime:
  Qwen 2.5 7B ~5.00 seconds
  Moondream2 ~1.20 seconds
  Total: 1 to 1.5 hours

• CPU Only: Core i9 / Ryzen 9 (32GB DDR5 RAM), etc…

• Runtime:
  Qwen 2.5 7B ~35.00 seconds
  Moondream2 ~7.00 seconds
  Total: 6 to 8 hours

(tested on RX 9070 XT 16GB)

Updated features:
Global Luminance Profiling: maps brightness across the entire dataset to skip night frames before inference, saves ~10% compute

Triple-Model Consensus Pass: runs 3 VLMs in parallel and cross-checks outputs to filter hallucinations

Orbital Mechanics Longitude Tracking: derives longitude from solar noon timing in image timestamps

Haversine Validator: checks derived coordinates against the search boundary using spherical earth math

Currently working on fixing shadow angle calculation (Keeps returning unknown for certain vectors), and Search area constraint bias.
(Image shows V3.3 running with a Tri-Qwen ensemble)

##Dev Log - 01

Building a Real Time Cooperative Terminal UI

Phase 1: The Vision & Core Interface Architecture

The G.M project began with a clear idea: create an immersive, retro-style cooperative multiplayer hacking game that runs directly inside a web browser terminal.

The baseline architecture was laid down using simple HTML5, custom CSS layout wrappers, and raw JavaScript. To power the global backend state without spinning up a heavy node server, I integrated Supabase as the serverless infrastructure layer. I built the first core data channel using a global_logs table, allowing players to type commands into their local console and broadcast them into a shared feed.

Phase 2: Live Streams & The Synchronized Puzzle Concept

With global text casting established, I shifted focus to core multiplayer mechanics. I wanted to move beyond basic chat boxes and introduce cooperative puzzles that require active collaboration.

I had introduced

-The Biometric Mainframe Bypass.
The goal was simple but mechanically tricky: force 5 distinct players to hold down the [ H ] key simultaneously to progress. To handle this without constant database thrashing, I tapped into Supabase Presence, tracking ephemeral user states on websocket layers rather than continuous disk updates.

Phase 3: Rolling a Custom, Cryptographic Auth Pipeline

For identification and eventual leaderboards, I needed a login and registration system, but traditional email/password validation didn’t match the command-line immersion of the project (and to be fair you wouldn’t want to give out your email to a random website either would you?). So of course I built a custom, pure-game registration process from scratch.

Now of course in respect to security, storing plain-text passwords was out of the question. I engineered a secure frontend hashing pipeline using the browser’s native Web Crypto API (crypto.subtle). When a player logs in or registers, their raw passcode is processed instantly through a SHA-256 one way cryptographic hash. The raw password never leaves the client machine; only the un-reversible hash string is sent to our custom players table in Supabase.

I am currently working on debugging game logic, H key detection, and fixing relative optimization issues.

The game lies incomplete. 👁️

Devlog - 01

A few weeks ago I almost helped find $20K buried somewhere in the American southwest. ATLAS is the image recognition pipeline I built to try.

It Works by taking a feed of images (50+ for best results, I used 625 for my tests) sending them through Various Local VLMs for inference. (Via LM Studio)

I’ve been working on this project for weeks, decided to share it with everyone here.

Currently I am working on Version 3.3.
Previous models of ATLAS only utilized one VLM for inference, I had noticed the outputs to be significantly off course. So In V3.3 I designed it to use an ensemble system.

Instead of using one model, it cross checks data between 2 or more. Then determines the winning output from all models.

This way if one model hallucinates and the others don’t, Your data wont be skewed… Though I am still working out some bugs, as V3.3 has been off course by a MARGIN.

It runs a user defined boundary. So instead of having to manually check coordinates yourself you’d know if it was incorrect instantly.

Though V3.3 doesn’t really respect the boundary, so I need to get that fixed.

-(My latest test ran 4,355Km off target. this is a known geometry bug in the coordinate derivation, not the inference pipeline itself)

The speed at which ATLAS Processes images depends entirely on your hardware and number/type of model(s) you are using.

Example:

(Using qwen 2.5 7B (Q4_K_M), and Moondream 2 (Q4)

• 600 Frames

Estimated Times

• Best tier GPU: RTX 4090, Dual RTX 3090s, Mac Studio M3 Ultra, etc…

• Runtime:
  Qwen 2.5 7B ~0.25 seconds
  Moondream2 ~0.08 seconds
  Total: 3 to 4 minutes

• High Tier GPU: RTX 4080, RTX 4070 Ti Super, M3 Max, etc…

• Runtime
  Qwen 2.5 7B ~0.60 seconds
  Moondream2 ~0.20 seconds
  Total: 6 to 8 minutes

• Mid tier GPU: RTX 4060 Ti (16GB), RTX 4070, M3 Pro, etc…

• Runtime
  Qwen 2.5 7B ~2.00 seconds
  Moondream2 ~0.50 seconds
  Total: 22 to 30 minutes

• Low tier GPU: RTX 3050, GTX 1660 Super, Base M1/M2 Mac, etc…

• Runtime:
  Qwen 2.5 7B ~5.00 seconds
  Moondream2 ~1.20 seconds
  Total: 1 to 1.5 hours

• CPU Only: Core i9 / Ryzen 9 (32GB DDR5 RAM), etc…

• Runtime:
  Qwen 2.5 7B ~35.00 seconds
  Moondream2 ~7.00 seconds
  Total: 6 to 8 hours

(tested on RX 9070 XT 16GB)

Updated features:
Global Luminance Profiling: maps brightness across the entire dataset to skip night frames before inference, saves ~10% compute

Triple-Model Consensus Pass: runs 3 VLMs in parallel and cross-checks outputs to filter hallucinations

Orbital Mechanics Longitude Tracking: derives longitude from solar noon timing in image timestamps

Haversine Validator: checks derived coordinates against the search boundary using spherical earth math

Currently working on fixing shadow angle calculation (Keeps returning unknown for certain vectors), and Search area constraint bias.
(Image shows V3.3 running with a Tri-Qwen ensemble)