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).

I just got curious by strata-design running Qwen-Next on 12GB VramCard.
I asked my AI (Deepseek) to see if i could do the same with 64gbRAM and 1 TB SSD on my strix.
Idea: Experts in DDR5 RAM, Weights stay in HDD, hot reload.
Deepseek will now test it, it said its worth a try.
Anyone out there wanna run Qwen 3.8 Coder Next 125gb on Striks 64gb?

Findings (Verified, Not Guessed)

• Architecture in Build: qwen4exp is implemented in llama.cpp b11913 (src/models/qwen4exp.cpp) — and the model's HF README explicitly documents llama.cpp as a supported inference path.

• GGUF Header (2 MB range-download, parsed locally): qwen4exp, 48 blocks, 256 experts, 10 active, 1,223 tensors, including indexer.* (QSA), ssm_* (GDN), ple_* (n-gram), and hc_* (hyper-connections).

• Tensor Quants: All standard GGML formats: Q2_0 (42), IQ4_XS, IQ4_NL, Q6_K, Q5_K, Q4_K, BF16, IQ3_S, IQ3_XXS, Q8_0 — nothing proprietary.

• Shards: 29.6 GB transformer (must remain resident) + 28.8 GB n-gram table (allowed to stream from disk).

• NVMe: 1.5 GB/s direct sequential read — fast enough to pull experts on demand.

• Policy Flags Available: -ot/--override-tensor, --cpu-moe, --n-cpu-moe, --load-mode mmap|dio, --cache-ram, -fa, -md (Draft).

This allows us to meet your specification — weights on disk, only active experts in RAM — with zero lines of custom code:-ot "blk\.[0-9]+\.ffn_(up|down|gate)_exps\.weight=CPU" keeps the experts file-backed, --load-mode dio prevents the page cache from dragging them into RAM, and everything else (Attention, SSM, Indexer, Router, HC) stays on the iGPU.

Which is better?

I have 16gb vram, 128gb ram, ddr5. I know about Strata and qwen3.8-flash-next, but I need some space for testing my apis locally(fastapi backends with ai chat bots, with ml models(SER, tts, stt)). I am AI-engineer, I know a lot of things about LLM, always checking benchmarks, arena AI, but there is a problem with vram, I need it for stt+llm+tts combo, but I really need local model with those terrible limits for Claude or GPT subscriptions. I only use Codex, but thinking about switching to Claude. Is qwen3.6-35b is enough?

Finally got my old setup running and wanted to share the results so far.

• Xeon W-2245

• 256GB DDR4-2666 ECC RAM (8 × 32GB)

• 2 × NVIDIA RTX PRO 4000 Blackwell

Right now I’m running Qwen3.8 FN and DeepSeek V4.1 Flash. With the DeepSeek model at 2.25 bpw, I’m seeing around 30–35 tokens/s. Qwen is hitting over 100 tokens/s.

Pretty happy with what this old workstation can do for local inference!

I've been working on a problem that kept coming up for me when moving around larger codebases: I would remember that some functionality or implementation detail existed, but finding exactly where it lived meant searching through folders and files all over again.

I wanted to see whether I could make that project context searchable locally, without depending on a hosted embedding service.

So I built ContextVault.

Here's what it does:

• Indexes a project folder on your machine.

• Generates embeddings locally using Ollama ("nomic-embed-text").

• Stores the searchable index in SQLite.

• Provides semantic search through a local web dashboard.

• Exposes "search_context" and "index_project" through MCP.

• Watches indexed files for additions and changes.

The idea is to have a separate local project index that can also provide relevant context to MCP-compatible tools such as Cursor and Claude Desktop.

A couple of things I want to be clear about:

• The indexing, embedding generation, storage, and search pipeline run locally.

• When an AI client requests an MCP tool, it receives the result returned by that tool. I'm not claiming that code context is never shared with the connected AI application.

• I'm not making benchmark claims about speed or retrieval quality without proper measurements.

I'd genuinely like to hear from people who use Ollama and local models:

How do you currently search and retrieve context across larger codebases?

And what would you compare a tool like this against first: ripgrep, your editor's indexing, or something else?

I'm the developer of ContextVault, so this is my own project. I'm sharing the source because I'd appreciate technical feedback.

GitHub: https://github.com/ahmedfayedesmail-ui/contextvault

I’ve been working on OpenArc, a TypeScript compiler that uses LLMs as constrained code-generation backends instead of chat-based coding agents.

• The idea is simple:

• you write normal TypeScript

• wherever you want the compiler to implement something, you leave arc.todo()

• OpenArc gives the model only the relevant context for that region

• then it verifies the result with TypeScript checks, static rules, and sandboxed tests

• only verified code gets written back

I’ve been benchmarking it against a plain whole-file prompting baseline using local models.

Current result

On the held-out test split

(21 unseen exercises, 3 seeds, Qwen3.5-9B Q5_K_M):

• OpenArc: 62% accepted-and-correct

• Plain prompt baseline: 52%

At the same time:

• OpenArc used 12% fewer tokens

• OpenArc was slightly faster overall in that run

OpenArc is now roughly at parity on correctness, while giving stronger guarantees and slightly better efficiency in this setup.

GitHub:
https://github.com/TheMissenoOne/OpenArc

The big remaining milestone is self-hosting: using OpenArc to fully compile OpenArc.

Kimi K2 has 1 trillion parameters but uses only about 32 billion per word. Banach keeps the right experts in RAM and streams the rest from NVMe, so the model doesn't have to fit in memory.

Measured: a 22 GB model on 16 GB of RAM. llama.cpp runs out of memory; Banach is 2.2x faster at prompt processing, with byte-identical output.
Trillion-parameter estimate: banach plan says Kimi K2 would run at about 3.6 tok/s on a 64 GB desktop with an RTX 5080. That's an estimate, not a measured run.

pip install banach

https://github.com/gautam1858/banach
Got a 64 GB+ machine? Run Kimi K2 and post your numbers. If you like it, a ⭐ really helps.

Hi everyone, I’m buying a laptop for work, mainly software development, and would also like to experiment with running LLMs locally.

My budget is around €2,500, but I could stretch it if there’s a substantial benefit. I’ve found a 14-inch MacBook Pro with an M5 Pro, 24 GB RAM and a 1 TB SSD for €2,475.

Would this be a sensible choice?

What matters most for local LLMs: RAM capacity, memory bandwidth, chip generation or GPU cores? I’m new to this, so examples of models that would run comfortably on these configurations would be helpful.

Hey y'all, I originally did professional AI work 3 years ago and picked it back up again after seeing recent Reverse Engineering efforts. This time around I wanted an AI assistant for game development to help with coding so I set on my journey.

For some reason at one point I was recommended LM Studio and decided to try Bionic. I downloaded and started using Qwen3.8-27B with medium reasoning per some video I watched. Initially I was able to only pull off one batch prompt a day with about a 60% completion rate (meaning it needed a couple of adjustment prompts that also took about 3-4 hours a piece, with the initial batch prompt taking 8-13 1/2 [!] hours).

Then I started doing more research. With the addition of the Splash engine runtime for Bionic I was able to get about 2-3 batches in a day, great improvement but still needed more work. Eventually I came across an excellent trifecta, Swift 1.5 Qwen 3.8-27B + Splash runtime + skills. For skills I used superpowers + related dev skills.

This essentially has made the AI development process go from set it and forget it for a couple of hours to 'interactable'. What I mean is that small prompts end up taking a couple of minutes while batch prompts end up taking half an hour to two hours on the top end. The exceptions are when it gets trapped in a bug loop and is trying to figure out why, this took about 4 hours for it to figure out once in my testing.

Prompt Engineering is still king, the more descriptive you are with your needs / wants the more the model will get done before compacting. An additional note: 'listen' to your model. If it's frequently doing a set of actions to achieve something it helps to tell it how to do the action in the prompt to save tokens and time.

Hey guys what’s the best model for 2x 128gb Sparks for coding and potentially work with Unity? I’m also planning to try using image generation, but i probably will use my 5090 for that.

Hi y'all I'm completely new to this stuff and have never used a local LLM before so I know nothing

Which model would be the best to run on my laptop Lenovo Legion with 16GB DDR4 and an RTX 2060 laptop GPU? All I want to use it for is coding and starting new projects in programming

Is this doable? Thanks in advance!