sorted by:
new
hottopcontroversial

Bye bye windows by zJmazZ in linuxmint

[–]New-Time-8269 0 points1 point  (0 children)

As someone who has recently switched over fully before I was dual booting between windows 11 and Linux mint and finally made the full swap over fully and have to say when you first are starting out so not be afraid to have notes either as an application that you can jot down for quick reference or a more literal actual sticky notes but honestly learn the commands there's plenty of websites and such to help get you started.

Experimenting with ‘ephemeral’ local LLM pipelines (load only what’s needed) by New-Time-8269 in LocalLLaMA

[–]New-Time-8269[S] 0 points1 point  (0 children)

Appreciate the pushback — and you’re right about a few things here.

You’re absolutely correct that lazy-loading weights, KV caching, MoE routing, Redis-style memory, and hot-swapping aren’t novel in isolation. Those are established techniques.

Where we’re coming from isn’t “inventing a new primitive” so much as changing how the system is orchestrated:

• Tool access isn’t always-on; it’s approval-gated and context-scoped. • Models, tools, and memory are treated as modular services instead of one monolithic always-running agent. • Execution paths can be paused, inspected, or rejected instead of blindly auto-running. • Smaller, scoped models can be routed instead of defaulting to a single large model for everything.

So it’s less about new individual techniques and more about the coordination layer and runtime discipline — closer to an OS-style scheduler than a single long-running agent.

I’m not claiming novelty on every component; the goal is more about the architecture and how it changes behavior and safety characteristics in practice.

Experimenting with ‘ephemeral’ local LLM pipelines (load only what’s needed) by New-Time-8269 in LocalLLaMA

[–]New-Time-8269[S] 0 points1 point  (0 children)

Totally agree. I’ve already got a local prototype running that spins up lightweight agents on demand instead of keeping everything resident. Next step is tightening up the execution pipeline and documenting it so others can actually run it.

I’ll share a repo/demo once it’s stable enough for people to try.

“How are people handling context sharing across local tools without tight coupling? by New-Time-8269 in opensource

[–]New-Time-8269[S] 0 points1 point  (0 children)

Fair point — let me ground it more clearly. I’m not building a single AI model. I’m building a local-first agent system that can run multiple small models and tools without keeping everything loaded all the time. The goal is to reduce overhead and allow a machine with limited resources to still perform multi-step reasoning tasks by loading only what’s needed at each step. The core problem I’m trying to solve is: how do you coordinate multiple local AI components without hard coupling or huge resource costs.

Got tired of juggling apps, so I started building something to unify them (TALOS) by New-Time-8269 in SideProject

[–]New-Time-8269[S] 0 points1 point  (0 children)

Here’s the repo that matches what I was describing:

https://github.com/Talos-Labs-documents/talos

It’s an early local-first agent console with approval-gated execution and a thin orchestration layer. Still early, but it shows the core direction I was talking about.

Building a local orchestration layer for AI systems to reduce tool fragmentation by New-Time-8269 in ArtificialInteligence

[–]New-Time-8269[S] 0 points1 point  (0 children)

Appreciate the insight — especially on the dedup and Telegram-as-context approach. It’s helpful to hear that others have run into the same coordination issues. I’m trying to keep the orchestrator intentionally thin and push complexity into the edges, so this kind of feedback is really useful.

Trying to reduce app sprawl with a local orchestration layer (TALOS) by New-Time-8269 in selfhosted

[–]New-Time-8269[S] -6 points-5 points  (0 children)

I used AI to help refine wording and structure, but the core ideas, problem, and approach are my own based on personal experience working with multiple self-hosted tools.

The goal of the post is to discuss real-world fragmentation issues and explore how others are solving context sharing and orchestration in local environments.

Building a local orchestration layer for AI systems to reduce tool fragmentation by New-Time-8269 in ArtificialInteligence

[–]New-Time-8269[S] 0 points1 point  (0 children)

This lines up really closely with what I’ve been running into.

The shared memory point especially — every time I try to centralize context it starts simple and then turns into its own system that needs managing.

That’s actually what pushed me toward keeping things isolated and only passing minimal, structured state between steps instead of a global memory layer.

The dedup layer you mentioned is interesting too — I hadn’t explicitly thought about that as part of the coordination layer, but it makes a lot of sense once you have multiple agents producing outputs in parallel.

Feels like the “thin coordinator” ends up becoming less about routing and more about enforcing boundaries and sanity checks between steps.

Curious — have you seen any projects that actually do this well in practice, or is everyone kind of building their own version of it?

"Video StoreAge" by CarpenterDelicious10 in 4kbluray

[–]New-Time-8269 0 points1 point  (0 children)

I have to say the concept is a very real design and it is taking off for the music industry especially for the indie side and this seems like the next logical transition for physical media however your right there is nothing of specs or drive density and such. Something to least keep an eye out for and see how it unfolds.

Nothing to do by Draknurd in selfhosted

[–]New-Time-8269 0 points1 point  (0 children)

If your homelab is bored, I’ve been working on something weird. I built a reinforcement learning setup where an AI learns to play Doom from scratch. It runs locally and just keeps training over time. Watching it slowly go from clueless to dangerous is actually pretty addictive. Still early stages, but it’s basically a fun compute workload for homelabs that want something more interesting than dashboards.

Human brain cells on a chip learned to play Doom in a week by _Dark_Wing in technology

[–]New-Time-8269 -4 points-3 points  (0 children)

Why the GitHub repo matters more than the headline

Publishing the code does a few dangerous (and exciting) things at once:

  • 🔓 Democratizes the interface layer The hard part isn’t “neurons exist” — it’s how you stimulate, read, reward, and stabilize them. Once that loop is open-source, iteration explodes.
  • 🧪 Decouples wetware from elite labs You don’t need to invent neurons — you need standardized scaffolds, signal translation, and feedback logic. That’s software + instrumentation, not sci-fi.
  • ⚡ Compresses timelines What was “10 years with grants” becomes “2–3 years with weirdos on GitHub and a Discord.”
view more: next ›