ML Code Generation Research / Recreating Aapo's original Habbo Architecture v2

[emansom]

Long read, might want to get some coffee.

Continuing on some ramblings here, I was wrong; it seems we are already at the stage in the development cycle where Claude Code can be used without relying on the cloud, and without being vendor locked-in to some "AI" company charging one thru the nose for "tokens". I hope it remains this way, and I hope the ML landscape and hardware improves to a point where people like us can start training models based on personal knowledgebases. ^{_{(without it requiring a datacenter, nor ~60 GW)}} That would be true independence, true open source/libre/free ML.

Unless that's already a thing too? Let me know. I've been out of the loop.

I think with the help of Claude Code ^{_{(either the cloud version, or self-hosted on single machine or many machine appliances)}}, it becomes attainable to get a real proper ^{_{(and improved)}} re-implementation of Aapo's original design from this paper (Habbo Architecture v2).

It has been attempted before, but never finished. At that time there were no force multipliers like Claude Code available ^{_{(okay, Indian slaves maybe, using MTurk lol)}}, so it would've been a very huge undertaking which most ^{_{(including me)}} wouldn't commit to. Quackster did for this project, which is astonishable and commendable.

Now these force multipliers do exist, and the context window of Claude Code seems large enough for it to grasp higher level concepts to where it can write effective code for a many-services many-node/machine Habbo server implementation.

But before one starts burning time and consume energy for nothing, it should be given the best chance and ability to comprehend the task. I think the following strategy will work:

Planning phase

• Create a monorepo

• Add protocol and research detail
  Use Pandoc to convert between different formats to Markdown
  Relevant files from here as Markdown ^{_{(thanks love, I guess)}}

  • FUSE-Server-Technology.pdf (helps establishing core concepts like virtual spaces)
  • Ahvenlampi_coss.pdf (some implementation details, mostly irrelevant old crap but maybe helps building relevant context)
  • xabbo/common (multiple parsers for protocol logic)
  • aromaa/Skylight.Protocol

  Puomi Wiki

  Relevant RaGEZONE topics as Markdown, Nillus his packet explainer, some posts from Moogkip etc.
  Feed it enough knowledge about Aaron to despise him
  Protocol logic from emulators and other tooling read by Claude digested to Markdown
  Reactor pattern from Woodpecker and Thor 2.0 digested by Claude to Markdown

• Add repositories as submodule in a repos folder, to aid in building context

  • Quackster/habbo_src and/or branw/habbo-shockwave-client-sources
  • xnumad/HabboSwfOpenSource
  • Quackster/Waldkorn or Quackster/Roseau?
  • Thor 2.0 "Stockholm" by JoeH
  • Quackster/Kepler
  • Quackster/Havana
  • habboarchive/Snowlight
  • habbod2/OpenHABBO (last R63A emulator by Nillus)
  • Arcturus fork on Krews?
  • aromaa/Skylight3 (well written functional multi-release server)
  • Any other emulators worth the context cost?

  Once sufficient complete emulators repos added, let Claude Code digest the important game logic loops to Markdown text, seperated by Reactor which should roughly equal the client CCT module seperation.

• Add Claude Code instructions/skills/commands to that monorepo.
  To interpret those Markdown files to aid in the implementation
  Along with instructions in the README on how to execute the Claude Code commands
  Implementation details meaning communication protocol details, game logic loops and documentation on implementing game servers using .NET Orleans

Revision Phase

• Execute the Claude Code commands generated to extract the game features to a Markdown

• At this point, if all game features are properly documented; we can clean the repo up and delete all sources to lower context cost.

• Ask Claude Code to generate and save files in the repo containing detailed written plans rendered to Markdown, plans to implement Orleans services, one per game feature in the client with the game logic from the previous generated definition file.

Execution Phase

• Clean up repo again, only leaving the Markdown files with the detailed plans on how to implement each per game feature Orleans service.

• Ask Claude to execute each plan, then clear context and continue with the next plan.

• Profit???

---

Heavily simplified ofcourse, but in theory this should work. In practice, we'll see. I'm configuring Ollama to use my 9070 XT locally for Claude Code right now.

[emansom]

@Webbanditten you got some GPUs? 👉👈🥺

[Webbanditten]

I got a 3090. The way I'd approach this is probably use something like https://github.com/gsd-build/get-shit-done have it plan put the entire thing as you mentioned. Obviously even then the output of the AI may be a bit iffy.

I don't have a current spending cap on AI usage.

[Webbanditten]

Maybe add me on Discord and we can give it a run?

[emansom]

Maybe add me on Discord and we can give it a run?

@Webbanditten I don't use Discord anymore, such a wasteful time-sink. And its either some power-trip, a cult or a dead server. No valuable conversation or knowledge to be had anywhere. Contributing code and AasC-like things seems a better use of my and everyone else their time.

I got a 3090.

8GB more VRAM (16GB on my 9070 XT vs 24GB on your 3090), hm. Maybe qwen3-coder:30b would run.

I do have 96GB of DDR5 system memory, I can give that a try. Runtime/speed doesn't matter much, as long as the responses and actions are of good quality, consistent and reliable.

Would be interesting if Ollama supports some way of tiered compute and memory, e.g. L1 TPU+VRAM, L2 GPU+RAM, L3 CPU+RAM, L4 CPU+SSD. Maybe I can configure such a thing with vLLM. Unsure, need to research more.

Do you have a local ML setup? What do you run? vLLM or Ollama?

I don't have a current spending cap on AI usage.

I wouldn't recommend wasting cloud ML tokens on this, it's not worth sinking more than $20/mo into this. Especially not when it can be done locally.

The way I'd approach this is probably use something like https://github.com/gsd-build/get-shit-done have it plan put the entire thing as you mentioned. Obviously even then the output of the AI may be a bit iffy.

I have been using the plan mode in Claude Code, similar to that. And it produces very good quality with the appropriate context and explanations so far. Quality of output will vary per model, like you mentioned. GSD looks very interesting! That could definitely be a time (and context) saver! Do you use it? And how?

[emansom]

Furthermore, I think it's possible to extend the lower quality models usefulness by using MCPs appropriately; e.g. a MCP for browsing documentation about a programming language, framework, library etc. extending its "brain"

.. a MCP to instrument programming languages, invoke Shockky, read Lingo etc.

[Quackster]

This can be your own project. Kepler isn't going to follow this architecture. Kepler is very stable and there's no reason why this should change.

I would welcome it in a new project, but I am busy with my own hobbies.

[emansom]

Yeah wasn't really meant as Kepler centric, more the larger scope of oldskool Habbo Emulators in general. Just needed a place to brainstorm.

[Quackster]

You're welcome to use forum.oldskooler.org :)

[emansom]

Vulkan based acceleration in Ollama is working ✅
No idea what token/s it's hitting with gpt-oss:20b but seems pretty responsive, so good enough
Does crash randomly in the middle of some outputs though lol, probably need to try TheRock plus/and/or ZLUDA

(Update: no it's because Claude Code isn't really designed to be used with other models, OpenCode works fine)

.. also gotta find a way to limit the GPU wattage during compute lol, can't have it shooting up to 300W all the time. Electricity expensive here 😔

(Update: use LACT, set Power Profile Mode to POWER_SAVING and Power Usage Limit to ~30% lower)

[emansom]

Okay some more research, learned some things. Will move this discussions and write this up somewhere else later, for now just need to brain dump somewhere before I lose track of these thoughts.

Other relevant discussions/issues/links:

• Tutorial: Offline Agentic coding with llama-server ggml-org/llama.cpp#14758
• What is the best Modelfile Template to use on local ollama models anomalyco/opencode#10824
• OpenCode sends tools (and Jinja tool template) to llama.cpp results in 500 error unless --jinja; with --jinja, template crashes (reject filter) anomalyco/opencode#1890
• https://github.com/akitaonrails/qwen3-dev
• https://simonwillison.net/2025/Oct/7/vibe-engineering/
• https://github.com/loganthorneloe/local-models
• https://cefboud.com/posts/coding-agents-internals-opencode-deepdive/
• https://arxiv.org/html/2405.04324v1
• https://www.i-programmer.info/news/105-artificial-intelligence/18435-opencode-the-claude-code-alternative-.html
• https://venturebeat.com/ai/ibms-open-source-granite-4-0-nano-ai-models-are-small-enough-to-run-locally
• https://gist.github.com/rstacruz/946d02757525c9a0f49b25e316fbe715
• https://gist.github.com/johnlindquist/0adf1032b4e84942f3e1050aba3c5e4a
• https://opencode.ai/docs/ecosystem/
• https://gist.github.com/gc-victor/1d3eeb46ddfda5257c08744972e0fc4c
• https://dev.to/chand1012/the-best-way-to-do-agentic-development-in-2026-14mn
• https://www.reddit.com/r/ClaudeAI/comments/1r4tk3u/there_are_28_official_claude_code_plugins_most/

---

Observations so far:

• Ollama (and/or llama.cpp backend) Vulkan support when run on AMDGPU kernel driver+RADV Mesa Vulkan implementation, will automatically use regular host memory when graphics memory runs out. This means that when system memory is adequate, large 70B models can run. Albeit slowly, but speed does not matter in this usecase, quality does!

• Qwen3-Coder 30B performs pretty good with tasks, as did Qwen2.5-Coder 14B. Did not test 70B or bigger yet, as I don't have the storage space yet.

• Using OpenCode instead of Claude Code was way simpler to configure, and has special logic internally to support more models (like Qwen).

• OpenCode really starts to shine when combining it with their plugin system to built up state of a project, similar to the GSD project mentioned above by @Webbanditten.

  • https://github.com/joshuadavidthomas/opencode-agent-memory
    • https://docs.letta.com/guides/core-concepts/memory/memory-blocks
  • https://github.com/joshuadavidthomas/opencode-agent-skills
  • https://github.com/awesome-opencode/awesome-opencode
  • https://github.com/obra/superpowers

• llama.cpp has support for VirtGPU, allowing usage in QEMU/libvirt microVMs. Combining this with e.g. Packer, SaltStack and some custom RPM definition files, this would allow for a complete set-and-forget configurable environment for all the ML tooling necessary to automate writing the code. I can even see it functioning inside a GitLab runner on a self-hosted GitLab.

• Quantization and Flash Attention really hurt the quality of output from the models, so while it keeps memory usage down; it seems to a non-viable optimization for high quality code results.

• The models make mistakes. When instructed to always test the changes it makes using type checkers and running both unit and end-to-end code tests, they can correct these mistakes before introducing faulty code. This requires the project to have proper testing in place.

[emansom]

@Webbanditten How much dedotated WAM do you have? 👉👈🥺
I have 96GB DDR5 + 16GB GDDR6

LLM leaderboards

List of models worth trying:
glm-4.7-flash:bf16
gpt-oss:120b
qwen2.5-coder:32b
devstral-2:123b
qwen3-coder-next:q8_0
qwen3-coder:480b

Probably qwen3-coder:480b with a context of 1 million tokens will perform the best, but one'd need atleast like 512GB of RAM lol..

---

granite-code:34b from IBM also looks interesting, as does granite4 in architect mode

[emansom]

I'm really intrigued by the Granite Code model from IBM, and the fact that it's very open, well researched, documented and reproducible. I feel like its usefulness can be very much improved by giving it access to MCPs and tools using OpenCode. Something like this.

And the best part: it fits entirely in 16GB of VRAM, even with a 125K context.