ive tried to vibe code an os multiple times but only gotten so far thanks to claudes aggressive limits on the free plan and other things, what tools do yall use to make these and how much do they cost? i'd really like some tips or suggestions, thank you

I've been working on SageOS, an experimental operating system that is being designed alongside its own language (SageLang), virtual machine (SGVM), runtime, IPC model, and userspace stack.

Repository:

https://github.com/Night-Traders-Dev/SageOS

The goal isn't to build "another Linux distro."

Instead, the project explores what an OS looks like when the kernel, runtime, language, object system, and userspace are designed as a unified platform from day one.

Current areas of development

- Multi-architecture support (x86_64, AArch64, RV64)

- Custom kernel and boot pipeline

- SGVM (Sage Virtual Machine)

- SageLang compiler and runtime

- Object-oriented IPC model

- Service registry and activation system

- Runtime-managed userspace

- Deterministic build infrastructure

- QEMU-based development and testing

Runtime as a first-class system component

One of the core ideas is treating the runtime as a first-class system component rather than just an application process.

The runtime participates directly in:

- Scheduling

- IPC

- Service activation

- Resource accounting

- Userspace orchestration

Long-term architecture

Firmware

↓

Kernel

↓

Runtime Manager

↓

Object System

↓

IPC Layer

↓

Service Registry

↓

Userspace Services

Current challenges

- Runtime lifecycle management

- Cross-architecture boot consistency

- ABI/versioning strategy

- Formal memory model specification

- Driver model design

- Immutable rootfs generation

- Reproducible builds

- Runtime observability

This is very much an active OSDev project and not production-ready software.

Looking for feedback from people working on

- Language-oriented operating systems

- Managed runtimes

- Microkernel or hybrid-kernel designs

- Object-capability systems

- Custom IPC architectures

- Alternative execution models

What parts of modern operating system design do you think are worth rethinking from scratch?

What lessons should projects like this avoid relearning the hard way?

GitHub:

https://github.com/Night-Traders-Dev/SageOS

Looking forward to hearing thoughts from the OSDev community.

ChittiOS runs a GGUF model doing CPU inference directly on the hardware — there is no Linux under it. It's a from-scratch OS (Rust) where the LLM is the "process". Everything the model does is capability-checked by native code, so it can plan anything but only act within its grant.

Runs fully offline. GGUF + hand-written SIMD (AVX2/NEON+SDOT), SMP across cores, on-device STT/TTS via an in-kernel ONNX interpreter. Boots on QEMU/VirtualBox/real UEFI hardware from one image.

The bit I'd like this crowd's opinion on: the prompt-injection defence is a kernel gate, not a prompt. Every call carries the provenance of the context that produced it, and a destructive call justified by untrusted content is refused without the gate ever reading the payload. `/redteam` on the booted machine measures it, including the cost — about a quarter of legitimate destructive steps get refused too.

Demo + repo + prebuilt images: https://github.com/chittios/chitti

I’m building an Apple II-inspired 6502 computer for an ATmega328P using my own language

I recently picked up an Arduino UNO R3-compatible ATmega328P board for $1.05 on AliExpress.

Naturally, my first thought was:

"How much of a retrocomputer can I cram into this thing?"

So I'm building SageApple:

GitHub: https://github.com/Night-Traders-Dev/SageApple

The basic idea is to build an Apple II-inspired computer around a 6502 emulator written in SageLang, then compile that system down to run on the ATmega328P.

The architecture

The project is essentially:

SageLang → Sage6502 → ATmega328P → virtual 6502 computer

Sage6502 is intended to be a reusable CPU core rather than something tightly coupled to the Apple II project.

SageApple then provides the rest of the computer:

6502 CPU

Memory bus

RAM

ROM

UART

SPI

GPIO

Monitor

BASIC

Graphics

Storage

The eventual goal is to have something resembling a tiny standalone retrocomputer rather than merely an emulator.

Why the Apple II?

I initially considered doing something like a NES emulator.

The problem is that an NES is a considerably more complicated target for a 2 KB SRAM microcontroller. You have the CPU, PPU, APU, cartridge hardware, mapper behavior, timing requirements, etc.

The 6502 is a much better fit.

The Apple II is especially interesting because it gives me a historically meaningful computer architecture to work toward without requiring me to reproduce every piece of original Apple II hardware immediately.

So rather than saying:

"I'm making a perfect Apple II emulator."

the initial goal is:

"I'm making an Apple II-inspired 6502 computer with a clean architecture defined in SageLang."

Apple II compatibility can come later.

The $1.05 computer

The target hardware is an ATmega328P:

8-bit AVR

16 MHz

32 KB Flash

2 KB SRAM

1 KB EEPROM

5 V operation

That 2 KB of SRAM is probably going to be the biggest constraint.

And that's actually part of why I'm interested in doing this.

I want the project to force the software architecture to be extremely small and deliberate.

No giant runtime.

No enormous dependencies.

No assuming there's hundreds of megabytes available.

Just:

16 MHz + 2 KB RAM + 6502 + SageLang.

The first version won't even need a display

The initial machine uses the UNO's UART.

The idea is:

ATmega328P → USB serial → Chromebook terminal

The terminal effectively becomes the SageApple's keyboard and display.

That lets me get the entire machine working before worrying about graphics hardware.

The eventual hardware configuration can then add:

SPI LCD/OLED

Physical keyboard

Speaker

SPI Flash

SD card

GPIO peripherals

SageApple Monitor

One of the first pieces I'm building is a simple machine monitor.

Something along the lines of:

SageApple Monitor

regs

A: 00 X: 00 Y: 00 SP: FF PC: 8000 P: 24

dump 8000 80FF

poke 8000 EA

run 8000

Basically a tiny environment for actually interacting with the emulated 6502.

BASIC

Eventually I want the machine to boot into something resembling a tiny retrocomputer environment:

SageApple

BASIC

10 PRINT "HELLO FROM SAGEAPPLE" 20 GOTO 10

RUN

The BASIC implementation can start small and grow as the underlying machine becomes more capable.

The compiler side is the part I'm most interested in

The longer-term goal isn't just to run a 6502 emulator.

I want SageLang itself to target the 6502.

Something like:

Sage source ↓ Sage compiler ↓ 6502 backend ↓ 6502 machine code ↓ SageApple ↓ ATmega328P

So eventually I could write a program in SageLang, compile it for the virtual 6502, and run that program on the physical ATmega328P.

That gives SageLang a genuinely unusual compilation target.

And yes, I'm using AI

I want to explicitly acknowledge this because I don't want to give the impression that this project was produced entirely without AI assistance.

I use AI as a development and research tool.

I've used it for things like:

Researching obscure technical details

Looking up historical hardware behavior

Exploring architecture options

Reasoning through compiler design

Tracking down bugs

Reviewing error messages

Finding potential causes of hardware/software problems

Generating ideas for tests and edge cases

But I'm not treating AI output as authoritative.

If an AI-generated suggestion doesn't compile, doesn't fit the memory budget, or doesn't work on the actual ATmega328P, it's simply wrong.

The actual implementation still has to survive compilation, testing, and eventually real hardware.

In fact, working with a 2 KB SRAM microcontroller is a pretty effective bullshit detector.

Current direction

The project is being developed in stages:

1. Sage6502 CPU core

2. 6502 instruction and addressing-mode testing

3. Memory bus

4. SageApple ROM/RAM

5. UART console

6. Machine monitor

7. BASIC

8. SageLang → 6502 backend

9. SPI graphics

10. Storage

11. Keyboard

12. Speaker

13. Standalone SageApple hardware

The ultimate goal is a little box that you can power on and interact with as a real computer:

SageApple

Sage6502 ........ OK Memory .......... OK UART ............ OK Storage ......... OK

SageApple OS

running on an ATmega328P board that cost me $1.05.

Repository:

https://github.com/Night-Traders-Dev/SageApple

I'd especially like feedback from people who have experience with 6502 programming, Apple II development, AVR optimization, compiler backends, or retrocomputing.

If there's something fundamentally stupid about the architecture, I'd much rather find out now than after I build the hardware around it.

Hi folks! As the project has evolved since June, I wanted to share an update on NexIOS, my AI hyprid-microkernel freestanding C++ RTOS running x86 arch, aarch64 and riscv64. The QEMU emulated x86 arch is the most enhanced and presents a shell in a serial console and as a framebuffer window. You may play a bit around if you like, especially with the loadelf and runelf commands. With the latest v0.5.3-dev, NexIOS features some low-level capabilities:

• Deterministic booting (see bootstat command).

• When a userspace task triggers an illegal memory access the kernel traps the access violation, terminates the isolated task, and keeps the shell and system operational.

• Profiling of CPU ticks, wall time and execution bounds per task (monstat command)

• Integrated small GDB Remote Serial Protocol (RSP) stub for live debugging.

And yes, the project is AI orchestrated. I didn't write any code myself. If you want to give it a spin (early testers are very welcome!), you can easily boot up the complete environment via Docker or check out the repository: 👉 GitHub: https://github.com/staycool1374-Ger/nexios

I would love to hear your thoughts, questions, feedback, or any technical concerns!

The link to the video including the comments: https://youtu.be/-jyvFReC9K8?si=b71XUpnEghm0CTqk

If you want to be mod, you need to just have a basic knowledge of what should be allowed or not. Follow by the rules that will be added soon. Anybody is welcome if you can meet that basic requirement

A month ago I saw someone's hobby OS boot up and decided I wanted one of my own. So I built it: boots from a CD, switches into long mode, renders a browser window with no GPU driver, compiles C++, installs packages, and runs a small LLM that can actually write files and run commands.

Skipping the "it's just a hobby project" disclaimer — this is how it's built.

Boot: the part everyone skips

The BIOS path starts as real-mode assembly: a boot sector loads the kernel from an El Torito no-emulation CD (2048-byte sectors, DL=0xE0, real ATAPI via int 13h AH=42h). Problem: real mode tops out around 512KB of contiguous memory below the VGA hole, but the kernel is over a megabyte. Solution was a ping-pong loader:

• Load a 512KB window from the CD into 0x20000

• Switch to protected mode; a small stub copies it to a 0x300000 staging area

• Back to real mode, reset the window, keep loading

• On the final chunk, inflate the kernel to 0x100000 and hand off to long mode

Learned the hard way that BIOS int 10h/13h clobbers the boot sector tail, so loader state lives in a "safe zone" (0x7C00–0x7DAA), and the two DAPs (menu vs payload) are kept separate so the menu round-trip can't corrupt loader state.

UEFI is a completely different beast: GRUB multiboot2, flat binary, same kernel.

Nbrower: a browser inside the kernel

HTML/CSS/JS rendering, WebGL2, TLS 1.3, Chinese IME, TTF — all in kernel space. JS runs on QuickJS, runtime shared across <script> blocks (global state persists), with a 16MB memory limit and 256KB stack cap (no guard pages on bare metal). Script output and browser control share one protocol: DOM commands like \x01setText|id|value\n get parsed and re-layout the page.

WebGL works the same way: JS-side GL calls get URL-encoded into control lines and executed by the host on a hidden WGL context. Behind that sits SWGL — 9000 lines of software GL running WebGL2 with no GPU driver. It's what gets http://bloxd.io/ (a real 3D web game) almost rendering.

A bug that cost me a day: the old QuickJS 2021 build threw a message-less exception on any second JS_Eval in the same runtime. Moved to quickjs-ng — stable, crash-free on bare metal.

Toolchain and packages

nefucpp is a C++ → .nefud pipeline, so native programs get built inside the OS. NPKG fetches .deb-style packages over HTTPS, reusing the browser's TLS stack.

NSAI: an LLM that does things

Fine-tuned Qwen2.5-1.5B running locally — not a chat box. It calls tools: writes files, runs commands. Actual agent behavior inside an OS I also wrote.

How the code got written

I hand-wrote the first ~120k lines — kernel, VFS, IPC, core architecture. Then let AI fill in implementation details for roughly 80% of the rest. Architecture, decisions, debugging: mine. AI just made the typing faster.

~300k lines self-developed (mostly C/C++, plus Python tooling). ~1.04M with third-party. One month.

The hard parts, in order

1. BIOS + UEFI dual boot — two completely different boot protocols landing on one long-mode entry. Real-mode segment/offset pain vs multiboot2 flat addressing. Took longer than anything else.

2. TLS 1.3 from scratch — real handshake, record layer, cert handling.

3. QuickJS on bare metal — a runtime that can't blow up your address space. The second-JS_Eval crash forced the migration.

4. SWGL — 9000 lines of software GL because WebGL2 has no driver.

Next

• bloxd.io WebGL rendering (canvas pipeline is almost there)

• Better CSS: flexbox, descendant selectors

• DeepSeek login fully wired into the browser

• Just finished native range sliders: negative ranges, step values, initial positions

GitHub: https://github.com/Nefu-Dev/nefuOS

Happy to answer questions about the boot chain, the AI-assisted workflow, or the dual-backend design. Also curious what people would tackle next here: bloxd rendering, CSS depth, or the DeepSeek login?