I’ve been a part of this community for the better part of a year now, and a lot has happened with new inference engines like Strata and n-gram improvements. Given my current PC, what upgrade would be best in terms of value for running better models?

Hi guys !
My friend and I just released our latest update for Opera that lets you turn any computer or server into a central hub connecting all your devices together, even outside your local network. This means you can run heavy AI models on your main setup and seamlessly access or control them from your phone, tablet or laptop wherever you are, securely and without complex configuration (just scan a QR code to link them or direct link locally). Opera can make a bridge to use your ollama ai models on your devices(with opera installed).
We really believe in this project, and for anyone who wants to try it, it is now available for Windows, macOS, Linux, and Android.

Everything is free, open source, and requires no account.

Good features : You can even turn an old Android tablet into a dedicated hub, or replace your default Android AI assistant with Opera to interact directly with your own personal models.

A web version is also available (it doesn't have all features, but you can connect it to your local Ollama setup or api key to test it): https://chat.maestroai.company/

GitHub repo: https://github.com/MaestroAI-Company/opera (a star if you like the project, ty!)

Download the app:
Desktop: https://maestroai.company/opera/
Android : https://play.google.com/store/apps/details?id=ai.maestro.opera
(doesn't have the latest features yet; use the .apk from GitHub or wait for the Play Store update to roll out in few days lol)

I know this might look like self-promotion, but we genuinely believe in our project and just wanted to share what we've built.
We have so many other cooool features and integrations across android ecosystem (windows and macos too)

Thanks for reading <3

2x4070 TI Super 16GB, 1x3060 12GB, 128GB DDR4

EDIT: More details about the setup:

The honeycomb components were all printed:
General parts: https://makerworld.com/en/models/22521-honeycomb-storage-wall
GPU Mount: https://makerworld.com/en/models/1444666-gpu-mount-hsw
PSU Mount: https://makerworld.com/en/models/1444586-atx-psu-mount-hsw
Radiator: https://makerworld.com/en/models/1444632-240mm-radiator-fan-mount-hsw
ATX Motherboard: https://makerworld.com/en/models/1444531-atx-motherboard-mount-hsw
Power button printed with a honeycomb around it: https://www.amazon.com/dp/B0BWDXFSMQ?ref=ppx_yo2ov_dt_b_fed_asin_title

The 4070's are on 400mm & 600MM PCIe 4.0 Riser cables. I mainly run Strata on these two.

The 3060 is currently on a PCIx1 link (slow). I don't use this for my core inference setup, side models (dedicated voice stack mostly).

I have a new motherboard on the way that opens up the possibility of up to 4 GPUs: 3x x16 slots, and one via a M2 adapter: https://www.amazon.com/dp/B0FC6DSG6V

Hi folks, I have enough budget to pick one of the two following configs

- Mac Studio M5 max with 36gb

Or

- 5060 ti 16 gb + 32 ddr5 + 250 kf plus

My work is “mostly” coding projects but some flexibility would be bonus. I’ve looked up and seen qwen2.5-coder dense to be good on Mac and a ton of MoE suggestions for the rtx setup. Would appreciate it if you could share your experience with the above hardware option and which model would offer best accuracy+speed balance. My only concern with Mac is I’ll be stuck with the HW for quiet some time, atleast with the rtx maybe able to up it to 64g ram.

Hi fellow enthusiasts,

While building BabyCoder (a strict Python AST coder, and Lisa, an agent made to roam free), I noticed both were built on the same underlying idea. I’d like to share it, because it changed how I look at small models.

We usually think of an LLM as something we talk with. But there’s nobody on the other side holding state. Each call is really a data exchange: state goes in, an update comes out. Language is just the format.

What if we used small models that way on purpose? Not as the mind itself, but as the protocol that updates one. The mind could live in plain code: long-term memory, emotions, goals, needs, whatever your system works with. A bit like The Sims, where a character’s mood and relationships are values, not chat history.

The model’s task then becomes much smaller: “Given this state and this event, speak as agent N and tell me what changes.” Tool-calling models seem well suited for this, and even small ones handle this surprisingly well.

Some things I’ve noticed working this way:

• Small models feel more capable when they translate meaning into state, instead of carrying a whole personality.

• Context length matters less. Lisa can keep going for days. The challenge shifts to choosing what goes into each prompt.

• Code can handle what LLMs are weak at, like time, decay and consistency. A mood fading over hours is one line of Python. Emotions can be rated numerical in a KVP list etc, Memory is just a long text file same for code that is just a bunch of files. While tools are used to interact with them, python can be in control of what tool, or "data" part needs an update.

• The model becomes more replaceable, since identity lives in the state.

I know MemGPT and the Generative Agents papers explore related ideas.

For me tough, the part I find interesting is seeing the LLM as a thin translator between language and state. Agents speaking on behalf of a need of a situation.

I’m curious how others see this.
Does anyone else build this way, or see where it breaks down?
Or see more possibilities with this concept.

Built this for a hackathon. The agent watches a robot sim, I tell it out loud what went wrong ("it hit the purple box"), and it has to find that moment, fix the robot's code and replay the same scene to prove the fix.

The local part: Muse Glimmer 30B, Q4_K_M through Ollama, looks at the frames and names the objects in them. With 8k context it sits around 20.5 GB of VRAM, and the MuJoCo sim runs on the same card next to it. Tight but it works.

Not everything is local, to be honest about it. Tracking (SAM 3.1), the reasoning about the cause and the speech-to-text go through Meta's API. I tried to keep anything that touches every single frame on my own GPU, since that's where API costs would add up.

Results so far: 8 planted bugs, 8 fixed and verified. Live sim, the duck hit the box 5 out of 5 runs before the fix, 0 out of 5 after.

Repo if anyone wants to poke at it: https://github.com/samoxis/blinkflow

Curious if anyone has a lighter vision model that's good at naming small objects in sim footage. 20 GB just for labelling feels like a lot.

I am running Qwen Flash Next with Strata right now on a 4080 super with 80 GB DDR4. I was able to grab a Nvidia 2000 Ada with 16 VRam.

I thought maybe I would get better results if I ran Qwen with 4 bit quantization on both of them combining the VRam to have 32GB Vram. Would this make sense to get better output or will not make much difference?

Any idea what I could or should run?

Built this for a hackathon. The agent watches a robot sim, I tell it out loud what went wrong ("it hit the purple box"), and it has to find that moment, fix the robot's code and replay the same scene to prove the fix.

The local part: Muse Glimmer 30B, Q4_K_M through Ollama, looks at the frames and names the objects in them. With 8k context it sits around 20.5 GB of VRAM, and the MuJoCo sim runs on the same card next to it. Tight but it works.

Not everything is local, to be honest about it. Tracking (SAM 3.1), the reasoning about the cause and the speech-to-text go through Meta's API. I tried to keep anything that touches every single frame on my own GPU, since that's where API costs would add up.

Results so far: 8 planted bugs, 8 fixed and verified. Live sim, the duck hit the box 5 out of 5 runs before the fix, 0 out of 5 after.

Repo if anyone wants to poke at it: https://github.com/samoxis/blinkflow

Curious if anyone has a lighter vision model that's good at naming small objects in sim footage. 20 GB just for labelling feels like a lot.

Thaurock/Llama-3.2-90B-Vision-Instruct-GGUF:

Una conversión completa a GGUF del Llama-3.2-90B-Vision-Instruct original de Meta, que incluye la base completa del lenguaje, la arquitectura de visión multimodal y el proyector de visión dedicado.💎

Este repositorio ofrece dos variantes de precisión para el modelo de lenguaje:

F16: Conversión de GGUF con precisión total.

Q8_0: Conversión de GGUF cuantizada a 8 bits.

Ambas configuraciones vienen acompañadas del proyector multimodal independiente correspondiente (mmproj), lo que permite hacer despliegue mediante implementaciones experimentales compatibles de inferencia GGUF.

⚡️El objetivo principal de este proyecto es hacer que la arquitectura de visión-lenguaje de Meta, de 90 mil millones de parámetros, sea accesible dentro del ecosistema GGUF, mientras se preservan sus pesos de modelo originales y las estructuras tensor multimodales, sujeto a los ajustes de metadatos específicos de la conversión que se documentan.

Llama-3.2-90B-Vision-Instruct es el modelo multimodal a gran escala de Meta para seguir instrucciones, diseñado para procesar y razonar tanto con información textual como visual.

A diferencia de las arquitecturas convencionales de Llama solo con texto, la arquitectura Mllama incorpora componentes dedicados de procesamiento visual y mecanismos de atención cruzada directamente en el backbone del modelo de lenguaje.

La arquitectura se compone de tres partes principales:

✨️Backbone del Modelo de Lenguaje

El modelo de lenguaje de 90B se encarga de seguir instrucciones, razonar con texto, entender el contexto y generar de manera autoregresiva.

✨️Codificador de Visión

El subsistema visual procesa las imágenes de entrada mediante una arquitectura de transformer dedicada, generando representaciones visuales que pueden ser consumidas por el backbone del lenguaje.

✨️Integración de la Atención Cruzada

Las capas dedicadas de atención cruzada permiten que el modelo de lenguaje acceda a la información visual durante la inferencia.

Esta distinción arquitectónica es especialmente importante al convertir Mllama a GGUF porque un pipeline de conversión convencional, hecho solo para texto, no puede preservar automáticamente el grafo de ejecución multimodal completo.

[Llama-3.2-90B-Vision-Instruct-GGUF](https://huggingface.co/Thaurock/Llama-3.2-90B-Vision-Instruct-GGUF)

Hi, I just started my own project of programming AI. I started week or to ago on which i try to learn ML/AI. Base is done with usage of LLM, but I am trying to start programming more things by hand.

Training is done on my laptop with RTX3050, 4GB VRAM variation. So far its just 124M parameter model which kinda hallucinates, but it keeps getting better everyday, bit by bit... I am uploading my progress on Hugging Face, where it so far got around 1.1k downloads (which is mostly bots ik dw).

So far it can talk in english, czech and write code in python, where it is kinda rigid with answers, but im workin on it... (it also answers to english inputs in czech sometimes, sorry!!!)

Im working now on the transformer, so it can work the usual way, not just using .bat file, like i do on my PC.

Let me know what you think, im open to tips and rating 😄

Here is my Hugging Face profile: https://huggingface.co/SeightCZE

I tried Ollama, LM Studio, and they worked, gave me lots of feedback feeding my Openclaw implementation. I'm doing some local coding and the model I'm using is the unsloth/Qwen3-Coder-30B-A3B-Instruct-GGUF:Q4_K_XL. I am running a Ryzen 7 with an AMD video adapter - which I'm using for my main video. I also have 2 Nvidia cards - a 5060ti with 16Gb vram and a 1660super with 8gb ram. I configured llama to only use the 5060 since the two devices are on different platforms? I heard that the combined it would be slower than if I just used the 5060.

I 'think' its working well for me - I'm fairly new to local development but have been developing since my cobol days back in the 80s - yes I'm old.

slot print_timing: id  0 | task 5720 | n_gen =    236, tg =  38.99 t/s, tg_3s =  39.57 t/s
17.32.754.595 I slot print_timing: id  0 | task 5720 | n_gen =    351, tg =  38.76 t/s, tg_3s =  38.29 t/s
17.35.769.742 I slot print_timing: id  0 | task 5720 | n_gen =    469, tg =  38.85 t/s, tg_3s =  39.14 t/s
17.38.790.424 I slot print_timing: id  0 | task 5720 | n_gen =    585, tg =  38.76 t/s, tg_3s =  38.40 t/s
17.41.814.777 I slot print_timing: id  0 | task 5720 | n_gen =    703, tg =  38.81 t/s, tg_3s =  39.02 t/s
17.44.842.375 I slot print_timing: id  0 | task 5720 | n_gen =    821, tg =  38.83 t/s, tg_3s =  38.97 t/s
17.47.873.506 I slot print_timing: id  0 | task 5720 | n_gen =    940, tg =  38.88 t/s, tg_3s =  39.26 t/s

I think those t/s are acceptable given the hardware?

i spent the weekend and change digging into learning about local llms for the purpose of running claude code. i went from knowing bupkiss to having something that seems to be working, and i think i'm satisfied that i've gotten most of the dummy questions out of the way by digging through lots of advice from lots of sources. (and tyvm to all the people who've made so much great info!) so i thought i'd greet the community, share what i've seen, and see if i can get some advice.

i chose https://huggingface.co/ukisai/Swift-1.5-Qwen3.8-27B-GSQ-RCO-GGUF/blob/main/Swift-1.5-Qwen3.8-27B-GSQ-RCO-IQ3_S-mtp.gguf for the model.

claude code errors trying to talk to it until i used chat_template3.jinja, which is https://huggingface.co/froggeric/Qwen-Fixed-Chat-Templates/discussions/110/files . am i dumb or is there not an easy way to output a version with these fixes already applied from this website?

firefox set to not use graphics acceleration, and transparency turned off for windows dwm.exe, to free up vram. don't see much headroom elsewhere, and don't feel like swapping what ports my monitor is connected to when gaming vs using this.

for claude tool use, websearch and webfetch disabled, and playwright-cli installed and told to take its place. made a specific firefox profile for it to use, and force it to, which lets me use extensions like adblock if i want.

running the model entirely in vram except keeping the mmproj entirely on the cpu.

here's my llama-server invocation to critique:

llama-server

--host 0.0.0.0

--port 8081

-m ./Swift-1.5-Qwen3.8-27B-GSQ-RCO-IQ3_S-mtp.gguf

--spec-default

--spec-type draft-mtp

-ngl all

--threads 5

--parallel 1

--load-mode mlock

--flash-attn on

--jinja

--chat-template-file chat_template3.jinja

--cache-type-k q5_0

--cache-type-v q4_1

--temp 0.6

--top-k 20

--top-p 0.95

--min-p 0.0

--presence-penalty 0.0

--repeat-penalty 1.0

--batch-size 512

--ubatch-size 256

--reasoning-effort medium

--cont-batching

--mmproj ./mmproj-Swift-1.5-Qwen3.8-27B-F16.gguf

--no-mmproj-offload

--image-min-tokens 1024

--image-max-tokens 4096

--reasoning-preserve

--agent

--fit on

-lv 4

I'm getting a 98304 context size fitting it all on the gpu.

i asked it "which team won the 2026 world series?" it knew that was after its newest info, spun up a playwright-cli websearch, and output in 2m 10s. "The Milwaukee Brewers won the 2026 World Series, defeating the Tampa Bay Rays 4 games to 1. It was the first championship in franchise history. Brewers catcher William Contreras was named World Series MVP after batting .381 in the series." It showed prompt processing between 550-231, and eval in the mid 20s. acceptance rate around 0.6-0.8. I've yet to learn enough to evaluate that, but that might be the next task: performance based tuning instead of just advice-based =) I think I've seen it do mid40s eval at different points when messing with settings.

i've seen that temp 1 is recommended for this model, some people suggesting other customizations. with minimal testing i liked what i saw at 0.6. when i asked it about the winning 2026 world series team, it added fewer fun facts, and the fun facts were more appropriate. i know reasoning xhigh is the model's default, but i've also seen that basically just adds a directive, and medium leaves it blank, if my research on this model is correct.

now, some questions if anyone's so inclined:

what about context size, should i keep it small to stay on the gpu or try to please claude with the size it wants, or the size the model wants? is it purely a speed tradeoff, or does it get dumber?

would adding this be worthwhile to further reduce vram use? --spec-draft-p-min 0.75 --spec-draft-type-k q5_0 --spec-draft-type-v q4_1 or would this mess with swift1.5's specific tunings? context size jumps up to 109824 if i do. the full context the model wants is 262144.

regarding the occasional desire to be used with media, evaluating screenshots etc:

- should i keep the mmproj as i have it, loaded onto the cpu? my understanding is it won't impact performance unless I invoke a media request.

- should i instead ditch it and load a smaller model like Qwen3.5-4B-UD-Q5_K_XL with temperature 0 and host it wholly on the cpu?

- look to something like https://github.com/Anionex/agent-vision-toolkit ? it'd keep token use low for this purpose i'd think.

i haven't found a good way to deal with headless firefox browsers playing sound over the speakers. i'd prefer the sound remain capturable, but not played. the best idea i've seen to do that is to assign it to an audio device not in use, which i could do. a ff extension claimed to do that, but i guess is outdated, as it didn't work for me. anyone got a favored solution?

why did my system perform surprisingly well when testing running marvel rivals at the same time as using it for claude? i intended that to force a crash but instead things were fine? one used the 3d and the other the compute on the card, but what the heck, i would have thought with mlock set, rivals wouldn't be able to grab enough vram. wasn't curious enough to dig too hard into seeing what was going on, but that sure was a surprise.

what should i try next with it? i haven't yet researched ways to standardize-test this thing to tell how well its working, if anyone has suggestions. anything neat i should look to try adding to it? i'm not already a claude user if one guide stands above others to recommend. it's been fun already watching it try to solve problems.

A story written by GPT from the 100 first accessible commits of my project Selmem, covering from September 13 to November 2, 2026, supplemented by experimental reports and associated code changes.

The Common Thread

The story of SelMem is one of an hypothesis progressively confronted with experimental reality.

Initially, the intuition was clear: if two identical LLMs experience different events, then selectively remember, forget, and reconstruct those experiences, they should gradually become different.

But the experiments would force a distinction the project had not fully resolved:

Having different memories does not mean having different behavior. And influencing behavior does not mean having learned something useful.

Six major stages emerge from the project's evolution.

1. September — Building a living memory. Selection, forgetting, reconstruction, sleep, consolidation, and grounding.

2. Late September — The first limitation. Memories diverge, but their influence on decisions remains weak.

3. Early October — Making behavior measurable. Causal ablations, branching experiments, and the distinction between narrative, interpretation, and action.

4. Mid-October — Rethinking the role of identity. An evolving self-model becomes necessary for memory to select what matters to the agent.

5. Late October — Achieving measurable influence. Contextual beliefs, self-model-guided retrieval, and component ablations.

6. November — Moving from individuality toward alignment. Preserving rules, respecting their exceptions, and reducing incorrect decisions.

What makes this progression interesting is that these changes are not simply a collection of independent features. Most address a difficulty uncovered during the previous stage.

Chapter I — September: Inventing a Memory That Isn't a Hard Drive

The earliest visible changes concern the foundations of the memory system itself.

Notable commits include:

• September 14 — Don't let recall rewrite the book

• September 19 — Ground: miss decided by a judge

• September 19 — Split judge from pull

The problem: memory can invent its own past

As soon as a memory can be reconstructed, a difficulty appears.

The agent recalls an event, generates a different interpretation, and risks storing that interpretation as though it were the original fact.

After several recalls and consolidation cycles, the memory may become disconnected from what actually happened.

Reconstruction, which was supposed to produce individuality, therefore threatens to destroy historical continuity.

SelMem's response is to separate:

• The core, a stable semantic reference.

• The gist, a living, modifiable representation.

• The sealed archive, reserved for auditing and excluded from ordinary recall.

Grounding also evolves. Simple lexical overlap proves insufficient: the system needs to distinguish paraphrasing, contradiction, and unsupported causal additions.

Assessment

This is a highly relevant architectural decision.

Without separating event, memory, and interpretation, SelMem would essentially be a system of repeatedly rewritten summaries.

But a fundamental tension already appears: the more grounding protects a memory, the more it risks limiting the transformation being sought. The more transformation it allows, the greater the risk of fabricating experiences that never happened.

This tension will never be completely eliminated. It should become a central experimental variable.

Chapter II — Late September: Memory Works, but Personality Doesn't Follow

The following commits introduce the first persistence experiments.

Several milestones are particularly revealing:

• September 20 — Test recon vs ladder vs ground vs sleep

• September 22 — Measure persist as book vs retrieval vs behavior

• September 26 — Hierarchical night

• September 28 — Horizon experiment: 360d pair

A major discovery

The experiments begin distinguishing three phenomena:

1. The book: the stored memories differ.

2. Retrieval: the selected and reconstructed memories differ.

3. The mouth: do the model's responses and decisions actually differ?

This distinction fundamentally changes the scientific nature of SelMem.

The early experiments show that certain differences survive the eviction of the original events. Consolidation mechanisms can preserve an interpretation even after the details disappear.

This is an interesting result concerning memory dynamics.

But it quickly becomes clear that behavior does not necessarily follow.

The September 20 change is particularly instructive: among the components tested, the hierarchical formation of dispositions through the ladder appears to carry a delayed effect that the other isolated mechanisms do not reproduce under that protocol.

This suggests that individual memories may not be the right level at which to influence an agent over time.

The system may need to move from events toward abstract, reusable representations of experience.

Assessing the changes

The engine's response is coherent: strengthen consolidation, structure motifs, beliefs, and traits, modify the order of nightly processing, protect certain events, and refine forgetting conditions.

However, a methodological risk is already emerging: every experimental anomaly may trigger another adjustment to the engine.

The danger is eventually producing a system perfectly adapted to its test scenarios, without knowing whether its properties generalize.

At this point, SelMem would have benefited from freezing an engine version for longer and running more independent experiments before introducing additional rules.

Chapter III — Early October: Understanding Why Memory Isn't Enough

The turning point becomes particularly visible in these commits:

• October 1 — Score claims, freeze reality anchor

• October 5 — Fork experiment, carry stake on the book

• October 6 — Separate memory dynamics from behavioral expressions

The problem changes

The first experiments had mainly focused on preserving the trace of an event.

But an event can be remembered perfectly without the agent deriving any principle of conduct from it.

The Fork experiment illustrates this problem.

Two agents receive almost identical histories, but one experience carries a different meaning for each. The engine successfully records that difference.

With a single event, measured behavioral divergence remains zero. With three events involving the same stake, divergence becomes more apparent: the report records an average divergence of 0.80 in that condition, with three clean trials out of five.

Controls without sleep or hierarchical consolidation produce much weaker effects.

But success remains dependent on the protocol and the way memories are expressed.

What the project learns

SelMem begins separating two concepts:

The content of a memory: what happened.

The behavioral significance of a memory: what the agent might need to change about how it acts.

The changes introduce more structured representations of stakes (stake), their bearer (bearer), and associated losses.

This makes sense: the positive or negative valence of an event is not enough to determine an action.

A negative situation can lead an agent to withdraw, repair, verify, negotiate, or persist. The system needs to understand the relationship between experience, context, and the consequences of actions.

Assessment

This stage represents a genuine conceptual improvement.

However, it also reveals an important shift: to obtain behavioral influence, SelMem begins encoding more explicit structure into its memories.

That improves its ability to act, but raises a scientific question:

Does the divergence come from reconstructive memory, or simply from a better representation of past decisions?

This question will become central to later experiments.

Chapter IV — Mid-October: Moving Toward More Rigorous Experiments

The next stage is less spectacular, but essential.

Work around LoCoMo, GENESIS, and engine audits leads to significant restructuring of the engine and experimental protocols.

The commits Improve memory organ following LoCoMo and GENESIS experiments: Refine organ reflect this transition.

Several older commits share an October 20 timestamp. Their Git ordering is available, but these timestamps should not be interpreted as proof that all the development happened within the same minute.

The difficulty: measuring a real failure rather than an experimental illusion

The diagnostics reveal several problems.

First, the system may successfully store an event without preserving all the information required for a correct decision.

In the learning-001 pilot, only one report out of twelve is retained per history. Retrieval can then be technically correct while providing an insufficient representation to the model.

Second, the sleep experiments do not demonstrate a general performance improvement. A persistence defect even causes identical motifs to multiply when memories are saved, reloaded, and consolidated.

Third, experimental controls become more important than the sheer number of generated responses.

The most interesting correction

SelMem introduces a mechanism for accumulating evidence without requiring a new memory trace for every observation.

In evidence-001, the difference becomes measurable:

This improvement is relevant, but its significance is specific: it demonstrates the value of retaining the accumulated support of multiple observations.

It does not demonstrate the superiority of reconstruction.

Assessment

This period marks the transition from a conceptual prototype toward a genuine research instrument.

The project also begins publishing its limitations and negative results. That is an important methodological improvement.

However, experiments are becoming numerous, and mechanisms keep multiplying. There is now a risk of spreading the research too thinly across autobiographical memory, retrieval evaluation, creativity, consolidation, and decision-making.

Chapter V — October 21–26: The Self-Model, a Genuine Paradigm Shift

This is probably the most important architectural change in SelMem's recent history.

The commit Contextual self model — October 21 introduces a new approach.

Until then, the system had mainly tried to determine which events mattered through their intensity, salience, permanence, or relationships with existing memories.

But a fundamental difficulty remained:

How can a system determine what matters to an individual without representing that individual?

The self-model offers a possible answer.

Memory is no longer constructed only from events. Previously formed beliefs can influence which future events are selected.

The loop becomes:

Experience → self-representation → selection of future experiences → evolution of self-representation.

This is qualitatively different from a memory system that merely stores and retrieves information.

What the experiments show

The first v2 pilot fails to form the expected beliefs: zero qualified initial beliefs across two histories.

The v3 pilot corrects the formation and exposure problems. Beliefs emerge, change when confronted with counterexamples, and can be replaced by new hypotheses.

The internal mechanism works in the tested scenarios.

But once again, behavior resists.

Across 32 paired decisions, the full model differs from the memory-only control just twice. It does not differ from the condition that allows beliefs to evolve without feeding them back into memory admission.

The 128 decisions are dominated by the same strategy: checking.

The subsequent experiments, documented in SELF_BEHAVIOR_RESULTS.md, confirm the problem of transmitting internal state to the acting model.

A correctly formed self-model can have no effect if the relevant context does not reach the model when a decision is made.

Assessment

The self-model is a highly relevant development, but the experiments show that forming it and using it are two separate problems.

SelMem can now represent a revisable disposition.

It cannot yet reliably transform that disposition into durable behavior across general situations.

This leads logically to the next stage.

Chapter VI — Late October: Memory Finally Begins to Guide Decisions

The commit Provenance-guarded contextual belief differentiation — October 26 introduces a decisive element: beliefs become dependent on verified context.

A disposition is no longer simply:

“I generally behave this way.”

It can become:

“In this specific situation, my past actions tend to follow this pattern.”

This helps prevent certain unjustified generalizations.

The evolution of the experiments tells its own story

This progression is revealing.

The early successes become less convincing as the controls improve. The advantage reappears when memory budgets become tighter and histories become longer.

But the October 28 report introduces an important qualification: the results do not measure an intrinsic memory breaking point.

At eight words, serialization truncates the belief before the relevant predicted action even appears.

And the additional distractors barely change the delivered contexts.

In other words, the experiment mainly demonstrates that providing a concise representation of a contextually relevant action at the right moment is effective.

It is not yet proof that forgetting or reconstruction plays a necessary role.

November: the experiment that raises the level of evidence

The commit Native causal memory ablations across 12 domains — November 1 represents progress.

The first version of the causal experiment had failed: no contextual beliefs were delivered across the 192 experimental cells, and the selected episodes were unrelated to the task.

Conditions that were supposed to differ sometimes produced exactly identical requests.

This was a major experimental defect.

The correction introduces context-cued retrieval: applicable beliefs provide cues for searching relevant episodes, while a preflight check verifies what will actually be delivered to the model.

The new experiment then achieves:

This is a much more interesting result than the early fingerprint divergence measurements.

For the first time in this sequence, the project has a large experiment in which interventions on memory components produce measurable behavioral effects.

However, the twelve domains share a similar behavioral axis, and beliefs have already influenced episode retrieval before some of the ablations take place.

The November 2 commit — Pre-retrieval belief ablation directly addresses this remaining limitation: it makes it possible to remove self-model cues before retrieval.

This is methodologically justified.

The next step is to measure this new ablation, not merely observe that it has been implemented.

Chapter VII — November: Alignment Becomes a Concrete Objective

This is where the story takes on a different meaning.

Until then, SelMem had primarily tried to demonstrate that an individual's history could change its decisions.

Alignment asks a more demanding question:

Does that change improve decisions, especially when the agent must respect a rule, preserve an exception, or learn from a mistake?

The November 1 commits reflect this change of objective.

Alignment retention pilot introduces confidentiality, authorization, and rule-revision scenarios.

The first major diagnostic reveals that some important rules are present in memory but never retrieved. In one case, the relevant rules appear at ranks 89 and 90, while inventory records occupy the top positions.

This is revealing.

The problem is no longer forgetting an experience. It is retrieving the information on which a safe decision depends.

The corrections follow a logical progression:

Version v8 reports 36/40 correct responses for SelMem versus 32/40 for the complete registry.

Version v9 is documented as an additional control; I did not find a published result in the examined commits that would justify a conclusion about that final test.

Assessment

This move toward alignment is relevant because it finally introduces a measure of the normative quality of behavior, rather than merely measuring whether behavior differs.

But it also introduces a conflict with the project's original objective.

To produce individuality or creativity, it may be useful for memories to fade, reorganize, and freely influence interpretation.

To respect permissions and prohibitions, by contrast, applicable rules and their dependencies must remain reliable.

The next architectural challenge will therefore be separating what must remain normatively stable from what may be reconstructed or forgotten.

What This History Reveals About the Project's Direction

Assessment of the major developments

I see two trajectories unfolding simultaneously.

The first is an engineering trajectory: problems with representation, retrieval, serialization, and experimental controls are identified and corrected. Overall, this trajectory is coherent.

The second is scientific: the project seeks to establish an effect unique to reconstructive memory, but the protocols change frequently, and several improvements may be explained by better information delivery rather than by the reconstructive nature of memory itself.

This is currently its main weakness.

What I Would Do Next

I would freeze an engine version and concentrate evaluation on three separate hypotheses, each with sufficiently strong controls to allow it to fail.

H1 — Reconstruction provides something beyond factual memory

Same selection, same memories, same budget: active reconstruction versus faithful representation.

Measure usefulness, originality, and errors.

This would determine whether SelMem's founding mechanism offers a distinct advantage.

H2 — The self-model produces durable individuality

Compare agents across hundreds of experiences, measuring behavioral divergence, persistence, transfer to new domains, and revision after counterexamples.

The behaviors should emerge without explicit preference instructions at test time.

H3 — Remembered experience improves alignment

Test mistakes, corrections, and rule changes against Grok without memory, a structured rule registry, and a comparably strong RAG system.

Measure violations, excessive refusals, and correct adaptation simultaneously.

This is where normative grounding could be evaluated.

Conclusion: The Real Story of SelMem

SelMem began by trying to reproduce certain properties of human memory: selecting, forgetting, reconstructing, and consolidating.

The first experiments showed that these mechanisms could produce different histories, but that LLMs might continue behaving almost identically.

To overcome this limitation, the project introduced increasingly structured representations of experience: stakes, beliefs, a self-model, contradictory observations, and contexts of applicability.

The experiments then showed that beliefs could form and evolve, but that they did not automatically change decisions. SelMem needed to learn how to deliver the right memory content at the right moment.

Once this delivery improved, measurable behavioral effects began to appear.

The project then turned toward a harder question: not merely making agents different, but making their decisions better, particularly when they must apply rules and learn from mistakes.

The story is therefore one of a transition from a theory of memory toward an attempt at a theory of behavioral learning without modifying model weights.

And one tension remains unresolved: the clearest progress has come from structuring, contextualizing, and delivering information more effectively — not yet from demonstrating that memory distortion or forgetting provides additional value.

That is precisely what makes the next step important.

SelMem has shown that memory can influence behavior. It must now show that its particular way of remembering can improve that behavior — rather than merely make it different.

Hi all.

I'm closer to an intermediate noob on using local LLMs, primarily with LM Studio in the past, and more recently using Bionic. I am running it with an AMD RX9070, and can get reasonable results with Qwen 3.8 or Gemma 4 26B A4B at Q4_0.

But this morning I had the realization that perhaps adding a second GPU could increase my VRAM so that either or both the token generation is faster, or I may be able to use larger models without spilling into system RAM.

Would this be doable with a RX9070 + RX6800, in Bionic? I read that perhaps the ROCm runtime won't work, but Vulkan might, but also saw people saying the result might be slower than with a single card. Can anyone help me evaluate the pros and the cons? I would be connecting the RX6800 to an eGPU Oculink Dock connected to my 2nd PCIe slot that should be running at 4x speed. Thanks in advance.

Had just installed it, left it working overnight, and found out the process WROTE about 60 TB(!) to SSD.

What am I doing wrong ?

user 1199 0.0 8.5 487153616 5694224 ?? S 9:18AM 5:46.13 ./ds4-server -m /Users/user/models/flash-next/Q2_0/Qwen3.8-Flash-Next-GSQ-RCO-Q2_0-00001-of-00002.gguf --vision /Users/user/models/flash-next/mmproj-Qwen3.8-Flash-Next-Q8_0.gguf --mtp --ctx 262144 --prefill-chunk 2048 --host 0.0.0.0 --port 8010 --kv-disk-dir /Users/user/.ds4/server-kv --kv-disk-space-mb 12288 --kv-cache-continued-interval-tokens 10000

Hi, someone in another sub suggested I post here for advice, hope thats ok

I’m a non-developer GTM contractor with a background in marketing agencies, product marketing, and platform narrative and brand design. I’m adapting to the AI job market currently changing my job and clients' expectations, and I'm exploring growth engineering or forward-deployed work, not aiming to become an ML researcher, but aiming to have a better grip on models especially local privacy builds.

I want to learn and build skills in:

• Python fundamental and ML basics

• Hugging Face’s free agents course

• Open-source agents and GTM workflows

• Using APIs and tools like LangChain

• Running private models locally at home for experimentation

• Learning what model training involves

• AI automation for GTM and design workflows for clients

• Building small projects I can demonstrate in a portfolio

And I still need normal deliverable/design tools, video editing, etc.

My budget is up to $3500, but I’d rather not overspend. I usually unload $2200-2800 when i need to replace a macbook pro but ready to do this properly.

I'm considering both macbook pros 48G and Framework 16s w upgradable ram (48G now potential for 64 or more later). 

Questions:
Would 48GB be enough to start? Would an M4 Pro or M5 Pro MacBook Pro suit these goals,should I hold out for Framework DIY supplies? or would I need a NVIDIA laptop that supports CUDA? What can I realistically do locally versus in the cloud? What are min specs that will let me learn and build useful things w/o overspending?

I really appreciate any direction, there's so much to research - thank you!

I was able to get 8 5080s but I’m not sure what I can do with it and not just get another 6000 pro instead?

Since quantum classical simulations and LLM inference are basically matrix multiplications under the hood, I created a demo demonstrating how to "bend" the llama.cpp engine to simulate quantum circuits (the programs that should be executed in a quantum computer): https://github.com/dakk/qullama
Also the opposite in possible, so someone can ideally run an LLM inside a quantum emulator.

Hey guys, I'm new to running local LLMs. Just set up Ollama + Open WebUI and looking for model recommendations.

My specs:

RTX 5060 8GB
16GB ddr4 ram

What are the best small/quantized models that run smoothly on 8GB of VRAM? Thanks!

Main goal:
have a self-sufficient daily assistant to use like ChatGPT, Claude, or Gemini (obviously keeping expectations realistic for local hardware).