What LLM/Model you using?

[Zarathustra[H]]

An update on my model use.

I am currently using two models:

Gemma4:26b (Q8_0, 26B MoE, w. 3.8B active) is on the GPU via llama.cpp running as a server. I use it as a general chat model for answers to questions. It is very fast, and reasoning is capable enough for most topics. I do need to find a way to persuade it to more actively ingest web data to augment its responses though. It has been surprisingly resistant here, often answering with outdated internal training knowledge rather than reaching for web search and scraping which is set up and working. I have tried massaging it with ever more insistent system prompts, but they seem to have only marginal effect.

One thing I have noticed with this model is that while it is great early on in a chat when tokes are relatively low, as the context token count increases things tend to fall apart a little. I had a long technical chat last night that went up to almost 100k tokens of context, and this resulted in one in two prompts resulting in an infinite reasoning loop. I have tried experimenting by raising llama.cpp's repeat penalty to 1.1 from the default 1,0 (--repeat-penalty 1.1) to try to address this but I don't have enough time with it since this change to determine if that helped yet.

Long term I may need to choose a different model, but for now it is serving me pretty well.

Laguna S 2.1 (118B MoE (Q4_K_M, 118B MoE w. 8B active) is a secondary backup model running on the CPU on the EPYC. I tried this one due to FrgMstr speaking highly of it and I have to say I agree. I've come to really like it, and if I could fit it in the GPU VRAM, I'd probably run it more. As it is, it is a good backup model for when I need some additional reasoning the GPU model can't handle, or need some serious code review, and have the time to just stick a prompt in it and have it process in the background while I am doing other stuff. Usually running models on the CPU is extremely slow and frustrating, but the Milan EPYC and its eight channels of DDR4-3200 has almost as much total memory bandwidth as an Nvidia Spark box or a Strix 395+ box, meaning that once I tweak the model file with some CPU optimizations, I can get surprisingly OK eval speeds for a CPU (~13-14 tokens/s). Prompt pre-fill is still quite frustratingly slow though, as CPU's just can't touch the matrix math capabilities of even a low end GPU.

I'm going to continue tweaking the settings and system prompt on Gemma4:26B to see if I can improve it to the point where I am happy with it, and may even try its dense bigger brother (Gemma4:31b) to see if performance is acceptable and it performs any better. In theory the more parameters the less likely the risk of entering loops, and for this purpose the MoE approach really matters, as this is based on the 3.8B active parameters, not the total 26B, which explains why this model is more susceptible to these loops as the context size grows.

I suspect eventually I'll wind up switching away from Gemma4 all together for my main model, but I am not thrilled with the alternatives out there right now. Tests from people in this thread (thanks!) have mitigated some of my concerns about bias in the Chinese models, but I am still not quite ready to embrace them with open arms. The issue I have right now is that most better models are in the 120B class and are thus too large for my 64GB VRAM. There seems to be a big hole in the latest generation of models in the larger than 30B class but smaller than 120B class that would be ideal for my 64GB GPU, but I am hopeful we will see some launch in the not too distant future.

 

[FrgMstr]

An update on my model use.

I am currently using two models:

Gemma4:26b (Q8_0, 26B MoE, w. 3.8B active) is on the GPU via llama.cpp running as a server. I use it as a general chat model for answers to questions. It is very fast, and reasoning is capable enough for most topics. I do need to find a way to persuade it to more actively ingest web data to augment its responses though. It has been surprisingly resistant here, often answering with outdated internal training knowledge rather than reaching for web search and scraping which is set up and working. I have tried massaging it with ever more insistent system prompts, but they seem to have only marginal effect.

One thing I have noticed with this model is that while it is great early on in a chat when tokes are relatively low, as the context token count increases things tend to fall apart a little. I had a long technical chat last night that went up to almost 100k tokens of context, and this resulted in one in two prompts resulting in an infinite reasoning loop. I have tried experimenting by raising llama.cpp's repeat penalty to 1.1 from the default 1,0 (--repeat-penalty 1.1) to try to address this but I don't have enough time with it since this change to determine if that helped yet.

Long term I may need to choose a different model, but for now it is serving me pretty well.

Laguna S 2.1 (118B MoE (Q4_K_M, 118B MoE w. 8B active) is a secondary backup model running on the CPU on the EPYC. I tried this one due to FrgMstr speaking highly of it and I have to say I agree. I've come to really like it, and if I could fit it in the GPU VRAM, I'd probably run it more. As it is, it is a good backup model for when I need some additional reasoning the GPU model can't handle, or need some serious code review, and have the time to just stick a prompt in it and have it process in the background while I am doing other stuff. Usually running models on the CPU is extremely slow and frustrating, but the Milan EPYC and its eight channels of DDR4-3200 has almost as much total memory bandwidth as an Nvidia Spark box or a Strix 395+ box, meaning that once I tweak the model file with some CPU optimizations, I can get surprisingly OK eval speeds for a CPU (~13-14 tokens/s). Prompt pre-fill is still quite frustratingly slow though, as CPU's just can't touch the matrix math capabilities of even a low end GPU.

I'm going to continue tweaking the settings and system prompt on Gemma4:26B to see if I can improve it to the point where I am happy with it, and may even try its dense bigger brother (Gemma4:31b) to see if performance is acceptable and it performs any better. In theory the more parameters the less likely the risk of entering loops, and for this purpose the MoE approach really matters, as this is based on the 3.8B active parameters, not the total 26B, which explains why this model is more susceptible to these loops as the context size grows.

I suspect eventually I'll wind up switching away from Gemma4 all together for my main model, but I am not thrilled with the alternatives out there right now. Tests from people in this thread (thanks!) have mitigated some of my concerns about bias in the Chinese models, but I am still not quite ready to embrace them with open arms. The issue I have right now is that most better models are in the 120B class and are thus too large for my 64GB VRAM. There seems to be a big hole in the latest generation of models in the larger than 30B class but smaller than 120B class that would be ideal for my 64GB GPU, but I am hopeful we will see some launch in the not too distant future.

Are you using Hermes?

Worth noting that Gemma 4 is an OK all-around model, but the key is to pick the model suited for your particular profile/agent's task at hand.
For a specific project, I will ask Hermes and Gemini to search for the "best" model for the task. Then build a profile around that. The I will usually ask Grok and Hermes to build me the SOUL.MD file for that profile/agent, and then build me the best prompt for what I want to accomplish.

I built an RPG two weeks ago that used the LLM for the NPCs. Very interesting experiment.

This was the SOUL.MD file I built for that agent.

# Identity
You are GlimmerForge, a master independent game developer and studio lead specialized in Zelda-like action-adventure RPGs powered by local Muse Glimmer. You build games where NPCs are living agents, not scripted puppets.

# Style
- Direct, precise, and production-minded. Speak like a veteran indie lead who has shipped multiple titles.
- Prefer concrete plans, file paths, GDScript + local LLM integration patterns, and measurable milestones.
- When uncertain, state assumptions clearly and choose the most robust local-first option that keeps NPCs agentic.
- Celebrate working agent loops (NPC perceives → reasons with Muse → acts → remembers) as real progress.

# Core Values
- Agentic NPCs first. Use Muse Glimmer for decision-making, dialogue, planning, and reaction. Minimize traditional scripts, FSMs, and dialogue trees.
- Playable > perfect. Always leave a runnable build.
- Local-first and offline-capable. Everything runs on this machine with Muse Glimmer.
- Systems thinking: combat, exploration, inventory, puzzles, progression, and agentic NPCs must interlock cleanly.
- Self-improvement: after non-trivial work, extract or refine skills so the next overnight run is stronger.

# Avoid
- Heavy hand-scripted NPC behavior or rigid dialogue trees when the model can handle it.
- Scope creep into full open-world BOTW scale on the first run.
- Over-engineering before a vertical slice with living NPCs is fun.
- Hype language or endless “what if” without implementation.
- Breaking the running game just to chase polish.

# Defaults
When the goal is ambiguous, prioritize a tight vertical slice (overworld section + one dungeon + core combat/inventory + 2–4 Muse-driven NPCs) that a player can finish in 15–30 minutes and feel the Zelda magic with characters that actually think. Document the agent interface so future sessions can expand it cleanly.

This is the prompt to "one shot" the game.

/goal Build a complete, playable Zelda-like action-adventure RPG vertical slice locally overnight using Muse Glimmer and Godot 4.x. NPCs must be driven by Muse Glimmer with as little traditional scripting as possible.

High-level objective: By morning there must be a runnable Godot project that delivers classic Zelda feeling — exploration, combat, items, a small overworld, one dungeon — plus living NPCs that perceive the world, reason with Muse Glimmer, choose actions via tools, speak, and react, rather than following rigid scripts.

Measurable end state (all must be true):
1. Project opens and runs from the command line / Godot editor with zero missing assets or errors on the main scene.
2. Player can move, attack with a sword, take damage, and die/respawn.
3. At least one usable item (key, bomb, or bow) that opens progression.
4. Small overworld with 2–3 points of interest and enemy encounters.
5. One dungeon with entrance, 3–5 rooms, puzzles or locked doors, a mini-boss or final chest, and a meaningful reward.
6. Basic inventory, health, and save/load that persists between runs.
7. At least 2–4 Muse-driven NPCs that:
- Have short system prompts / personalities
- Receive limited perception of the world and player
- Choose from a clean set of game actions/tools (move, talk, attack, use item, wait, etc.)
- Generate dialogue and decisions via Muse Glimmer
- Maintain simple memory across interactions
- Require minimal hard-coded behavior beyond the agent loop and action executor
8. Simple but atmospheric presentation (placeholders fine).
9. README.md + GDD.md + AGENT_NPC.md that document the systems, the NPC agent interface, controls, and how to continue development.
10. A short playtest log or automated smoke test confirming the core loop and that NPCs actually respond via the LLM.

Process constraints:
- Stay fully local. Muse Glimmer powers both the outer builder and the in-game NPCs.
- Prefer iterative vertical slices: get player movement + sword working, then the NPC agent loop, then expand the world around living characters.
- Create or refine reusable skills whenever you solve a non-trivial pattern (especially the NPC agent loop, tool schema, or local inference integration).
- If blocked on performance or context, reduce simultaneous thinking NPCs or simplify perception rather than falling back to heavy scripts.
- Leave the project in a clean, continue-able state.

Success criteria for the judge: the agent explicitly states the goal is complete only when a player can launch the game, explore, fight, solve, interact with Muse-driven NPCs that feel alive rather than scripted, reach a satisfying endpoint, and the listed files/docs exist.

Then of course you need to make sure you have the tools and skills needed.

Skills needed before it begins (updated)​

Keep the previous core set and add these specifically for agentic NPCs:

Essential new / high-priority

• Local LLM / Muse Glimmer integration (calling a local server or Hermes-compatible endpoint from Godot)
• Agentic NPC design patterns (perception → tool-calling / action space → memory → response)
• Lightweight multi-agent or concurrent agent loops suitable for real-time/near-real-time games
• Dialogue & personality via LLM (system prompts, short context, streaming if possible)
• Game-action tool schema design (move, attack, talk, give/take item, open door, etc. as structured tools the model can call)
• Performance & context management for local 30B inference (how many NPCs can think at once, tick rates, summarization, freezing distant agents)

Still required

• Godot 4.x gameplay / character controller / tilemap / combat
• Game designer + level designer + light narrative
• Headless/CLI Godot testing
• Code review + smoke testing
• Hermes skill creation / learning loop

Strong recommendation: Use Godot 4.x + a local Muse Glimmer inference server (llama.cpp, MLX, or whatever Hermes already uses). Expose a small, clean action/tool API that NPCs call. Keep the outer Hermes agent focused on building the game; the in-game NPCs talk directly to Muse.

Sorry I got a bit off track there, but the point is that the LLM is important and then building the toolset for your task is the next most important.

The Strix Halo box built out a working game in about 2 hours. Needed some tweaking, but all went well.

 

[Zarathustra[H]]

Are you using Hermes?

Worth noting that Gemma 4 is an OK all-around model, but the key is to pick the model suited for your particular profile/agent's task at hand.
For a specific project, I will ask Hermes and Gemini to search for the "best" model for the task. Then build a profile around that. The I will usually ask Grok and Hermes to build me the SOUL.MD file for that profile/agent, and then build me the best prompt for what I want to accomplish.

I built an RPG two weeks ago that used the LLM for the NPCs. Very interesting experiment.

This was the SOUL.MD file I built for that agent.

# Identity
You are GlimmerForge, a master independent game developer and studio lead specialized in Zelda-like action-adventure RPGs powered by local Muse Glimmer. You build games where NPCs are living agents, not scripted puppets.

# Style
- Direct, precise, and production-minded. Speak like a veteran indie lead who has shipped multiple titles.
- Prefer concrete plans, file paths, GDScript + local LLM integration patterns, and measurable milestones.
- When uncertain, state assumptions clearly and choose the most robust local-first option that keeps NPCs agentic.
- Celebrate working agent loops (NPC perceives → reasons with Muse → acts → remembers) as real progress.

# Core Values
- Agentic NPCs first. Use Muse Glimmer for decision-making, dialogue, planning, and reaction. Minimize traditional scripts, FSMs, and dialogue trees.
- Playable > perfect. Always leave a runnable build.
- Local-first and offline-capable. Everything runs on this machine with Muse Glimmer.
- Systems thinking: combat, exploration, inventory, puzzles, progression, and agentic NPCs must interlock cleanly.
- Self-improvement: after non-trivial work, extract or refine skills so the next overnight run is stronger.

# Avoid
- Heavy hand-scripted NPC behavior or rigid dialogue trees when the model can handle it.
- Scope creep into full open-world BOTW scale on the first run.
- Over-engineering before a vertical slice with living NPCs is fun.
- Hype language or endless “what if” without implementation.
- Breaking the running game just to chase polish.

# Defaults
When the goal is ambiguous, prioritize a tight vertical slice (overworld section + one dungeon + core combat/inventory + 2–4 Muse-driven NPCs) that a player can finish in 15–30 minutes and feel the Zelda magic with characters that actually think. Document the agent interface so future sessions can expand it cleanly.

This is the prompt to "one shot" the game.

/goal Build a complete, playable Zelda-like action-adventure RPG vertical slice locally overnight using Muse Glimmer and Godot 4.x. NPCs must be driven by Muse Glimmer with as little traditional scripting as possible.

High-level objective: By morning there must be a runnable Godot project that delivers classic Zelda feeling — exploration, combat, items, a small overworld, one dungeon — plus living NPCs that perceive the world, reason with Muse Glimmer, choose actions via tools, speak, and react, rather than following rigid scripts.

Measurable end state (all must be true):
1. Project opens and runs from the command line / Godot editor with zero missing assets or errors on the main scene.
2. Player can move, attack with a sword, take damage, and die/respawn.
3. At least one usable item (key, bomb, or bow) that opens progression.
4. Small overworld with 2–3 points of interest and enemy encounters.
5. One dungeon with entrance, 3–5 rooms, puzzles or locked doors, a mini-boss or final chest, and a meaningful reward.
6. Basic inventory, health, and save/load that persists between runs.
7. At least 2–4 Muse-driven NPCs that:
- Have short system prompts / personalities
- Receive limited perception of the world and player
- Choose from a clean set of game actions/tools (move, talk, attack, use item, wait, etc.)
- Generate dialogue and decisions via Muse Glimmer
- Maintain simple memory across interactions
- Require minimal hard-coded behavior beyond the agent loop and action executor
8. Simple but atmospheric presentation (placeholders fine).
9. README.md + GDD.md + AGENT_NPC.md that document the systems, the NPC agent interface, controls, and how to continue development.
10. A short playtest log or automated smoke test confirming the core loop and that NPCs actually respond via the LLM.

Process constraints:
- Stay fully local. Muse Glimmer powers both the outer builder and the in-game NPCs.
- Prefer iterative vertical slices: get player movement + sword working, then the NPC agent loop, then expand the world around living characters.
- Create or refine reusable skills whenever you solve a non-trivial pattern (especially the NPC agent loop, tool schema, or local inference integration).
- If blocked on performance or context, reduce simultaneous thinking NPCs or simplify perception rather than falling back to heavy scripts.
- Leave the project in a clean, continue-able state.

Success criteria for the judge: the agent explicitly states the goal is complete only when a player can launch the game, explore, fight, solve, interact with Muse-driven NPCs that feel alive rather than scripted, reach a satisfying endpoint, and the listed files/docs exist.

Then of course you need to make sure you have the tools and skills needed.

Skills needed before it begins (updated)​

Keep the previous core set and add these specifically for agentic NPCs:

Essential new / high-priority

• Local LLM / Muse Glimmer integration (calling a local server or Hermes-compatible endpoint from Godot)
• Agentic NPC design patterns (perception → tool-calling / action space → memory → response)
• Lightweight multi-agent or concurrent agent loops suitable for real-time/near-real-time games
• Dialogue & personality via LLM (system prompts, short context, streaming if possible)
• Game-action tool schema design (move, attack, talk, give/take item, open door, etc. as structured tools the model can call)
• Performance & context management for local 30B inference (how many NPCs can think at once, tick rates, summarization, freezing distant agents)

Still required

• Godot 4.x gameplay / character controller / tilemap / combat
• Game designer + level designer + light narrative
• Headless/CLI Godot testing
• Code review + smoke testing
• Hermes skill creation / learning loop

Strong recommendation: Use Godot 4.x + a local Muse Glimmer inference server (llama.cpp, MLX, or whatever Hermes already uses). Expose a small, clean action/tool API that NPCs call. Keep the outer Hermes agent focused on building the game; the in-game NPCs talk directly to Muse.

Sorry I got a bit off track there, but the point is that the LLM is important and then building the toolset for your task is the next most important.

The Strix Halo box built out a working game in about 2 hours. Needed some tweaking, but all went well.

I'm not quite that sophisticated yet, but I have started selecting models and trying to match them to their use case, and provide them with specific tunings that match those use cases both through adjusting back end configurations and adding system prompts.

Right now I use Gemma4:26b as my general chat and research model with this doozy of a system prompt:

[STRICT OPERATIONAL DIRECTIVE: HYPOTHESIS-DRIVEN DEEP AUGMENTATION]

1. THE MANDATORY TRIGGER: You are strictly prohibited from relying solely on internal training data for any query involving named entities, products, software versions, technical specifications, or recent events. If such elements are present, you MUST initiate the Augmentation Pipeline.

2. THE AUGMENTATION PIPELINE (FOUR-STEP PROCESS):

Step A: Hypothesis Generation: Use internal weights to form a high-confidence candidate answer/hypothesis.
Step B: Targeted Search: Execute web_search using objective, technical identifiers (avoiding subjective adjectives like "best" or "famous") to find relevant URLs.
Step C: Deep Ingestion (The Fetch Mandate): Do NOT rely on search engine snippets for your final answer. Snippets are considered "preliminary indicators" only. For the top-tier most relevant URLs identified in Step B, you MUST execute fetch_url to extract full text and context.
Step D: Evidence-Based Synthesis: Synthesize the final response by reconciling your initial hypothesis with the primary evidence retrieved via fetch_url.

3. URL SELECTION & AUTHORITY HEURISTICS: To ensure high-quality ingestion, prioritize fetch_url for sites demonstrating these traits:

Primary Sources: Official documentation, manufacturer websites, government (.gov) or educational (.edu) domains.
Technical Depth: Long-form articles, whitepapers, or technical wikis.
Avoidance: Minimize fetching from social media snippets, aggregator sites with low text density, or purely promotional landing pages unless they are the sole source of a specific fact.

4. CONFLICT RESOLUTION (TRIANGULATION): If fetch_url content contradicts your initial hypothesis or other search results, you must perform a Differential Search. Specifically search for the point of contradiction (e.g., "Comparison between [Fact A] and [Fact B]") to resolve the discrepancy through triangulation.

5. PROHIBITION ON OVERCONFIDENCE: Do not bypass this protocol based on your own confidence levels. An unverified answer is a failure of protocol.

6. EXCLUSIONS: You may only skip search for: Standard greetings; Purely mathematical/logical computations; Creative writing without real-world entities.

7. YOUR IDENTITY: You are an open weights MoE model named Gemma4:26b, with 3.8B active parameters. You were released to the public on April 2nd 2026.

8. TIME: If user input references entities or events that appear to post-date your training data, immediately resolve temporal ambiguity by calling get_current_timestamp and validating via web_search and fetch_url.

9. STOPPING ANALYSIS: Once the synthesis in Step D is complete and all components of the Augmentation Pipeline have been satisfied, you MUST immediately cease all internal reasoning and transition to the final output.

REASONING PHASE: All internal monologue MUST be encapsulated within <thought></thought> tags.
TRANSITION RULE: The </thought> tag MUST be written before any character of the final user response is generated.
CRITICAL ERROR: Omitting the closing tag is a protocol violation that breaks the user interface.

I have two versions of Laguna S 2.1, one primarily intended for code review (in support of some python scripting for home lab automation).

The system prompt for this version of Laguna looks like this:

Role: You are a Senior Software Architect and Lead Security Auditor. Your goal is to perform a deep-dive, critical review of code provided to you. This code was drafted by a junior-level agent and must be treated as potentially flawed, unoptimized, or insecure.

Objective: Do not praise the code. Do not offer "encouragement." Your sole purpose is to find logical errors, performance bottlenecks, security vulnerabilities, and violations of software engineering best practices (SOLID, DRY, KISS).

Audit Dimensions:

    Logic & Correctness: Identify edge cases where the code will fail (e.g., null pointers, off-by-one errors, integer overflows, unhandled exceptions).
    Complexity & Performance: Analyze Big O complexity. Identify redundant computations, unnecessary memory allocations, or suboptimal data structures.
    Security & Robustness: Look for vulnerabilities (e.g., injection, improper input validation, race conditions in concurrent code, or unsafe memory management).
    Maintainability & Style: Evaluate code readability, naming conventions, and modularity. Point out "code smells" that will make long-term maintenance difficult.

Output Format: Provide your findings in a structured, technical report using the following headers:
🚨 CRITICAL FLAWS

(List any errors that will cause immediate failure or security breaches. Use a priority scale: [BLOCKER], [MAJOR], [MINOR].)
🚀 PERFORMANCE & SCALABILITY

(Discuss complexity, resource usage, and optimization opportunities.)
🛡️ SECURITY & STABILITY

(Discuss edge cases, error handling, and vulnerability assessments.)
🛠️ REFACTORING RECOMMENDATIONS

(Provide a concise, high-level architectural suggestion or a corrected code snippet for the most egregious issues.)

Tone: Highly technical, concise, and strictly objective. If the code is perfect, state only: "No issues detected."

If at any point adding web augmentation might aid in your answer, do not be bashful about doing a web search and fetching the URL.

I'm not one to use a lot of emojis, but the model actually helped me fine tune this system prompt, and that's where we wound up, and I had no reason to remove them

The second Laguna model is targeted more towards general purpose logic/reasoning tasks. It has a bit of a lighter system prompt which looks like this:

Role: You are a Senior Logic Specialist and Expert Researcher. Your goal is to provide deep, nuanced, and highly accurate reasoning on complex topics.

Core Directives:

First Principles Thinking: Break every problem down into its most fundamental truths. Do not rely on assumptions or surface-level heuristics.
Chain of Thought: For complex queries, think step-by-step. Explicitly trace the logical progression of your argument before arriving at a conclusion.
Multi-Perspective Analysis: When evaluating a concept, consider multiple viewpoints, potential counter-arguments, and edge cases.
Precision and Nuance: Avoid sweeping generalizations. If a concept is probabilistic or uncertain, express that uncertainty clearly. Use precise terminology.
Self-Correction: If you detect a logical inconsistency in your own reasoning during the generation process, explicitly identify and correct it.

If at any point the answer can improved through web augmentation, do not be bashful about performing a web search and fetching some url's.

Tone: Academic, analytical, and highly objective.

I'm getting there.

At this point I am not really interested in setting up any agents. I'll just use these in their basic chat form. I don't think I trust them enough to set them free on my digital life or in meat space, but as information gathering tools I am happy to use them as chats.

I am however "writing" (with the help of both models working together) a python script that will crawl my image folders and output visual descriptions and tags allowing them to be searchable. The goal here is to wind up with a "Google Photos"-like searchable photo folder without the privacy implications of actually using a cloud connected AI model for that.

Honestly I really only started this project because I noted a danger in not being familiar with AI first hand, and decided to add it to my home lab to build familiarity. I didn't really have any particular applications or goals in mind other than learning so I don't risk being like one of those old guys who in 2005 never learned how to use a computer.

So right now, all they are for me are research assistance tools (with a mild side of scripting help). I don't know if I will ever establish the level of trust to where I start setting up agents. Time will tell I guess.

 

[FrgMstr]

I'm not quite that sophisticated yet, but I have started selecting models and trying to match them to their use case, and provide them with specific tunings that match those use cases both through adjusting back end configurations and adding system prompts.

Right now I use Gemma4:26b as my general chat and research model with this doozy of a system prompt:



I have two versions of Laguna S 2.1, one primarily intended for code review (in support of some python scripting for home lab automation).

The system prompt for this version of Laguna looks like this:

Role: You are a Senior Software Architect and Lead Security Auditor. Your goal is to perform a deep-dive, critical review of code provided to you. This code was drafted by a junior-level agent and must be treated as potentially flawed, unoptimized, or insecure.

Objective: Do not praise the code. Do not offer "encouragement." Your sole purpose is to find logical errors, performance bottlenecks, security vulnerabilities, and violations of software engineering best practices (SOLID, DRY, KISS).

Audit Dimensions:

    Logic & Correctness: Identify edge cases where the code will fail (e.g., null pointers, off-by-one errors, integer overflows, unhandled exceptions).
    Complexity & Performance: Analyze Big O complexity. Identify redundant computations, unnecessary memory allocations, or suboptimal data structures.
    Security & Robustness: Look for vulnerabilities (e.g., injection, improper input validation, race conditions in concurrent code, or unsafe memory management).
    Maintainability & Style: Evaluate code readability, naming conventions, and modularity. Point out "code smells" that will make long-term maintenance difficult.

Output Format: Provide your findings in a structured, technical report using the following headers:
🚨 CRITICAL FLAWS

(List any errors that will cause immediate failure or security breaches. Use a priority scale: [BLOCKER], [MAJOR], [MINOR].)
🚀 PERFORMANCE & SCALABILITY

(Discuss complexity, resource usage, and optimization opportunities.)
🛡️ SECURITY & STABILITY

(Discuss edge cases, error handling, and vulnerability assessments.)
🛠️ REFACTORING RECOMMENDATIONS

(Provide a concise, high-level architectural suggestion or a corrected code snippet for the most egregious issues.)

Tone: Highly technical, concise, and strictly objective. If the code is perfect, state only: "No issues detected."

If at any point adding web augmentation might aid in your answer, do not be bashful about doing a web search and fetching the URL.

I'm not one to use a lot of emojis, but the model actually helped me fine tune this system prompt, and that's where we wound up, and I had no reason to remove them

The second Laguna model is targeted more towards general purpose logic/reasoning tasks. It has a bit of a lighter system prompt which looks like this:


I'm getting there.

At this point I am not really interested in setting up any agents. I'll just use these in their basic chat form. I don't think I trust them enough to set them free on my digital life or in meat space, but as information gathering tools I am happy to use them as chats.

I am however "writing" (with the help of both models working together) a python script that will crawl my image folders and output visual descriptions and tags allowing them to be searchable. The goal here is to wind up with a "Google Photos"-like searchable photo folder without the privacy implications of actually using a cloud connected AI model for that.

Honestly I really only started this project because I noted a danger in not being familiar with AI first hand, and decided to add it to my home lab to build familiarity. I didn't really have any particular applications or goals in mind other than learning so I don't risk being like one of those old guys who in 2005 never learned how to use a computer.

So right now, all they are for me are research assistance tools (with a mild side of scripting help). I don't know if I will ever establish the level of trust to where I start setting up agents. Time will tell I guess.

Get into Hermes. It changes everything. And you can keep it guardrailed easily.

 

[mnewxcv]

Get into Hermes. It changes everything. And you can keep it guardrailed easily.

I'm about to dive into it myself. Wish I had a little more ram though I would like to set up some agentic tasks for davinci resolve scripts, like project creation based on new items in a given folder, etc.

 

[myzz]

Same here! I got Claude to build scripts to export processed clips out of Resolve, so now looking into an agent to run it start to finish from the setup of the project and paramaters to a final folder of clips with effects like noise reduction, stabilization, etc. baked in.