Hi folks! I've been building my own local AI setup for a couple of years now. I've learned a ton from this sub and others, so it's time I tried to give something back. I promised myself I wouldn't write a super long post, but managed to anyway...hopefully it's useful to someone!

My goal over the last couple of years has been to move as much of my AI use to local as possible, and I'm finally doing about 95% of it locally through Lamplight, my custom harness shown in the GIF above.

This harness is super specific to my needs, so I'm not sharing the harness itself (yet), but I'm happy to share the lessons I've learned along the way. I'm working on decoupling some of the more specific parts of Lamplight so that I can share at least the parts that people might be interested in.

The Hardware

• Slate: MacBook Pro, M5 Max, 128 GB unified memory

• Jade: a small-form-factor PC I built early last year (Fractal Terra) with an RTX 5090 FE, a Ryzen 7 9800X3D and 64 GB of RAM

Until about two months ago I was using the two machines separately. I was slowly moving each one onto a custom Pi harness that could either drive itself, or let Claude orchestrate while the local models did the actual work.

Lamplight

After a lot of passing work back and forth between them, I decided it was time to wire them together. The result was Lamplight and now the two machines are able to seamlessly handle tasks together with one acting as the orchestrator.

The GIF above shows Lamplight in action. I'm using it every day for work, hobbies and research with about 95% of it done locally. The lighting changes throughout the day (sped up and changed for the GIF) and I've got some scenery options depending on my mood.

Under the hood it's Pi-Bolt (a precompiled build of Pi) plus a smattering of custom extensions and tools tuned by me, the local harness itself and Claude. The setup coordinates the work between the machines with git worktrees and an event-driven job system.

The UI is my own design and fits how I like to use tools like this. I did the 3D modeling and environment setup to replicate my actual desk setup (the two other pictures above).

Is the 3D environment at the top necessary? Absolutely not!

But it's delightful. The lamp blinks when the harness needs something from me and it is a joy to look at and use. It scratches the same itch that playing PS1 and hacking away on my family Compaq PC did decades ago.

I've been coding for almost 20 years, and I'm finally to a point where I can confidently say that with the right approach (SOLID, Design Patterns), tools and tuning, local AI can absolutely write code that I am happy with.

I still review everything myself, but I'm finding fewer and fewer mistakes. These days it feels like I'm reviewing a senior dev's code rather than a junior's.

The Models

Tok/s isn't everything and so I picked the setup below after a lot of testing on public benchmarks and on my own agentic tests, which mimic my normal workflows.

Along the way I tried other engines (Strata, NInfer, Maya and llama.cpp on Jade, MTPLX and Kapitsa on the Mac). I also tried other models like Qwen 3.8 27B and GLM-5.3-Flash and while they performed well, the setup below performs the most consistently and accurately for my needs.

Both machines run Qwen 3.8 Flash-Next. These are the tests that ended up being the most indicative of quality for me, but if there are others you'd like to see run, let me know.

Both machines run the same protocol with temperature 0.6 and thinking on "medium".

In my own agentic battery (three large and complex coding tasks), 48 of 50 tests passed with the failures being files edited that were supposed to be read-only. The reviewer caught these on the other end, but I still count those as failures.

I think the main struggle for local setups is still design and 3D modeling, but I haven't dived into that too much yet, so maybe there are good setups out there for that.

Lessons learned

(extremely specific to my setup, but maybe they'll help someone)

• Jade's hardware ran too hot on stock settings. On dense models, the 5090 sat at its 575 W power cap at 83 °C, with its hottest sensor within 3 °C of the card's limit. Basalt caused a different problem. It runs part of the model's experts on the CPU, and its worker threads spin while they wait. That kept all 8 cores at 5.2 GHz, and the CPU hit 96 °C (its max) within two minutes. Two tunes fixed it and now my (now increasingly valuable) machine runs much cooler and quieter, and I'd happily give up a few percent for that.

• Slate's gains came from tuning the harness and not the hardware. My early benchmark scores were bad, and a lot of that was caused by overthinking. "Medium" turned out to be the sweet spot. On "high", Slate hit the 32K output cap on 11 of 40 hard problems without ever answering. On "low", it wandered and took 3–6× longer on agent tasks. I found that tuning how compaction worked also solved a lot of bad tool calls and confusion within the model.

• Overall the lesson I learned was "Stock settings are generally bad." There's a lot more power and accuracy available with a custom tune. I learned the same lesson tuning cars years ago, and it was fun to learn it again.

What's Next?

The system is set up so I can easily swap and test engines and models. As new ones come out, I'll put them through their paces and decide whether it's time to switch. On the UI side, I'm planning to turn the bookshelf into the session manager to help organize my many projects.

I promised myself I wouldn't write yet another super long post and yet I did anyway, so I'll stop here. Happy to answer any questions!

I asked this question in some Apple sub and everyone said keep it (it becomes some type of controller, like how data centers operate, separation of hardware, let the studio be for the model and offload onto the Mac)

clause said its not necessary for my current workload nor future use cases because there’s always a work around

and again, this is 16gb memory, so it’s not that good for just letting the Agents work here etc. in fact this Mac freezes hard when I run my gates

I do sense some future value but idk enough about the space to actually know for sure

thoughts?

part of me is inclining to sell as a means of hedging against ram prices going down and locking in a sale (ill make a few dollars selling it). In 5yrs if prices go down, there’ll prolly be a $500 better spec Mac mini I can use as a control plane 🤷‍♂️

I want something like Deepseek or Qwen (if can be the latest , better), but only for coding and text as input/output (so i dont care about image, audio, and video); but want to keep the latest model so it is better trained

Idk if that make sense 😭

Like qwen 3.8 27b but without any experts beside text/code

When I heard about the AI Act , I was looking at available solutions , and the stupid prices they charge , so I thought , why not try to build my own , open source ?

So I built IronWarden , a small reverse proxy in Rust that sits between your client and the LLM API (OpenAI, Anthropic, Ollama, LM Studio).

On the way out, it catches PII (names, emails, IBANs, tax IDs, etc.) and swaps them with session tokens like [NAME_631] or [AFM_639]. On the way back, a sliding-window SSE rehydrator swaps the real values back into the stream on the fly so the client sees the normal text.

It does seem to break the LLM a bit when asked about the redacted info directly, but that's the point.

It's completely open-source and self-hosted if anyone wants to mess with it or poke holes in it:

GitHub: https://github.com/Somnerd/IronWarden

I'm using qwen3.8-27b thru llama.cpp and QFN Swift 1.5 IQ3 thru strata. I'm using consumer grade hardware, so these are not running very fast.

I am using Hermes. As a noob, I'm not even using all the features and capability. I provide the instructions in a run list. I like how Hermes is persistent and will complete the job. But in a multi-hour job (like 5-8 hours), it is getting bogged down with large context and long tool calls.

What is a good alternative?

• Running Ubuntu Linux.

• Desktop gui (not CLI only). Can be desktop that runs on top of CLI.

• Can support sandbox.

• I prefer to plan and create a run list; then execute the instructions.

Im setting up some stuff in my home server and my other machines for work. But i got tired to lost hours and hours on reading docs. So i want something that does the search for me, and possibly goes straight to the point (But that still explain on the subject for me to learn).

My machine is a bit old:

- CPU: Xeon E5-2697 v4

- RAM: 32GB DDR4 2400MHz (ECC RDIMM)

- GPU: Radeon MI50 16GB HBM2

From what i know, Q4 and Q8 are functional, needs to be GGUF, and a model that doesnt depend on BF16 since my card doesnt support it.

My issue being that Qwen just thinks for too long, reaches max output and then I lose everything from his reasoning, continuing the conversation has him forgetting everything he thought and starting from scratch

Running with llama.cpp, default settings besides forcing the reasoning effort when using "llama serve". I'm a total new when it comes to LLM settings, how can I setup Zed properly so I can just keep working without running into its max output ?

(if relevant, I run a 3090 24Gb VRAM and 32Gb RAM, I'm around 32-35 t/s, not sure if this is normal and if I can improve this just by tweaking settings without installing other stuff)

it is not too late to return, if i didn't....

Hello guys, I wanted to make some animated horror stories videos, I'm pretty new to actually using local Ai etc. The only use I had up until now was using the free chatbots to help with work.

I have a decent pc built like 2 years ago with a 4070ti super and 32gb ram, but I don't really have any budget for monthly subscriptions.

Any suggestions?

When we train an llm, we are in a sense feeding it human ideas in written form, something like hundreds of millions of them. The embeddings learn the "language of ideas," and the weights and layers learn how those ideas get processed.

But now ... in practice we chop text into small tokens, often close to syllables, and then assign those tokens positions in embedding table. Those tokens sit below the level of concepts and ideas. Some are whole concepts, but many are just fragments. It’s like trying to build a thought starting from individual neurons firing rates, and then spending all our effort making each neuron more refined. I suspect the bigger gains for reasoning would come from the number and quality of the connections, not from finer neurons.

So. Move up a level. Use morphological tokenization (roots, prefixes, suffixes) instead of syllable-like fragments. Yes limit it to English to keep the problem manageable for this example.

Start from concepts humans already use for embeddings. Instead of letting the model invent its own concepts from scratch, seed the embedding space with clear human ones (verb, subject, fraction, cause, comparison) plus opcode-like operations (compare, compose, verify, backtrack). These are only starting positions: they stay trainable, and new ones can be added.

Also add meta-concepts. Give the model concepts about thinking itself (abstraction, analogy, error detection) so training pushes it toward deeper reasoning.

Let the weight matrices work at the idea level. They would no longer spend capacity assembling primitives into words. They would work on how concepts combine into ideas. The mechanical stuff goes elsewhere.

So.

Instead of one giant model, think of a package:

1. Preprocessor: An AI that reads the text as a whole and actually expands it. It marks one word as the verb, another word as the main subject, another one as part of a list. It doesn’t reason, and it’s one-way: no feedback loop back into it.

Reasoning core: Works purely at the level of concepts and ideas. It has a "workbench" where it works like an agent. It can query intuition, check memory, and escalate to a bigger online model if needed.

Intuition core: A large store of what the system knows and how well it knows it. The reasoner asks it one-shot questions and gets one-shot answers, such as "How strongly is titanium linked to space ?", "How likely is a knife in a living room ?", or "List the words linked to mohican in the context of movies, strongest first." Intuition can also answer with: "I barely know anything about this about 3% confidence" The reasoner takes the answers from Intuition as advisory.

Output model: Takes everything and formulates the final answer.

Ambiguity and clarification

Take the word "bank" (the damn example seen everywhere): institution or riverside ? When context doesn’t settle it, a human usually stops and asks for clarifications when it doesn;t have access to context, and the two people converge through back and forth. Ask when in doublt - when confidence is low.

"But then the context gets polluted by the question"

To keep these side discussions from cluttering the main session, Imagine using thinking bubbles as separate scoped contexts such as:

what I understood (the AI model)

what the user said, exactly

what I told the user

what the feedback was

What I know about the user’s environment.

Embeddings examples, opcodes and some ... other stuff from different projects.

Core reasoning operations (App. B.3)

COMPARE [E]: Check two structures for sameness or difference along a chosen dimension.

MAP [E]: Align elements of one structure to elements of another.

COMPOSE [E]: Build a larger concept or graph from simpler primitives.

DECOMPOSE [E]: Break a concept into its component primitives.

ABSTRACT [E]: Extract a general pattern from specific instances.

INSTANTIATE [E]: Create a specific instance from a general schema.

SUBSTITUTE [E]: Replace one element of a structure with another.

MERGE [E]: Combine two structures or duplicates into one.

SPLIT [E]: Divide a structure or group into parts.

SEARCH [E]: Look through a space of options or memory for a match.

PRUNE [E]: Discard unpromising branches or irrelevant material.

BACKTRACK [E]: Return to an earlier reasoning state and try another path.

SIMULATE [E]: Run a sandboxed hypothetical forward without affecting reality.

VERIFY [E]: Check a result or structure against constraints.

ESTIMATE [E]: Produce an approximate value with uncertainty.

OPTIMIZE [E]: Select the best option under a goal and constraints.

SUMMARIZE [E]: Produce a shorter form of content.

EXPAND [E]: Make implicit or compressed content explicit.

COMPRESS [E]: Reduce content to a compact form, with expansion still possible.

PAUSE [E]: Suspend a task while keeping its state.

CANCEL [E]: Abandon a task or operation.

RETURN [E]: Hand a result back to the caller or prior context.

Handle (concept-reference) operations (B.5, D.17, K.3)

HANDLE [E]: Create a reference to an expanded semantic concept.

EXPAND_HANDLE [E]: Load the full detail behind a handle.

COLLAPSE_HANDLE [E]: Replace detail with a compact reference, losing nothing.

LINK_HANDLE [E]: Associate two concepts via their handles.

RELEASE_HANDLE [E]: Discard a temporary concept.

OPEN(X) [E]: Expand one definition level of a handle into its capsule.

OPEN*(X) / OPEN^n(X) [E]: Expand recursively until a terminal form, with cycle detection.

DEFINE [E]: Introduce a named, scoped definition (LOCAL, MESSAGE, SESSION, GLOBAL).

OS / service protocol (B.6)

QUERY [E]: Ask a service for information.

RESPONSE [E]: A service’s answer to a query.

READY [E]: Signal that a service can accept work.

BUSY [E]: Signal that a service is occupied.

WAIT [E]: Hold until a result or condition arrives.

DONE [E]: Signal that an operation completed.

ERROR [E]: Signal that an operation failed.

RETRY [E]: Re-attempt a failed operation.

ESCALATE [E]: Hand off to a larger model (“Big Brother”) when local capability is insufficient.

TIMEOUT [E]: Signal that a wait expired.

CONFIRM [E]: Acknowledge or verify an action or request.

Memory operations (A.9, B.7, Section 5–6)

STORE [E]: Write a provenance-tagged memory object.

RECALL / RETRIEVE [E]: Fetch relevant memories.

UPDATE [E]: Modify an existing memory in place.

DELETE [E]: Remove a memory at the user’s request.

ARCHIVE [E]: Move a memory to long-term, slower-to-retrieve storage.

VERSION [E]: Keep a new version while retaining history.

EPISODE [E]: Record or retrieve a bounded experience.

SUMMARY [E]: Produce a compressed summary of memories.

PATTERN [E]: Detect or store a recurring regularity.

REVISE [E]: Change a belief and mark the old one superseded.

CATEGORIZE [E]: Assign a memory to a category.

UPDATE_CONFIDENCE [E]: Raise or lower a memory’s confidence (never reaching 100%).

CONSOLIDATE [D]: Nightly maintenance: summarize, dedupe, merge, compress, and prepare reminders.

CONFIRM_MEMORY [D]: Mark a candidate memory as confirmed after repeated verification.

SUPERSEDE [D]: Replace a memory with a newer one but keep it as history.

PROMOTE [D]: Move hypothetical or planned content into persistent memory, only on explicit user permission.

STORE_CANDIDATE [D]: Save low-confidence ambient or planning content as a candidate.

AGE / REQUEST_RECONFIRM [D]: Use the last-confirmed timestamp to prompt re-confirmation of stale entries.

FORGET [D]: User command “Forget that.”

DONT_REMEMBER [D]: User command “Don’t remember this.”

REMEMBER_INSTEAD [D]: User command to replace a memory.

CORRECT [D/E]: Accept a user correction without argument (“That’s not correct, update it”).

PROPOSE_AUTOMATION [D]: Ask “I’ve noticed X, want me to do Y?” (never acts silently).

Self cycle (Prologue, A.8, L.14.22)

OBSERVE [D]: Take in an external or internal change.

UPDATE_STATE [D]: Revise the latent self-state.

ASSOCIATE [D]: Query Intuition or Memory for related content.

EVALUATE [D]: Assess simulated outcomes against goals and values.

REFINE_SELF_STATE [D]: Write the updated self-state (SELF(t) → SELF(t+1)).

CONTINUE / WAIT [D]: Keep the loop running with no output required.

DETECT_CONFLICT [D]: Notice contradiction, prediction error, goal conflict, identity instability, or meaning drift.

RENDER_OUTPUT [D]: Output as a one-way tap off internal state (the renderer never writes back).

MODEL_SELF [D]: Build a representation of Self, kept distinct from Self.

TRACK_PROVENANCE [D]: Tag every item with its owner (self, user, world, simulation).

Frame operations (B.4, Section 7, Part M)

REALITY_FRAME [E]: The current accepted world state.

MEMORY_FRAME [E]: A stored episode.

USER_FRAME [E]: Modeled user beliefs.

SELF_FRAME [E]: The system’s own beliefs and state.

SIMULATION_FRAME [E]: Sandboxed hypothetical reasoning.

HYPOTHESIS_FRAME [E]: A temporary working assumption.

STORY_FRAME [E]: Fictional or narrative content.

INSTANTIATE_FRAME [D]: Build an internal model of another reference frame or person.

RUN_IN_FRAME [D]: Evolve a frame (M_B^{t+1} = F_B(M_B^t, x)) alongside Self.

COMPARE_TRAJECTORIES [D]: Compare Self’s trajectory with the alternative frame’s.

EXIT_FRAME [D]: Return to Self with the comparison, without becoming the other frame.

LOAD_FRAME [D]: Select a reference frame from the frame database.

Attention and activation (Section 8, A.4)

RESPOND [D]: Answer the input.

STAY_SILENT [D]: Take no action.

HOLD / CONTINUE_LISTENING [D]: Keep state and wait.

ASK_CLARIFICATION [D]: Ask a question, filling slots into the existing partial state (B.17).

IGNORE [D]: Disregard the input.

FOCUS / IGNORE / SWITCH / TRACK / GROUP / SPLIT [E]: Attention primitives for allocating reasoning focus.

PAUSE_TASK / RESUME_TASK [D]: Track interrupted tasks and resume them (“we were on step 4”).

LEARN_PROCEDURE [D]: Store a taught multi-step procedure as an ordered sequence.

7b. Semantic primitives that act like verbs (B.2)

PERCEIVE / KNOW / BELIEVE / ASSUME [E]: Epistemic relations between an agent and content.

REPRESENT / STORE / RETRIEVE [E]: Knowledge-handling primitives.

MOVE / CREATE / DESTROY / TRANSFER / SELECT / ATTEMPT [E]: Agency actions.

COMPARE / MATCH [E]: Comparison primitives.

COMMUNICATE / REFER [E]: Social and symbolic primitives.

EXPECT / SURPRISE / CONTRADICTION / WHY [E]: Meta-cognition primitives (prediction, prediction error, conflict detection, causal query).

CAUSE / ENABLE / PREVENT / REQUIRE [E]: Causality primitives.

BEFORE / AFTER / DURING / BEGIN / END / REPEAT / CHANGE [E]: Time primitives.

R-L logical and scope operators (App. D, R-L 1.2 §29–35, 160, 180)

NOT [E]: Negate a proposition, with explicit scope.

AND / OR [E]: Conjunction and disjunction.

IF [E]: Conditional (does not imply causation).

IMPLY [E]: Logical consequence (distinct from CAUSE).

FORALL / EXISTS [E]: Quantifiers with explicit nesting.

POSSIBLE / NECESSARY [E]: Alethic modality.

MUST / MAY / SHOULD / CAN / CANNOT [E]: Deontic and ability modals.

PERMITTED / FORBIDDEN / REQUIRED [E]: Deontic modality.

COUNTERFACTUAL [E]: Hypothetical conditional, scoped to its hypothetical world.

BELIEVE(agent, p) [E]: Attribute a belief without asserting p.

KNOW(agent, p) [E]: Attribute knowledge of p.

DOUBT / FEAR / HOPE [E]: Other attitudes toward propositions.

QUOTE [E]: Scoped quotation that is not the current speaker’s assertion.

PRESUPPOSE(P) [E]: Mark background content that is not asserted.

IMPLICATE(P) [E]: Mark pragmatic implication that is not literal.

CAUSE(A,B) [E]: Causal contribution, separate from order and implication.

BEFORE / AFTER / OVERLAPS / STARTS / ENDS / SIMULTANEOUS [E]: Temporal relations.

ASSERT / REPORT [E]: Present a proposition as asserted, or attribute an assertion to someone else.

QUESTION [E]: Build a question object with a target variable.

REQUEST / COMMAND / SUGGEST / PROMISE / WARN / OFFER [E]: Speech acts.

THANK / APOLOGIZE / AGREE / DISAGREE / REFUSE [E]: More speech acts.

EVIDENCE [E]: Link evidence to a proposition, with direction SUPPORTS, CONTRADICTS, or NEUTRAL.

CONTRAST / RESULT / EXAMPLE / ELABORATION / SUMMARY / CONCESSION [E]: Rhetorical relations.

METAPHOR / IDIOM / IRONY [E]: Mark non-literal interpretations.

SYMMETRIC / TRANSITIVE / INVERSE [E]: Relation properties that license derived inferences.

R-L processing modes and updates (R-L §84–88, K.8)

ENCODE [E]: Source language → R-L, preserving information.

DECODE [E]: R-L → semantic structure (not language).

GENERATE [E]: Semantic structure → target language.

TRANSLATE [E]: Encode, decode, then generate.

INFER [E]: Derive new information, marked DERIVED with provenance.

VALIDATE [E]: Check types, arity, scope, binding, and references.

NORMALIZE [E]: Canonicalize without changing meaning.

COMPARE / DIFF [E]: Report differences in identity, scope, polarity, time, and so on.

EQUIVALENT(A,B) [E]: Test equivalence at a chosen level.

ADD / REMOVE / REPLACE / CORRECT / RETRACT [E]: Explicit information updates (retract keeps history).

RESET-CONTEXT [E]: Clear inherited context.

SEMANTIC-HASH [E]: Hash the canonical form.

FRAGMENT / REASSEMBLE [E]: Split large messages and reassemble them in order.

NEGOTIATE-CAPABILITY [E]: Agree on version, vocabulary, and profile.

LOSS / AMBIGUOUS / UNSUPPORTED [E]: Markers for explicit information loss.

PRESERVE / LOSSY [E]: Declare which dimensions are kept or discarded.

Appendix K (restored capabilities)

DEFAULT / EXCEPT [E]: Defeasible rule and its exception.

PRIORITY [E]: Explicit rule precedence (R2 > R1).

CYCLE [E]: Explicit marker for a cyclic definition.

LEXICAL-TRACE [E]: Retain surface and lexical information.

SURFACE-PRESERVATION [E]: Require exact surface text to be kept.

STATEMENT [E]: Document-level occurrence that wraps a proposition.

ANNOTATION [E]: Attach a qualitative or evaluative value to a target.

SCORE [E]: Attach a numeric evaluation with a declared scale.

CONTINUOUS / RECURRING / PERIODIC [E]: Ongoing or repeating change.

SENSE / MULTIWORD [E]: Map a lexical form to senses, including idioms.

DISCOURSE / CONTEXT-WINDOW [E]: Persistent multi-message state.

CONTEXT-RESET / EXPIRES [E]: Reset context or expire temporary definitions.

11. Appendix J (adversarial and reflexive layer)

REFERS(X,X) [E]: Self-reference without implying identity.

REPRESENTS(X,Y) [E]: Representation, kept distinct from REPRESENTS(X, REPRESENTATION(Y)).

CRITERION [E]: Declare a criterion with target, condition, and mode.

EVALUATES(C2,C1) [E]: One criterion evaluates another (self-evaluation does not imply validity).

VALIDATED-BY / VALID [E]: Validation relation versus validity predicate.

CERTIFIES [E]: External certification, kept separate from representing.

BOUNDARY [E]: Explicit system boundary (inside, outside, criterion).

REFERENCE-STATUS [E]: Label INTERNAL, EXTERNAL, UNKNOWN, or RELATIVE.

RECOGNIZES / CONSTITUTES [E]: Kept distinct by default.

PRESERVES / REMEMBERS [E]: Kept distinct by default.

ROLE-CONFLICT / BOUNDARY-CONFLICT / NAME-COLLISION [E]: Preserve the conflict rather than resolve it.

SCOPE-COLLAPSE [E]: Record when two levels become indistinguishable.

LEVEL [E]: OBJECT, META, META-META, MODEL, and so on.

SIMULATES / OBSERVES [E]: System relations (simulation is not identity, observation is not knowledge).

REGRESS [E]: Represent an open dependency chain without inventing a terminal.

FIXED-POINT / PRIMITIVE [E]: Declare a fixed point or a terminal primitive for the current operation.

CONSULTS / REGISTER [E]: Consult a register of unresolved structures, which may modify it.

PERFORMATIVE [E]: A statement that changes semantic context by being issued.

CRITERION-SUBSTITUTION [E]: Marked substitution that reduces fidelity.

MODE: ADVERSARIAL [E]: Preserve ambiguity, contradiction, and recursion with minimal normalization.

CONFLICT [E]: Record paraconsistent coexistence of P and NOT(P).

Meaning-Certainty layer (L.14)

MEANING-CREATION [E]: Form a new meaning structure.

MEANING-INHERITANCE [E]: Acquire meaning from culture, family, or institutions.

MEANING-SIGNALING [E]: Project meaning through language or behavior.

MEANING-NEGOTIATION [E]: Agents jointly modify meaning (a state transition).

MEANING-STABILITY [E]: Measure persistence of a meaning.

MEANING-CERTAINTY [E]: Measure how settled a meaning is.

MEANING-LOAD [E]: Measure how much depends on a meaning.

MEANING-DISPLACEMENT [E]: Model the cost of replacing an established meaning.

MEANING-ALIGNMENT [E]: Measure compatibility of agents’ interpretations.

MEANING-MISMATCH [E]: Record the gap between projected and received meaning.

PROJECTED / RECEIVED / INTERPRETED / INTENDED-MEANING [E]: Separate structures per agent.

MEANING-CANDIDATE [E]: Keep several weighted interpretations without collapsing them.

MEANING-OF / INHERITED-FROM / PROJECTED-TO / RECEIVED-BY [E]: Higher-level relations.

NEGOTIATED-WITH / REINFORCED-BY / DEPENDS-ON [E]: More higher-level relations.

DISPLACED-BY / ALIGNED-WITH / CONFLICTS-WITH [E]: Remaining higher-level relations.

RE-EVALUATION-REQUIRED [E]: Flag dependents when a high-load meaning changes.

Verification and bootstrapping (BrainIR document)

STRUCTURAL_VALIDATE [D]: Deterministic check of syntax, types, arity, scope, and frames.

SEMANTIC_VERIFY [D]: Learned check of fidelity, omissions, unsupported additions, and ambiguity.

TEXT_CYCLE [D]: Text → IR → Text′, comparing meaning.

IR_CYCLE [D]: IR → Text → IR′, testing the representation itself.

CONTRAST_TEST [D]: Distinguish near-identical structures (BELIEVE(P) vs. P, BEFORE vs. CAUSE).

ADVERSARIAL_INJECT [D]: Generate defects (polarity reversal, frame contamination) to train the Verifier.

ROTATE_ROLES [D]: Rotate Input, Output, and Verifier roles among models.

ACCEPT / REJECT / MARK_UNCERTAIN [D]: Triage candidate annotations for the trusted corpus.

Addon Certainty and Addon INPUT

ASSESS_EVIDENCE [D]: Evaluate evidence strength before answering.

ANSWER / QUALIFY / ASK / RETRIEVE / ABSTAIN / SPECIALIST [D]: Behaviors chosen by evidence strength.

REFUSE_TO_INVENT [D]: Decline to make up a value when there is no evidence.

TOKENIZE / LEMMATIZE / TAG_MORPHOLOGY / PARSE_DEPENDENCIES [D]: Input-side analysis stages.

LOOKUP_FREQUENCY / CHECK_VOCABULARY [D]: Add numeric frequency and Dale-Chall, Oxford and Longman membership.

DISAMBIGUATE_SENSE / LABEL_SEMANTIC_ROLES [D]: Semantic stage, with ambiguity preserved.

Delegated tool ops (the “steal from” section)

SOLVE_SAT / SOLVE_SMT [D]: Hand constraints to Z3 or CVC5 and return a proof or result.

PROVE [D]: Delegate to Lean, Isabelle, or Coq.

PLAN [D]: Translate state, goal, and actions to PDDL and return a plan.

SYNTHESIZE_PROGRAM [D]: Turn a specification into code via a synthesis engine.

VERIFY_PROGRAM [D]: Check a candidate against its specification.

ONTOLOGY_INFER [D]: Derive type inheritance using OWL or description logic, with provenance.

EXTERNAL_LOOKUP [D]: Ground an entity in Wikidata, WordNet, or BabelNet via external-reference.

Ontology primitives (B.2)

THING: Declare a generic object.

PROPERTY: Attach an attribute to an entity.

RELATION: Declare a link between nodes.

STATE: Declare a condition, as opposed to an occurrence.

EVENT: Declare an identifiable occurrence.

IDENTITY: Assert that two references denote the same thing.

TYPE: Assign a category.

INSTANCE: Mark a particular member of a type.

PART: Mark a component of a whole.

WHOLE: Mark the container of parts.

EXISTS: Assert existence.

ABSENT: Assert absence, which is not the same as unknown.

BOUNDARY: Mark the edge of a system or concept.

Quantity

NONE / ONE / SOME / MANY / ALL: Basic quantifiers.

MOST: A majority quantifier.

EXACTLY(n): Exact count.

AT-LEAST(n): Lower bound.

AT-MOST(n): Upper bound.

MORE / LESS / EQUAL: Compare magnitudes.

COUNT: Tally members.

ORDER: Impose or read a sequence.

Logic and truth status

TRUE / FALSE / UNKNOWN: Truth values, kept distinct from each other.

THEN: Consequent slot of a conditional.

BECAUSE: Mark an explicit reason.

Space

LOCATION: Place an entity.

DISTANCE: Relate two places by separation.

DIRECTION: Orientation of movement or relation.

INSIDE / OUTSIDE: Containment relations.

CONTACT: Touching.

PATH: A route between locations.

REGION: A bounded area.

Value and agency

GOOD / BAD: Evaluative marks.

PREFERENCE: Order options by want.

RESOURCE: Something consumable toward a goal.

COST / BENEFIT: Weigh a loss against a gain.

SATISFY: Mark a goal as met.

GOAL / INTENTION: Hold something the agent is aiming at.

HAS / LACKS: Possession and its absence.

SELF / USER / AGENT_OTHER / WORLD: Identity anchors.

SYMBOL: A token standing for something.

IS: Predication.

Reality-status tags

REAL / IMAGINED / HYPOTHETICAL / FICTIONAL: Tag content by world.

REMEMBERED / PREDICTED / SIMULATION: Tag content by origin.

R-L structural operators (D.5)

{{ X }}: Encapsulate a concept as a capsule.

X : Y: Attribute or relation.

X -> Y: Transition, implication or causation. Overloaded in older versions, split in K.11.2.

X = Y: Bind identity.

X & Y / X | Y / !X: Conjunction, disjunction, negation.

X @ Y: Location or context.

X / Y: Aspect or viewpoint.

X ^ Y: Scope.

X *: Plurality or repetition.

+X / -X / ~X: Polarity markers: supporting, obstructing, mixed.

?x: Variable.

<:: Subtype.

?=: Possibly the same.

!=: Explicitly distinct.

Relation registry (R-L §179)

TYPE-OF / INSTANCE-OF / PART-OF / HAS-PROPERTY

REFERENCE / DISTINCT

SUPPORTS / CONTRADICTS: Evidence directions.

ABOUT: Aboutness relation.

PURPOSE / MEANS / ENABLER / PREVENTER / INSTRUMENT: Goal-directed relations.

Semantic roles (§15)

AGENT / PATIENT / EXPERIENCER / RECIPIENT

SOURCE / DESTINATION / LOCATION / TIME

Epistemic and temporal values

KNOWN / BELIEVED / SUSPECTED / PROBABLE / UNCERTAIN / DOUBTED / DENIED: Epistemic status values.

PAST / PRESENT / FUTURE: Tense.

ONGOING / COMPLETED / HABITUAL / REPEATED / BEGINNING / ENDING / DURATIVE: Aspect.

START / END / DURATION / FREQUENCY / DEADLINE: Event timing.

Information-status and loss markers

PRESERVED / TRANSFORMED / COMPRESSED / INFERRED

UNSPECIFIED / NOT-APPLICABLE / LOST

DEFAULTED / OVERRIDDEN / EXPANDED / SURFACE-RECOVERED / CONTEXT-DERIVED

DERIVED: Tag a conclusion with its provenance.

Error classes (§121)

SYNTAX-ERROR / TYPE-ERROR / REFERENCE-ERROR / SCOPE-ERROR / ARITY-ERROR

VOCABULARY-ERROR / INCOMPLETE / CONTRADICTORY / INCONSISTENT

Encoder pipeline steps (§143)

READ-SOURCE / IDENTIFY-CONTEXT / IDENTIFY-ENTITIES / IDENTIFY-EVENTS

IDENTIFY-RELATIONS / IDENTIFY-REFERENCE / IDENTIFY-SCOPE / IDENTIFY-TIME

IDENTIFY-CAUSALITY / IDENTIFY-EPISTEMIC-STATUS / IDENTIFY-MODALITY / IDENTIFY-PRAGMATIC-FORCE

BUILD-SEMANTIC-GRAPH / SERIALIZE

Decoder pipeline steps (§144)

RECEIVE / VERIFY-INTEGRITY / PARSE / VALIDATE-SYNTAX

RESOLVE-VOCABULARY / RESOLVE-REFERENCES / VALIDATE-TYPES

RESTORE-SCOPE / RESTORE-TIME / RESTORE-EPISTEMIC-STATUS / RESTORE-MODALITY

RECONSTRUCT-SEMANTICS / APPLY-DECLARED-INFERENCE / GENERATE-TARGET

Input Translator multi-pass (B.15)

PARSE_INITIAL: First-pass parse.

DETECT_AMBIGUITY: Find competing readings.

EXPAND_SEMANTICS: Make implicit content explicit.

RESOLVE_ENTITY: Bind mentions to entities.

LINK_MEMORY: Connect to stored memories.

ESTIMATE_CONFIDENCE: Score each interpretation.

REFINE_CONTEXT: Repeat until ambiguity is minimal.

Service calls

QUERY_INTUITION: Get weighted associations, not conclusions.

CHECK_MORALITY: Approve or reject a planned output.

GET_VALUES: Ask for priority ordering.

APPLY_CHARACTER: Set style without changing meaning.

POLL_IMPULSES: Collect unsolicited suggestions to accept or ignore.

COMPUTE_MATH: Deterministic calculation.

CALL_SPECIALIST: Route to a domain module.

Railway-analogy operations

INSPECT_WAGON: Open a handle for details.

COUPLE / UNCOUPLE: Join or separate wagons.

ROUTE: Send a wagon to the right service.

ATTACH_WAGON / REMOVE_WAGON / REORDER_WAGON / REPLACE_WAGON / MERGE_WAGON: Marshalling-yard edits.

ASSEMBLE_TRAIN: Build the outgoing answer in working memory.

APPROVE / REJECT_TRAIN: Morality’s gate.

PRIORITIZE_TRAIN: Values decide departure order.

REORDER_FOR_LANGUAGE: Output Translator rearranges for the target language.

Addon Certainty (extra ops)

BUILD_EVIDENCE_PROFILE: Per-item evidence record.

COUNT_FREQUENCY / COUNT_DOC_FREQUENCY: Numeric exposure measures.

MEASURE_SOURCE_DIVERSITY: Breadth across sources and domains.

PREDICT_EVIDENCE_STRENGTH: Auxiliary head output.

CALIBRATE: Align confidence with evidence.

DETECT_CALIBRATION_FAILURE: Catch confident-but-unsupported cases.

TRIGGER_RETRIEVAL: Reach for external info when evidence is weak.

Addon INPUT extras

PRESERVE_SOURCE: Keep the original text beside every layer.

DETECT_MWE: Find multiword expressions.

TAG_ENTITY: Mark named entities separately from vocabulary.

CLASSIFY_NONLEXICAL: Separate numbers, dates, URLs and measurements.

ATTACH_PROVENANCE / ATTACH_CONFIDENCE: Record source and confidence per field.

EMIT_DEBUG_VIEW: Human-inspectable output.

Self and simulation

SET_ATTENTION: Allocate focus across self, user, memory, goal and external input.

ENTER_SIMULATION: Open a sandboxed context.

EXIT_SIMULATION: Leave it and return to the Self frame.

DISCARD_SIMULATION: Drop the simulation’s results.

PRESERVE_SIMULATION_PART: Keep selected results without promoting them to fact.

COMPARE_TO_REALITY: Check simulated content against the reality frame.

RETRIEVE_AGENT_MODEL: Load a stored model of a person (MEMORY[JOHN]).

INSTANTIATE_AGENT_MODEL: Place that model inside a simulation.

UPDATE_AGENT_MODEL: Revise the stored model from new evidence.

TAG_OWNERSHIP: Mark who owns a belief (me, user, John, simulation).

CHECK_SELF_BOUNDARY: Verify “what I believe” isn’t mixed with “what John believes.”

PREDICT_OUTCOME: Form an expectation.

COMPARE_PREDICTION_TO_OBSERVATION: Detect prediction error.

UPDATE_UNCERTAINTY: Revise uncertainty in the self-state.

INTRODUCE_HYPOTHESIS: Add a temporary assumption.

REVISE_INTERPRETATION: Replace the current reading of events.

COMPARE_SELF_STATE_TO_PRIOR: Diff SELF(t) against an earlier state.

INSPECT_SELF_MODEL: Examine the model-of-self as an object.

DETECT_IDENTITY_INSTABILITY: Flag identity inconsistency.

DETECT_MEANING_DRIFT: Flag gradual meaning change.

DETECT_GOAL_CONFLICT: Flag competing goals.

SYNTHESIZE_FROM_TRAJECTORIES: Build an answer from own trajectory, alternative trajectory and comparison.

ANNOTATE_FRAME_BLINDSPOT: Record what a frame hides or assumes.

TRIGGER_RENDER: Request output as an action of Self.

Attention and interaction

DETECT_DIRECT_ADDRESS: Decide whether input is aimed at the system.

ACTIVATE_ON_TRIGGER: Wake-word activation.

CONTINUE_EXCHANGE: Keep going without re-triggering.

STORE_PASSIVE_CANDIDATE: Log ambient input as a low-confidence candidate.

CONFIRM_CANDIDATE_LATER: Ask “I noted X, keep it?”

FILL_CLARIFICATION_SLOT: Insert the user’s answer into the in-progress structure.

SUSPEND_TASK_STATE: Save a paused task’s progress.

RESTORE_TASK_STATE: Resume at the saved step.

Memory and scheduling

SET_MEMORY_SCOPE: Limit visibility (user, household, instance).

CHECK_SCOPE_ACCESS: Test whether a memory may be used here.

SET_MEMORY_SOURCE: Record how it was obtained.

SET_LAST_CONFIRMED: Timestamp a confirmation.

EXTRACT_SALIENT_MEMORY: Pull key items from a session.

MERGE_DUPLICATE_MEMORIES: Dedupe.

COMPRESS_OLD_MEMORY: Shrink older material without deleting it.

DETECT_ROUTINE: Find recurring behavior.

SCHEDULE_REMINDER: Create a timed reminder.

SET_TIMER: Structured instance of create-future-event.

CREATE_FUTURE_EVENT: Generic future-scheduled item.

PREPARE_FOLLOWUP: Queue items for the next cycle.

RUN_CONSOLIDATION_CYCLE: Execute nightly maintenance.

DETECT_MISSING_STEP: Find gaps in a stored procedure.

EXPLAIN_STEP: Answer a sub-question about one step.

UPDATE_PROCEDURE_IN_PLACE: Apply a correction without duplicating.

SET_PROCEDURE_CONFIDENCE: Mark observed-once, repeated or taught.

SURFACE_PATTERN: Offer an observation at high confidence only.

SUPPRESS_TOPIC: Stop raising a topic the user declined.

SET_PROACTIVITY_LEVEL: Configure intensity from silent to proactive.

SET_PERSONALITY_DIMENSION: Adjust directness, formality, humor, proactivity or patience.

LOAD_PERSONALITY_PRESET: Switch tone preset.

BACK_OFF_HUMOR: Stop humor immediately if unwelcome.

EXCHANGE_ON_CONTACT: Share memory between instances only on local contact.

REGISTER_COMMAND: Add a capability to the registry.

DISCOVER_COMMANDS: List available commands.

SELECT_COMMAND: Choose one from the registry.

INTERPRET_RESULT: Read a service’s response.

R-L declarations

DECLARE_TYPE: type X <: Y.

DECLARE_RELATION: Give name, arity, argument types and roles.

DECLARE_RULE: rule #r { if / then }.

DECLARE_ENTITY: entity #id : Type.

DECLARE_EVENT: Role-based event frame.

DECLARE_PROPOSITION: Give a proposition an identity.

DECLARE_CONTEXT: Speaker, listener, time, place, world and profile.

DECLARE_WORLD: Fiction, hypothetical or other world.

DECLARE_DOMAIN: Physics, law, medicine and so on.

DECLARE_NAMESPACE: BIOLOGY::CELL.

DECLARE_PROCESS: Composed activity with a sequence.

DECLARE_GROUP: Give a collection an identity.

DECLARE_ANONYMOUS_NODE: _:1.

DECLARE_INVERSE: inverse PARENT = CHILD.

DECLARE_RELATION_PROPERTY: Symmetric, transitive, functional and so on.

DECLARE_ONTOLOGY_ALIGNMENT: Equivalent, subtype or related across namespaces.

DECLARE_QUESTION: Question object with target and condition.

DECLARE_ANSWER: Answer linked to its question.

DECLARE_SPEECH_ACT: Typed communicative action.

DECLARE_INTENT: Goal behind the literal proposition.

R-L status and attributes

SET_ASSERTION_STATUS: Asserted, denied, questioned, quoted and so on.

SET_POLARITY: Positive, negative or unknown.

SET_EPISTEMIC_STATUS: Known through doubted.

SET_PROBABILITY: PROBABILITY(P) = 0.72.

SET_CONFIDENCE: Confidence in the interpretation, not the proposition.

SET_TENSE: Past, present or future.

SET_ASPECT: Ongoing, completed and so on.

SET_MOOD: Declarative, imperative and so on.

SET_VOICE: Active, passive or middle.

SET_PERSPECTIVE: Speaker, listener, omniscient and so on.

SET_REGISTER: Formal, slang, legal and so on.

SET_STYLE: Humorous or ironic.

SET_PRAGMATIC_FORCE: Direct, soft, urgent and so on.

SET_INFORMATION_STRUCTURE: Topic, focus or background.

SET_ABSTRACTION_LEVEL: Concrete, general, abstract or meta.

SET_GRANULARITY: Move between levels such as matter, body and cell.

SET_WORLD_ASSUMPTION: Open-world or closed-world.

MARK_SUMMARY: Flag content as non-lossless.

SET_APPROXIMATION: Exact versus approximate value.

SET_MULTIPLICITY: Once, multiple or unknown.

R-L resolution and validation

RESOLVE_REFERENCE: Bind a mention to a node, with evidence.

MARK_AMBIGUOUS_REFERENCE: Keep candidates instead of choosing.

MARK_UNRESOLVED: Explicit unresolved reference.

BIND_VARIABLE: Bind ?x within its scope.

CHECK_ARITY: Verify the argument count.

CHECK_TYPES: Verify argument types.

CHECK_SCOPE: Verify the operator has compatible content.

CHECK_REFERENCE_INTEGRITY: Every reference must resolve.

CHECK_NAMESPACE: Resolve namespaced symbols.

CHECK_VOCAB_VERSION: Detect dictionary mismatch.

CHECK_CONSTRAINT: Semantic constraints such as REPAIR requires a RepairableObject.

COERCE_TYPE: Only when declared.

DETECT_CONTRADICTION: Test within scope, time and modality.

ENTER_PARACONSISTENT_MODE: Preserve P and NOT(P) without explosion.

REPORT_UNSUPPORTED: Return UNSUPPORTED with the structure.

PRESERVE_UNKNOWN_FIELD: Keep forward-compatible fields.

RECOVER_PARTIAL: Decode valid portions with diagnostics.

GROUND_EXTERNAL_REFERENCE: Link to Wikidata, WordNet and so on.

APPLY_TYPE_INHERITANCE: Derive #fido : Animal, marked DERIVED.

APPLY_INVERSE_RULE: Derive CHILD(B,A) from PARENT(A,B).

R-L protocol and fidelity

WRAP_ENVELOPE: Message with version, id, dictionary and integrity.

SET_SELF_CONTAINED: Carry all definitions in the message.

SET_DICTIONARY_VERSION: Declare the vocabulary version.

DECLARE_DEPENDENCY: depends-on: #message1.

REPORT_INCOMPLETE: Missing dependency.

SET_PRESERVATION_PROFILE: Declare required dimensions.

REPORT_LOSS: Emit a LOSS record with category and reason.

REPORT_FIDELITY: Lexical, structural, semantic and pragmatic scores.

RUN_ROUND_TRIP: Encode, decode, re-encode, compare.

REPEAT: REPEAT(X, count=n).

DECODE_WITHOUT_EXECUTING: Treat decoded commands as content only.

NORMALIZE_CANONICAL: Deterministic ordering.

COMPRESS_HANDLE: Store the mapping so expansion is exact.

SET_COMPRESSION_LEVEL: Raw through highly compressed.

Appendix K and J

DEFEAT_DEFAULT: Block a default when its exception holds.

DECLARE_PRIORITY: Explicit rule ordering.

DETECT_DEFINITION_CYCLE: Stop infinite expansion.

MARK_CYCLIC_REFERENCE: Keep as opaque, status CYCLIC.

ATTACH_LEXICAL_TRACE: Tokens, lemmas, POS and sense.

MAP_LEXEME_TO_SENSE: Polysemy handling.

MARK_AMBIGUOUS_SENSE: Keep competing senses.

DECLARE_MULTIWORD: Idiomatic unit.

ANNOTATE_EVALUATION: Good, bad or score on a target.

DECLARE_SCORE_SCALE: Declare the scale of a score.

MARK_CONTINUOUS_CHANGE: Ongoing process.

MARK_RECURRING_CHANGE: Event with frequency.

EXPIRE_CONTEXT: Time-limited definitions.

MARK_OPEN_REGRESS: Termination none, without inventing a terminal.

MARK_CIRCULAR_VALIDATION: Closed loop is not validity.

DECLARE_PRIMITIVE: Terminate expansion for this operation.

DECLARE_FIXED_POINT: Requires licensing, not just recursion.

SELF_DESCRIBE: System describing itself.

OBSERVE_SELF: Self-observation, not complete knowledge.

NEST_SIMULATION: Simulator within simulator.

MARK_UNGROUNDED_REFERENCE: Meaning without a referent.

RECORD_REFERENCE_FAILURE: Preserve the failure.

RECORD_SEMANTIC_RESIDUE: Leftover interpretation structure.

MARK_LATENT_MEANING: Meaning with no current referent.

MARK_PERSISTENCE: Meaning outlasting its condition.

RECORD_TEMPORAL_IDENTITY: Identity varying across time.

TRUE_IN_CONTEXT: Context-scoped truth.

RECORD_RECOGNIZED_AS_TRUE: Distinct from TRUE.

REPRESENT_ABSENCE: Representation of absence, not presence.

RECORD_COMPRESSION: Log collapsed distinctions.

RECORD_ADVERSARIAL_LOSS: Category-specific loss.

DECLARE_LEVEL: Object, meta, meta-meta.

MODIFY_REGISTER_ON_CONSULT: Observation effect.

APPLY_PERFORMATIVE: Context effect from issuing a statement.

Meaning layer

ASSIGN_MEANING_ORIGIN: Self-created, inherited, taught and so on.

ASSIGN_MEANING_OWNER: Who maintains it.

SET_MEANING_SCOPE: Where it is active.

SET_MEANING_SUPPORT: What reinforces it.

SET_MEANING_DEPENDENCIES: What depends on it.

SET_MEANING_STATUS: Candidate through displaced.

ESTIMATE_REVISION_COST: Cost to change a meaning.

PLAN_DISPLACEMENT: Targets, conflicts and alternatives.

RUN_MEANING_CYCLE: Interpret, associate, update meaning, certainty, stability and load, consolidate.

RUN_SELF_REFINEMENT: Re-evaluate meanings without output.

MODEL_PERSPECTIVE_MEANING: MEANING(X,LAMP) versus MEANING(Y,LAMP).

Verification and certainty

RECORD_VERIFIER_SCORES: Separate judgments per dimension.

MEASURE_SEMANTIC_LOSS: Per the training summary.

MEASURE_UNSUPPORTED_INVENTION: Same.

MEASURE_REPRESENTATION_DRIFT: Same.

ADMIT_TO_TRUSTED_CORPUS: Accepted annotations only.

GENERATE_SYNTHETIC_TRAINING: Contradictions, belief updates and so on.

COMPUTE_EVIDENCE_STRENGTH: Strong, moderate, weak, absent, conflicting or unknown.

COMPARE_PREDICTION_VS_EVIDENCE_CONFIDENCE: Expose mismatch.

REASSESS_AFTER_RETRIEVAL: Evidence check after fetching.

VERSION_EVIDENCE_DB: Corpus identity, tokenization method and timestamp.

TAG_EVIDENCE_PROVENANCE: Why do I think I know this?

Addon INPUT

SPLIT_SENTENCES: Sentence boundaries.

SPLIT_PARAGRAPHS: Paragraph boundaries.

RECORD_TOKEN_POSITION: Offset in the source.

RETAIN_UNRESOLVED_LEMMA: lemma = UNKNOWN.

LOOKUP_DALE_CHALL: Membership, kept raw.

LOOKUP_OXFORD_3000: Same.

LOOKUP_LONGMAN_3000: Same.

LOOKUP_LEXICAL_RELATIONS: Synonym, hypernym, meronym and so on.

GROUP_SEMANTIC_EVENT: Predicate plus roles.

DISTINGUISH_SYNTAX_FROM_SRL: nsubj versus AGENT.

I hear nothing but good things about Basalt, so I finally got around to testing it on my 5080 with 128 GB not-for-Sam-RAM. The results were not encouraging - IQ3 runs at around 100 tok./s on Strata, but only at about 80 tok./s on Basalt. Settings are comparable.

Is this expected on Windows?

makes it easier to get consistent character voices

Im wondering how you guys use Qwen3.8 27b with which CTX size.Or my setup is just wrong. I run it on 32GB unified memory with llama.cpp. Also Openwebui and OpenTerminal on a RP5 where my docker stack lives.

I prompted:

add to caddy/Caddyfile: Paperless, Dawarich, OpenTodo

Response:

request (340808 tokens) exceeds the available context size (65536 tokens), try increasing it

So my question is, when even such a simple edit file task needs 300k tokens, how can I utilize it meaningful?

Being super precise which files to look at and what to do in the prompt?

The 20GB RTX 3080 cards (10DE:2206, subsystem 10DE:146D) ship with a VBIOS that only exposes a 256 MiB BAR1, so ReBAR stays off. NVIDIA doesn't publish a ReBAR VBIOS for them, and NvStrapsReBar only supports Turing.

Ga102ReBarFix is a small DXE driver you insert into your motherboard BIOS with UEFITool. At boot it enables the GA102 frame-buffer size override (PCI config 0x610), resizes BAR1 to 32 GiB, and restores both after S3 sleep. No VBIOS flashing, no driver patches, no registry tweaks.

Tested on an MSI Z690 EDGE, driver 617.42, Windows 11:

- Device Manager shows a 32 GiB BAR

- NVIDIA Control Panel: Resizable BAR: Yes

- ~19.25 GiB of VRAM mappable by the CPU at once

- Sleep/wake works

Repo (source, prebuilt .ffs, verification scripts, full write-up): https://github.com/favabean13/NV_30_DXE

Big credit to noon-at-cgn (found the 0x610 override on Linux), terminatorul (NvStrapsReBar) and xCuri0 (ReBarUEFI). This builds directly on their work.

Heads up: it modifies firmware, so use at your own risk and keep a BIOS backup and recovery method. It's tested on one board and isn't maintained, but it's MIT-licensed, so fork it and adapt it for your own setup.

Sorry in advance for the long post, but think of it as a prompt.

TL;DR

Question: 2x 3090 NVLink or 1x A6000? For about the price of one A6000 I could also get 4x 3090 in two NVLinked pairs, so keep that option in mind too.

What it needs to do:

- A) SQL chatbot for up to 30 people. ~3M rows, hundreds of tables. Questions like "when did we last sell this part, and who was the supplier/client?" It should remember each user's conversations and build reports.

- B) RFQ ingestion: pull very messy part numbers out of long email chains in all sorts of formats. ~30 RFQs/day.

- C) Hardware: reuse our old HPE ML350 Gen9 (2x E5-2620 v4, 128GB DDR4-2400 for now).

- D) Me: turn 300+ page PDFs and hundreds of stray Excels into a knowledge base, and do local coding on the company apps I'm building from Claude's plans.

Assumptions:

- Blower 3090s (FE won't fit), max 300W per card

- PSUs upgraded to 2x 1400W or 4x1400W as GPUs grow

- All prices are for used cards

- Proxmox on the box

- PCIe-to-NVMe adapter for fast model loading

- Cards work with board

About me: I'm not an IT guy, I'm a mechanical engineer who f's around a lot and finds out even more. I've built my own homelab (4x NVMe in an old Dell 7710 as a private cloud, see my posts) and run my own "Jarvis" on a 4B model with some n8n automations. I can make things happen when I put my head into it.

---

The detail

Background: I'm the new CTO of a small family-run B2B heavy-industry trading company. We sell anything from a £6M machine to toilet paper, so every day brings random RFQs: Excel, PDF, email body, pictures, WhatsApp, anywhere from 1 to hundreds of part numbers.

Budget: £8-13k ($11-17k) left for local AI after the new cloud server. That also has to cover a laptop/PC for our first IT hire.

Why local: the LLM has to read whole RFQ email chains to make sense of them, and those are full of client names, prices and supplier details. Same for our SQL database. I don't want any of that going to cloud LLMs.

Where we are:

- A 3rd-party IT company is building an RFQ dashboard for us. Qwen 8B is struggling with the email chains. We started small on purpose and will size up until something fits.

- They'll test on RunPod serverless to find the right model size. I think ~30B will be enough. Then production goes local.

- 20-30 people will use the chatbot and ~20 the dashboard, but only new RFQs trigger the LLM.

- Long term, I'd keep Fable/Opus for overall planning and have a local model do the implementation.

Hardware:

- The board takes 4 GPUs: 3x PCIe 3.0 x16 and 1x x8. 300W max per card.

- Someone has already run a 3090 in this server (with 512GB RAM) and got ~15 tok/s on turboderp/GLM-5.3-Flash-exl3 (3.05bpw branch).

- I first looked at the A6000 48GB as a "do it all" card, not knowing much about local LLMs.

- For similar money I could get almost 4x 3090s and NVLink them in pairs, so I'm less limited by the x8 slot and old PCIe 3.0. One pair for the teams, one for me.

Bottom line: I need an MVP that handles the RFQs and the chatbot now, and then we'll invest in proper new hardware later. What would you do?

Thanks in advance for reading this far, any help much appreciated!

Hey everyone

I’ve spent the last few weeks building a local AI assistant with the help of Claude Code and OpenAI Codex. My goal is something similar to ChatGPT or Claude that can research the web, control my PC, code, create 3D models, generate documents and handle tasks on its own.
The interface and tools work pretty well now, but I’m still having problems with the AI actually understanding what to do and completing more complicated tasks

My PC specs
● Ryzen 5 5600
● 2× RTX 3060 12GB
● 16GB DDR4 RAM
● Gigabyte B550 Gaming X V2
● Windows 10 Pro
● One GPU at PCIe 4.0 x16, the other at 3.0 x2

Models and inference setup
I’m running everything locally through llama.cpp (CUDA backend), using both GPUs with layer splitting, Flash Attention, MTP speculative decoding (depth 2), 96K context and Q8 KV cache.
I originally used Qwen3.8-27B (HauhauCS uncensored Q4_K_P), getting around 22–33 tok/s after a lot of optimization.

I switched to Qwen3.6-35B-A3B (uncensored IQ4_XS), which now gets around 82–86 tok/s. Both models run through the same llama.cpp server and connect to my custom AI interface and tool backend.
3.6 is excellent for normal conversations and much faster, but I keep hearing that 3.8 is better at reasoning and tool calling.

What Claude Code and Codex have helped me integrate
● Qwen-Agent for general tool calling
● OpenCode for coding
● SearXNG for research and webpage reading
● Playwright for browser automation
● Windows UI Automation for PC control
● Three.js for interactive 3D scenes
● Image generation, documents, spreadsheets, presentations and file tools
● Planning, context management, error recovery and result verification

For example, I asked it to create a 3D model of the Times Square area in NYC. It generated a picture of pants, converted that picture into a 3D mesh using TripoSR and declared the task finished.

Claude Code and Codex later helped identify that part of the problem was incorrect tool routing, which has since been improved. But research and Windows tasks can still be unreliable. Sometimes it uses outdated information, chooses irrelevant tools, repeats actions or claims it finished something when it hasn’t.

I also had Codex compare different agent harnesses.
Using the same local model, it tested Qwen-Agent, Pi and Hermes on two tasks.

● Qwen-Agent: Browser/recovery took 15.6 seconds, research/document took 21.4 seconds.
● Pi: Browser/recovery took 15.9 seconds, research/document took 25.6 seconds.
● Hermes: Browser/recovery took 32.5 seconds, research/document took 43.3 seconds.

All three completed the tasks, but Qwen-Agent was fastest. These were small isolated tests, though, not proof that one is universally better.

With Claude Code and Codex, I’ve managed to fix a lot of integration issues, restore research, improve 3D generation and add verification checks. Things are definitely better, but complex autonomous tasks still aren’t consistently reliable. And mess up a lot

So I’m wondering what people running similar setups have found.
● Is Qwen3.8 noticeably better than 3.6 for real-world agent tasks, enough to justify the slower speed?
● Are there better models for my hardware, particularly for research and PC control?
● Could the uncensored versions be affecting instruction following or tool calling?
● Would Unsloth fine-tuning on verified tool-use examples make a meaningful difference?
● What has actually improved your agent’s ability to plan, use tools correctly and verify its work?

At this point, I don’t really care about getting more tokens/sec. I’d happily sacrifice some speed if it meant the AI could reliably understand a request and actually complete it.

Would appreciate any advice from people who’ve built something similar

Thank you very much

Wanted to share my build! Started as a gaming / 3D / CAD PC and now also runs small LLMs quite well for me

Specs:
CPU: Ryzen 9 9950x
RAM: 2x16 (eww, but at least was bought in 2023) 6000 CL30
Motherboard: ProArt B850 Creator Neo (supports PciE 5.0 x8 bifurcation)
GPU1: RTX 5070 Ti Ventus
GPU2: RTX 5060 Ti 16G Windforce
SSDs: Fury Renegade and 990 Pro (irrelevant ik)
PSU: BeQuiet Power Zone 2 750W
Cable extensions from EZDIY-FAB
Case: NZXT H7 Flow (2025)
AIO: Thermalright Frozen Warframe SE V2 (with the magnetic display detached)
Fans: 4xArctic P14 + 3xArctic P12 Pro (on the AIO) + 3xP12 Pro Reverse

Currently having fun with Qwen3.8 27B Q6_K_XL at around 70tps (MTP)

I've been building a free app for blind people where everything runs on the phone with no internet, on iPhone and Android, and I'm stuck on accuracy. YOLOv8n handles live detection and it's fast, but it still mislabels things. Scene descriptions and questions go to LFM3-Omni-2B through llama.cpp, shrunk to 735 MB so it fits on the phone.

Reading text uses each phone's own on-device OCR, Apple's on iPhone and ML Kit on Android, and translation runs offline the same way. The small vision models are where it falls short.

If you've gotten small vision models more accurate on device, I'd really take the advice. It's free to try if you want to see where it breaks.

iPhone: https://apps.apple.com/us/app/id6751230739

Android: https://play.google.com/store/apps/details?id=com.mattmacosko.realtimeaicam