From Raw Logs to Root-Cause Clues with OpenClaw & MiniCPM5–2B

AI tools, developer platforms, and infrastructure generate an enormous amount of information every day. Application logs are a perfect example.

When an application starts misbehaving, logs are usually one of the first places developers look. The problem is that logs rarely provide a clear explanation of what went wrong. They contain a mixture of normal requests, warnings, errors, retries, timestamps, and unrelated messages. Finding the important signals manually can take time.

This raises an interesting question:

How useful can a small local AI model be when it is placed inside a real developer workflow?

To explore that, this tutorial builds a local AI log analyzer using OpenClaw, Ollama, and MiniCPM5–2B.

The goal isn’t to replace a production observability platform or an experienced engineer. Instead, the experiment focuses on using a small local model for first-pass log analysis while keeping the inference workload on the VM.

The setup uses Ollama to serve MiniCPM5–2B locally, while OpenClaw provides the agent interface and workflow layer.

The final pipeline looks like this:

Application Logs
       ↓
    OpenClaw
       ↓
     Ollama
       ↓
  MiniCPM5-2B
       ↓
   Log Analysis
       ↓
Errors • Warnings • Evidence
       ↓
Troubleshooting Plan

The tutorial covers the complete process — from installing Ollama and downloading the MiniCPM5–2B GGUF model to connecting it with OpenClaw and testing increasingly structured log-analysis prompts.

The experiment also looks beyond the successful output. It examines where the small model performs well, where it can make unsupported assumptions, and how prompt structure can help separate confirmed evidence from possible causes.

That makes the project less about building another chatbot and more about testing what a small local model can actually do in a practical developer workflow.

Environment and Specifications

This experiment was tested on an Ubuntu 24.04 LTS virtual machine with the following configuration:

| Component                 | Specification                                  |
| ------------------------- | ---------------------------------------------- |
| Operating System          | Ubuntu 24.04 LTS                               |
| CPU                       | 8 vCPUs — Intel Xeon Platinum 8171M @ 2.60 GHz |
| RAM                       | 31 GiB                                         |
| GPU                       | No compute GPU — Hyper-V virtual VGA           |
| Architecture              | x86_64                                         |
| Storage                   | 30 GB root disk                                |
| Swap                      | 0 GB                                           |
| Ollama                    | 0.34.2                                         |
| OpenClaw                  | 2026.9.3                                       |
| Node.js                   | v24.20.0                                       |
| npm                       | 11.19.0                                        |
| Model                     | MiniCPM5-2B                                    |
| Model Format              | GGUF                                           |
| Quantization              | Q4_K_M                                         |
| Model Size                | ~1.56 GB                                       |
| Model Parameters          | 2.5B                                           |
| Active Context            | 16,384 tokens                                  |
| Model Maximum Context     | 131,072 tokens                                 |
| Inference                 | CPU-only                                       |
| Model Server              | Ollama                                         |
| Agent Layer               | OpenClaw                                       |

Model Configuration

The MiniCPM5–2B model was downloaded as a Q4_K_M GGUF file and imported into Ollama using a custom Modelfile.

The active Ollama configuration uses:

FROM ./MiniCPM5-2B-Q4_K_M.gguf

PARAMETER temperature 1.0
PARAMETER top_p 0.95
PARAMETER num_ctx 16384

OpenClaw is configured to use the same 16K active context:

ollama/minicpm5-2b

with thinking disabled for the tests:

"thinking": false

For the OpenClaw command-line tests, the workflow uses:

--thinking off
--local-model-lean

--thinking off keeps the initial tests focused on the final response, while --local-model-lean reduces the tool surface exposed to the local model.

Hardware Considerations

This setup does not use a GPU for inference. MiniCPM5–2B runs through Ollama directly on the VM’s CPU.

That makes the experiment useful for testing a relatively small local model on modest infrastructure rather than depending on a dedicated AI GPU.

The model file itself is approximately 1.56 GB, while the VM has 31 GiB of RAM and 30 GB of root storage.

For this particular experiment, the available resources were sufficient to run MiniCPM5–2B and OpenClaw together, although CPU inference is naturally slower than GPU-based inference.

Architecture

The complete software stack is:

Ubuntu 24.04
      │
      ├── OpenClaw 2026.9.3
      │       │
      │       ▼
      │   Ollama Provider
      │       │
      │       ▼
      │   Ollama API
      │       │
      │       ▼
      │ MiniCPM5-2B Q4_K_M
      │
      └── Local Application Logs
                  │
                  ▼
             Log Analysis

The important part is that the MiniCPM5–2B inference path remains local to the VM. The application log is passed to OpenClaw, OpenClaw sends the request to the local Ollama API, and Ollama runs the model locally.

This is the environment used for the log-analysis experiments described in the rest of the article.

Local Machine vs. VM

This setup can also be run entirely on your own local machine. The same Ollama + MiniCPM5–2B + OpenClaw workflow can be installed locally as long as the machine has enough RAM and storage.

For this tutorial, the setup is running on an Ubuntu VM because it provides a consistent environment and makes it easier to keep the services running independently of the local development machine.

The VM also gives us a convenient environment for testing the complete workflow without depending on the laptop’s current workload.

If you’re following along on your own machine, you can simply replace the VM-specific commands with the equivalent commands for your operating system. Ollama supports local model serving, so the overall architecture remains the same:

Your Local Machine
       ↓
    OpenClaw
       ↓
     Ollama
       ↓
 MiniCPM5-2B
       ↓
  Log Analysis

For this walkthrough, however, the VM is used as the primary environment, so all performance observations and command outputs in the tutorial are based on that setup.

Skip the Manual Setup with a Pre-Configured OpenClaw VM

If you don’t want to install Ollama, OpenClaw, dependencies, and the supporting environment manually, there is another option.

TechLatest OpenClaw VM — AI Agent Automation Stack

TechLatest provides a pre-configured OpenClaw VM that comes with OpenClaw, Ollama, required dependencies, and the runtime environment already set up.

The VM is available for deployment on AWS, Azure, and GCP, with both CPU and GPU configurations depending on the workload.

Launch OpenClaw on AWS Launch OpenClaw on Azure Launch OpenClaw on GCP

For this tutorial, the environment is configured manually so that every installation and configuration step is visible and reproducible. But a pre-configured VM can be useful when the goal is to start experimenting with OpenClaw immediately rather than spending time setting up the environment.

The available VM configurations support:

• CPU deployments for lightweight workloads and API-based integrations
• GPU deployments for faster local model inference with Ollama
• Pre-installed OpenClaw
• Ollama for local model execution
• Required dependencies and runtime components
• A cloud-based environment isolated from the local machine

This also makes the VM useful when experimenting with system-level AI agents, since the OpenClaw environment can be kept separate from the primary development machine.

For deployment guides and additional OpenClaw resources, see the TechLatest OpenClaw Support page

Step 1 — Install Ollama

Run this exactly in your Ubuntu VM:

curl -fsSL https://ollama.com/install.sh | sh

Wait for it to finish.

Then run:

ollama --version

And finally:

systemctl status ollama --no-pager

What I want to see

Ideally:

ollama version ...

and:

Active: active (running)

Step 2 — Verify the Ollama API

Before downloading MiniCPM, let’s make sure the API responds correctly.

Run:

curl http://127.0.0.1:11434/api/tags

You should get something similar to:

{"models":[]}

An empty model list is expected because we haven’t installed MiniCPM yet.

Then check Ollama’s disk location

Run:

df -h /

We want to make sure there is enough disk space for the model.

Step 3 — Set Up Python and Hugging Face Hub

The Hugging Face CLI is used to download the MiniCPM5–2B GGUF model. On Ubuntu 24.04, Python packages should be installed inside a virtual environment rather than directly into the system Python environment.

3.1 Install pip and virtual environment support

Update the package index:

sudo apt update

Install pip:

sudo apt install -y python3-pip

Verify the installation:

python3 -m pip --version

Then install Python virtual-environment support:

sudo apt install -y python3-venv

3.2 Create a virtual environment

Create a dedicated environment for the Hugging Face CLI:

python3 -m venv ~/hf-env

This VM uses the Fish shell, so activate the environment with:

source ~/hf-env/bin/activate.fish

Once activated, the terminal prompt should show:

(hf-env) ubuntu@ayush-ubuntu-vm ~>

Verify Python and pip:

python --version
pip --version

Expected output:

Python 3.12.3
pip 24.0 from /home/ubuntu/hf-env/lib/python3.12/site-packages/pip

3.3 Install Hugging Face Hub

Install the Hugging Face Hub package:

pip install -U huggingface_hub

Verify that the hf CLI is available:

hf --version

Example:

1.32.0

At this point, the Hugging Face CLI is ready to download the model.

Note: If you’re using Bash or Zsh instead of Fish, activate the environment with source ~/hf-env/bin/activate. For Fish, use source ~/hf-env/bin/activate.fish.

Step 4 — Download the MiniCPM5–2B GGUF Model

With the Python virtual environment active and Hugging Face Hub installed, download the MiniCPM5–2B Q4_K_M GGUF model.

The Q4_K_M quantization keeps the model size manageable while making it suitable for CPU-based local inference.

4.1 Create a directory for the model

mkdir -p ~/models/minicpm5
cd ~/models/minicpm5

4.2 Download the GGUF model

Run:

hf download openbmb/MiniCPM5-2B-GGUF \
  MiniCPM5-2B-Q4_K_M.gguf \
  --local-dir .

This downloads the model directly into:

~/models/minicpm5/

4.3 Verify the downloaded file

Run:

ls -lh ~/models/minicpm5/

You should see:

MiniCPM5-2B-Q4_K_M.gguf

The Q4_K_M file is approximately 1.56 GB, so make sure the VM has enough available disk space before starting the download.

Step 5 — Import MiniCPM5–2B into Ollama

Since the GGUF file is already downloaded from Hugging Face, we don’t need to download it again through Ollama. We’ll create an Ollama model from the local file.

First, confirm the file:

ls -lh ~/models/minicpm5/

You should see:

MiniCPM5-2B-Q4_K_M.gguf

Then create an Ollama Modelfile:

nano ~/models/minicpm5/Modelfile

Add:

FROM ./MiniCPM5-2B-Q4_K_M.gguf

PARAMETER temperature 1.0
PARAMETER top_p 0.95
PARAMETER num_ctx 8192

Save with:

• Ctrl + O
• Enter
• Ctrl + X

These parameters follow the MiniCPM5 documentation’s recommended sampling settings, while the 8192 context keeps the local deployment practical for this VM.

Then create the Ollama model:

cd ~/models/minicpm5
ollama create minicpm5-2b -f Modelfile

Finally, verify:

ollama list

You should see minicpm5-2b in the list.

Step 6 — Run MiniCPM5–2B Locally

The model is now available in Ollama. Start it with:

ollama run minicpm5-2b

Ollama will load the local MiniCPM5–2B model and open an interactive terminal session.

6.1 Send a test prompt

Once the model starts, enter:

Explain what an AI agent is in 3 sentences.

The response should be generated by MiniCPM5–2B running locally on the VM.

You can also test it with a prompt closer to our actual project:

Summarize this headline in one sentence: OpenAI releases a new model for AI agents.

6.2 Exit the model

When the test is complete:

/bye

This returns you to the Ubuntu terminal.

What we’re verifying

This step confirms the complete local inference path:

MiniCPM5-2B GGUF
       ↓
     Ollama
       ↓
   Local inference
       ↓
   Generated response

Step 7 — Connect MiniCPM5–2B to OpenClaw

The goal is:

OpenClaw
   ↓
Ollama API
   ↓
MiniCPM5-2B
   ↓
Local response

Before changing OpenClaw’s model configuration, first confirm that Ollama’s API is responding.

7.1 Check the Ollama API

Open another SSH terminal/session and run:

curl http://127.0.0.1:11434/api/tags

It confirmed:

minicpm5-2b:latest

with:

• 2.5B parameters
• Q4_K_M quantization
• GGUF format
• 131,072 context length
• Tools + thinking + completion capabilities

This confirms that Ollama is exposing the model through its local API.

7.2 Test the model through the API

Run:

curl http://127.0.0.1:11434/api/generate \
  -d '{
    "model": "minicpm5-2b",
    "prompt": "Explain AI agents in 3 sentences.",
    "stream": false
  }'

Ollama should return a JSON response containing the model’s generated answer.

Why test the API first?

We don’t want to troubleshoot OpenClaw and Ollama simultaneously.

The sequence is:

MiniCPM5-2B
      ↓
Ollama CLI             ← already tested
      ↓
Ollama API             ← test now
      ↓
OpenClaw                ← configure after API works

Once the curl request returns a response, we'll configure OpenClaw to use the local Ollama model.

The API returned:

"done": true

So the local inference pipeline is working.

But let’s fix one thing before OpenClaw

The response took about 18.6 seconds for only 428 generated tokens:

"eval_count":428
"eval_duration":18650755000

That’s roughly 23 tokens/second on this CPU-only VM.

That’s actually useful information for the blog because we’re testing a real CPU deployment rather than assuming performance.

Before we connect it to OpenClaw, I’d do one controlled test to see whether MiniCPM5 can return a concise answer without exposing its thinking output.

Run:

curl http://127.0.0.1:11434/api/generate \
  -d '{
    "model": "minicpm5-2b",
    "prompt": "Summarize this headline in one sentence: OpenAI releases a new AI agent framework.",
    "stream": false
  }'

The API returned:

OpenAI has announced the introduction of a new AI agent framework.

and:

"done": true

So the generation completed successfully.

One useful observation: the model briefly produced:

The user wants a summary...
</think>

before the final answer. That is the model’s reasoning/thinking output. For the actual OpenClaw news workflow, we should make sure OpenClaw only receives the useful final response rather than relying on that reasoning being shown to the user.

Also, this shorter request took about 4.95 seconds, compared with ~18.6 seconds for the previous longer response. So response length has a noticeable effect on CPU inference time.

Step 8 — Connect MiniCPM5–2B to OpenClaw

With MiniCPM5–2B running successfully through Ollama, the next step is to register the local Ollama model with OpenClaw.

The resulting setup looks like this:

OpenClaw
    ↓
Ollama Provider
    ↓
Ollama API
    ↓
MiniCPM5-2B

8.1 Configure the local Ollama provider

Set Ollama as the provider API:

openclaw config set models.providers.ollama.api "ollama"

Configure the local Ollama endpoint:

openclaw config set models.providers.ollama.baseUrl "http://127.0.0.1:11434"

Because Ollama is running on the same VM, the API remains accessible only through the local address.

8.2 Register MiniCPM5–2B

Add the locally installed model to OpenClaw’s Ollama provider configuration:

openclaw config set models.providers.ollama.models '[{"id":"minicpm5-2b","name":"minicpm5-2b","input":["text"],"contextTokens":8192,"params":{"num_ctx":8192,"thinking":false}}]' --strict-json

The configuration keeps the model’s active context at 8,192 tokens, matching the num_ctx value configured in Ollama Modelfile.

8.3 Verify the OpenClaw configuration

Run:

openclaw models list --provider ollama

The model should appear as:

ollama/minicpm5-2b

with the model marked as local and configured.

8.4 Test MiniCPM5–2B through OpenClaw

Use OpenClaw’s isolated agent exec command for the first test:

openclaw agent exec \
  --model ollama/minicpm5-2b \
  --thinking off \
  --local-model-lean \
  "Explain what an AI agent is in 3 sentences."

The --local-model-lean option reduces the tool surface presented to a local model, which is useful for a smaller model such as MiniCPM5-2B.

A successful run should end with:

stopReason=stop

and return a generated response.

For example:

An AI agent is a program that can take in natural-language instructions
and automatically complete tasks on your behalf. It handles multi-step
workflows, adapts to new situations, and operates independently or in
collaboration with humans.

8.5 The completed local setup

At this point, the complete inference path is working:

User
 ↓
OpenClaw
 ↓
Ollama Provider
 ↓
127.0.0.1:11434
 ↓
MiniCPM5-2B
 ↓
Local Response

No external model API is required for the MiniCPM5–2B inference itself. The model is stored locally on the VM and served by Ollama.

Note: For a small local model, keeping the tool surface and context under control is important. In this setup, --thinking off and --local-model-lean are used for the initial OpenClaw tests.

Step 9 — Turn OpenClaw into a Local AI Log Analyzer

Now that MiniCPM5–2B is running through Ollama and OpenClaw can use it as its local model, we can build something more useful than a simple chatbot.

For this experiment, I wanted to answer a practical question:

Can a small local model help investigate messy application or server logs?

Instead of sending logs to a hosted AI service, we’ll keep the analysis on the VM:

Application / Server Logs
          ↓
       OpenClaw
          ↓
       Ollama
          ↓
    MiniCPM5-2B
          ↓
     Log Analysis
          ↓
 ┌──────────────────────┐
 │ Errors               │
 │ Warnings             │
 │ Patterns             │
 │ Possible causes      │
 │ Troubleshooting      │
 └──────────────────────┘

The first thing we need is a realistic log file.

Step 10 — Create a Sample Application Log

Rather than relying on an existing production log, we’ll create a small reproducible example so anyone following the tutorial gets the same input.

Create a directory:

mkdir -p ~/openclaw-log-hunter
cd ~/openclaw-log-hunter

Create the log:

nano application.log

Add:

2026-09-18 09:41:02 INFO  Application starting
2026-09-18 09:41:03 INFO  Loading configuration
2026-09-18 09:41:04 INFO  Database connection initialized
2026-09-18 09:41:05 INFO  HTTP server listening on port 8080
2026-09-18 09:42:11 INFO  GET /api/users 200 42ms
2026-09-18 09:42:15 INFO  GET /api/products 200 38ms
2026-09-18 09:43:07 WARN  Database connection pool nearing capacity
2026-09-18 09:43:22 ERROR Database connection timeout
2026-09-18 09:43:22 ERROR Failed to execute query: connection unavailable
2026-09-18 09:43:23 WARN  Retrying database connection attempt 1/3
2026-09-18 09:43:25 ERROR Database connection timeout
2026-09-18 09:43:25 WARN  Retrying database connection attempt 2/3
2026-09-18 09:43:28 INFO  Database connection restored
2026-09-18 09:43:29 INFO  GET /api/users 200 51ms
2026-09-18 09:44:01 ERROR Failed to load cache entry: key=user_1842
2026-09-18 09:44:02 WARN  Cache miss rate above threshold
2026-09-18 09:45:11 INFO  GET /api/products 200 44ms

Save:

• Ctrl + O
• Enter
• Ctrl + X

Then verify:

cat application.log

At this point, we have a deliberately small but realistic log containing:

• normal requests
• warnings
• database failures
• retries
• recovery
• cache problems

Step 11 — Run the First Log Analysis

Now that our sample log is ready, let’s give it to the local OpenClaw agent.

Run:

openclaw agent exec \
  --model ollama/minicpm5-2b \
  --thinking off \
  --local-model-lean \
  "Analyze this application log and identify the errors, warnings, likely problem areas, and a concise troubleshooting plan:

$(cat ~/openclaw-log-hunter/application.log)"

The command reads application.log and passes its contents to the local OpenClaw agent.

The processing pipeline is:

application.log
      ↓
     cat
      ↓
   OpenClaw
      ↓
MiniCPM5-2B
      ↓
 Log analysis

The run completed successfully with:

stopReason=stop

MiniCPM5–2B identified the database connection failures, cache-related messages, and several possible problem areas. It also produced a troubleshooting plan.

This is our first useful result: the local 2B model can take raw application logs and turn them into a developer-readable analysis without sending the log to an external model API.

However, there was an important limitation.

The model occasionally treated assumptions as if they were facts. For example, it inferred that the database connection pool was completely saturated even though the log only explicitly said that the pool was “nearing capacity.”

That gave us the next experiment.

Step 12 — Generate a Structured Incident Report

A free-form analysis is useful, but when you’re investigating an incident, a consistent structure makes the output easier to read and compare.

So instead of asking for a general analysis, let’s explicitly define the format we want.

Run:

openclaw agent exec \
  --model ollama/minicpm5-2b \
  --thinking off \
  --local-model-lean \
  "Analyze the application log below and produce a structured incident report.

Use exactly these sections:

1. Incident Summary
2. Errors
3. Warnings
4. Evidence from Logs
5. Possible Causes
6. Troubleshooting Steps
7. Severity
8. Uncertain or Missing Information

Application log:

$(cat ~/openclaw-log-hunter/application.log)"

The model again completed the run successfully:

stopReason=stop

This time the response was organized into the eight requested sections.

The report identified:

Errors

• Database connection timeout at 09:43:22
• Database connection timeout at 09:43:25
• Failed database query because the connection was unavailable
• Failed cache entry lookup for user_1842

Warnings

• Database connection pool nearing capacity
• Database retry attempts
• Cache miss rate above the configured threshold

Evidence

The model extracted the relevant timestamps and log entries into a timeline.

Possible causes

It suggested possibilities including database connection-pool pressure, a temporary database connectivity problem, and a cache-related problem.

Troubleshooting

It suggested investigating:

• database connection-pool configuration
• database connectivity
• cache behavior
• retry behavior
• subsequent application requests

This is considerably more useful than simply asking an AI model to summarize the log.

But there was still a problem.

The model was making some assumptions about what the log meant.

For example, the log tells us:

Database connection pool nearing capacity

That does not prove that the pool was completely exhausted.

Likewise, a cache miss does not automatically tell us why that cache entry was unavailable.

So let’s make the analyzer more conservative.

Step 13 — Make the Log Analyzer Evidence-Aware

The previous experiment showed that a small local model can analyze the logs, but it can also make assumptions when interpreting them.

For an incident-analysis tool, that distinction matters.

We don’t want:

Log evidence
      ↓
     AI
      ↓
"Definitely the root cause"

when the log doesn’t actually prove the root cause.

Instead, we want:

Log evidence
      ↓
   MiniCPM5-2B
      ↓
┌───────────────────────┐
│ Confirmed observation │
│        vs.            │
│ Possible explanation  │
└───────────────────────┘

To test this, we’ll explicitly instruct the model to separate facts from hypotheses.

Run:

openclaw agent exec \
  --model ollama/minicpm5-2b \
  --thinking off \
  --local-model-lean \
  "Analyze this application log.

Follow these rules strictly:

- Only state something as a fact if it is directly supported by the log.
- Do not invent events, timestamps, metrics, configuration values, or system behavior.
- Clearly label hypotheses as possible causes.
- Calculate time differences carefully from the timestamps.
- If the log does not contain enough information to determine something, say so.

Return:

1. Confirmed Errors
2. Confirmed Warnings
3. Timeline
4. Possible Causes
5. Evidence
6. Missing Information
7. Troubleshooting Steps

Application log:

$(cat ~/openclaw-log-hunter/application.log)"

The run completed successfully:

stopReason=stop

This time the model produced a much more evidence-oriented report.

It correctly identified the confirmed errors:

Database connection timeout
Failed to execute query: connection unavailable
Failed to load cache entry: key=user_1842

It also identified the confirmed warnings:

Database connection pool nearing capacity
Retrying database connection attempt 1/3
Retrying database connection attempt 2/3
Cache miss rate above threshold

The timeline was also extracted directly from the log, including the recovery event:

09:43:22  Database connection timeout
09:43:22  Failed to execute query
09:43:23  Retry attempt 1/3
09:43:25  Database connection timeout
09:43:25  Retry attempt 2/3
09:43:28  Database connection restored

The model then separated possible causes from confirmed evidence.

For example, database connection-pool pressure was presented as a possible explanation rather than something definitively proven by the log.

It also identified information that the log doesn’t contain, such as:

• database engine
• connection-pool configuration
• cache implementation
• actual pool size
• underlying cause of the timeout
• reason the cache entry was unavailable

That’s exactly the behavior we want from a first-pass log analyzer.

What We Learned

At this point, we’ve tested three increasingly constrained versions of the same workflow:

Step 11
Raw Log
   ↓
General Analysis

↓

Step 12
Raw Log
   ↓
Structured Incident Report

↓

Step 13
Raw Log
   ↓
Evidence-Aware Analysis
   ↓
Facts + Hypotheses + Missing Information

The interesting part isn’t simply that MiniCPM5–2B can summarize a log.

The more interesting result is that a small local model can be turned into a useful first-pass analysis tool by controlling how the task is structured and how the output is constrained.

At the same time, the experiment also shows an important limitation: the model’s output should still be treated as an investigation aid, not as proof of the root cause.

The model can identify what appears in the logs, suggest plausible explanations, and point us toward areas to investigate. A developer still needs to verify those conclusions against the actual application, infrastructure, metrics, and service configuration.

Step 14 — Final Architecture

Show the complete system:

                         Developer
                             │
                             ▼
                    Application Logs
                             │
                             ▼
                         OpenClaw
                             │
                             ▼
                       Ollama API
                             │
                             ▼
                       MiniCPM5-2B
                             │
                             ▼
                    Log Analysis Engine
                             │
              ┌──────────────┼──────────────┐
              ▼              ▼              ▼
          Confirmed       Possible       Missing
          Findings        Causes        Information
              │              │              │
              └──────────────┼──────────────┘
                             ▼
                    Troubleshooting Plan

Then explain that everything in the inference path is local:

OpenClaw
   ↓
Ollama
   ↓
MiniCPM5-2B

No external model API is required for the actual log analysis.

Step 15 — What This Experiment Taught Me

This should be your conclusion rather than another technical test.

Something like:

What This Experiment Taught Me

Building this wasn’t about creating another chatbot.

I wanted to see how far a relatively small 2B local model could go when combined with an agent framework.

The result was better than simply asking the model questions.

OpenClaw provided the agent interface, Ollama handled local model serving, and MiniCPM5–2B performed the actual analysis.

The model was able to:

• identify errors from raw logs
• identify warnings
• build a timeline
• organize the information into an incident report
• suggest possible causes
• identify missing information
• generate troubleshooting steps

But the experiment also exposed an important limitation.

A model can produce a convincing explanation that goes beyond what the logs actually prove.

That’s why the evidence-aware prompt was important.

Instead of treating every model-generated conclusion as fact, we explicitly asked it to distinguish:

Confirmed evidence
        vs.
Possible causes
        vs.
Missing information

That makes the output more useful as a first-pass debugging aid, while still leaving the final diagnosis to the developer.

Final Thoughts

I started this experiment with a simple setup: an Ubuntu VM, Ollama, and a small local model.

By the end, I had:

Ubuntu VM
    ↓
Ollama
    ↓
MiniCPM5-2B
    ↓
OpenClaw
    ↓
Local Log Analyzer

The interesting part wasn’t the size of the model.

It was seeing how much more useful that model became once it was placed inside an actual workflow.

A 2B model running locally isn’t going to replace a full production observability stack or an experienced engineer.

But for a private first-pass analysis of application logs, it can already be surprisingly useful.

And because the inference happens locally, the experiment also gives you a way to explore AI-assisted debugging without sending your logs to a hosted model.

Thank you so much for reading

Like | Follow | Subscribe to the newsletter.

Catch us on

Website: https://www.techlatest.net/

Newsletter: https://substack.com/@techlatestnet

Twitter: https://twitter.com/TechlatestNet

LinkedIn: https://www.linkedin.com/in/techlatest-net/

YouTube:https://www.youtube.com/@techlatest_net/

Blogs: https://medium.com/@techlatest.net

Reddit Community: https://www.reddit.com/user/techlatest_net/