#openclaw research workflow

1 messages · Page 1 of 1 (latest)

golden sleet
#

I have a openclaw Local PC setup with a smaller LLM runs on a custom target on Local.

I also have a larger LLM model running on a remote Machine called Hulk. This LLM runs on a custom target with an accelerator.

Now, I want to build following

Summarize complex tech-paper, if the paper is less than 4-5 pages, use LLM on Local PC.
For Large documents uses the Hulk setup.

How to make this setup possible? what are the best architecture solution to make this setup possible?

Also tell me if processing small documents on local is feasible/efficient? Tell me what are the skills or tools required?

Tell me what are the configurations needs to be done for the setup? which approach should I use?

Will there be a any node connection? requirement of distributed file access/operation system?

Give me single clear recommendation that follows openclaw best practice to implement this setup

silver quarryBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

pliant badgeBOT
#

Recommended architecture: keep one OpenClaw Gateway on your Local PC, configure both LLMs as model providers, then add one “paper summarizer” skill that routes by page/token count. Don’t make Hulk a node unless you need shell/file operations on Hulk.

Best-practice design

  1. Local PC Gateway

    • Owns Discord/Telegram/UI sessions.
    • Receives PDFs.
    • Counts pages/tokens locally.
    • Chooses model.

  2. Two model providers

    • local-small/... → local LLM endpoint.
    • hulk-large/... → Hulk LLM endpoint over LAN/Tailscale/VPN/SSH tunnel.

  3. One custom skill

    • summarize-paper
    • Logic:
#
  • Extract PDF metadata locally.
    • If pages <= 5 or token estimate is small → call pdf with local model.
    • Else → call pdf with Hulk model, or spawn a sub-agent using Hulk for long research tasks.
  1. No distributed filesystem needed
    • If the PDF is uploaded to OpenClaw, the Gateway can read it and send text/PDF bytes to the selected model provider.
    • You only need shared storage if PDFs already live on Hulk and you don’t want to upload/copy them.
    • You only need an OpenClaw node host on Hulk if you want OpenClaw to run commands on Hulk, not merely use Hulk’s LLM endpoint.

Example shape:

{
  models: {
    providers: {
      "local-small": {
# 
        baseUrl: "http://127.0.0.1:8000/v1",
        apiKey: "${LOCAL_LLM_API_KEY}",
        api: "openai-completions",
        request: { allowPrivateNetwork: true },
        models: [
          {
            id: "small-tech-model",
            name: "Local Small Tech Model",
            input: ["text"],
            contextWindow: 32768,
            maxTokens: 4096
          }
        ]
      },
      "hulk-large": {
# 
        baseUrl: "https://hulk.example.local/v1",
        apiKey: "${HULK_LLM_API_KEY}",
        api: "openai-completions",
        request: { allowPrivateNetwork: true },
        timeoutSeconds: 600,
        models: [
          {
            id: "large-research-model",
            name: "Hulk Large Research Model",
            input: ["text"],
            contextWindow: 128000,
            maxTokens: 12000
          }
        ]
      }
# 
    }
  },

  agents: {
    defaults: {
      model: {
        primary: "local-small/small-tech-model"
      },
      pdfModel: {
        primary: "local-small/small-tech-model"
      },
      pdfMaxPages: 20,
      pdfMaxBytesMb: 25
    }
  }
# 
}

Then your skill should explicitly choose:

  • Small PDF: model: "local-small/small-tech-model"
  • Large PDF: model: "hulk-large/large-research-model"

Do not rely on model fallbacks for this. Fallbacks are for failure recovery, not “if document is large, route to Hulk.”

Small-document local processing is feasible if the local model has enough context and decent instruction following. For 4–5 page papers, it’s usually efficient and privacy-friendly. For dense technical papers, quality may still be better on Hulk, so I’d use page count + token estimate, not page count alone.

If Hulk is just serving an OpenAI-compatible/vLLM/SGLang endpoint: no OpenClaw node connection required. If you need remote command execution on Hulk, then use openclaw node run/install on Hulk and pair it.

Docs:

golden sleet
#

Can you tell me more about how to create a custom skill ? How to create a sub-agent for this task?

pliant badgeBOT
#

Yes — for your case I’d make one custom skill and optionally a dedicated Hulk sub-agent.

1. Create a custom skill

A skill is just a folder with a SKILL.md.

mkdir -p ~/.openclaw/workspace/skills/paper-summarizer
nano ~/.openclaw/workspace/skills/paper-summarizer/SKILL.md

Example SKILL.md:

---
name: paper_summarizer
# 
description: Summarize research papers and route small PDFs locally, large PDFs to Hulk.
---

# Paper Summarizer

When the user asks to summarize a technical/research PDF:

1. Determine the paper size:
   - Prefer page count if available.
   - If page count is unknown, estimate from extracted text/token size.

2. Routing:
   - If the paper is <= 5 pages, use the local model:
     `local-small/small-tech-model`
   - If the paper is > 5 pages, use the Hulk model:
# 
     `hulk-large/large-research-model`
   - For large papers, prefer spawning a sub-agent so the main chat stays responsive.

3. Use the `pdf` tool for PDF analysis.

4. Output format:
   - TL;DR
   - Main contribution
   - Key methods
   - Important results
   - Limitations
   - Practical implications
   - Questions/follow-ups

Then reload:

# 
{
  agents: {
    list: [
      {
        id: "main",
        default: true,
        workspace: "~/.openclaw/workspace",
        model: "local-small/small-tech-model",
        pdfModel: "local-small/small-tech-model",
        subagents: {
          allowAgents: ["main", "hulk-research"]
        }
      },
      {
        id: "hulk-research",
# 
        workspace: "~/.openclaw/workspace-hulk-research",
        model: "hulk-large/large-research-model",
        pdfModel: "hulk-large/large-research-model",
        skills: ["paper_summarizer"]
      }
    ]
  }
}

Then for a large paper you can run:

/subagents spawn hulk-research Summarize this technical paper using the paper_summarizer skill. Return TL;DR, methods, results, limitations, and practical implications.
#

If you don’t want a separate agent, you can also spawn the same agent with a model override:

/subagents spawn main Summarize this large paper in detail. --model hulk-large/large-research-model

Docs: https://docs.openclaw.ai/tools/subagents and https://docs.openclaw.ai/concepts/multi-agent

My recommendation

Use:

  • Custom skill = routing instructions and summary format.
  • Main agent = local/small model default.
  • hulk-research sub-agent = large model default.
  • No node connection unless you need to run shell commands/files directly on Hulk.
#

If /subagents is not available, check /tools. You may need to allow sub-agent tools or use a coding/full tool profile.

Also, if config examples don’t work exactly, paste openclaw --version first — config details move quickly.

golden sleet
#

Is sub-agents really required here?

Give me the best recommendation for my use case overall.What is the archetecture? what should I need to have? what runs where?

How the page count determined if unknown. How the token size of paper is calculated ? From where?

How it is used in routing mechanism inside custom skill ?

pliant badgeBOT
#

No — sub-agents are not required for your routing requirement.

My best recommendation: single main agent + custom skill + small local “preflight” script + explicit model override. Add sub-agents later only if large-paper summaries make the chat feel blocked.

Best architecture

Runs on Local PC:

  • OpenClaw Gateway
  • Discord/Telegram/UI session
  • PDF upload/storage
  • Page/token preflight script
  • Small local LLM endpoint
  • Custom skill logic

Runs on Hulk:

  • Large LLM server only, exposed as an OpenAI-compatible/vLLM/SGLang/Ollama endpoint.
#

Flow:

User uploads PDF
        ↓
OpenClaw Gateway on Local PC receives it
        ↓
custom skill runs preflight:
  page_count + extracted_text_token_estimate
        ↓
routing decision:
  small → local-small/model
  large/unknown → hulk-large/model
        ↓
OpenClaw pdf tool summarizes using selected model
        ↓
# 
reply back in chat

No node connection needed. No distributed filesystem needed. Hulk just needs to expose an API endpoint reachable from the Local PC.

How page count is determined

Best option: use a local preflight script on the Gateway machine.

It can use one of:

pdfinfo paper.pdf

or Python libraries like:

# 
pypdf
pymupdf

The script reads the uploaded/local PDF and returns:

{
  "pages": 4,
  "text_chars": 18500,
  "estimated_tokens": 4600,
  "route": "local"
}

If page count cannot be determined, route to Hulk by default. That’s the safer rule.

#

How token size is calculated

Token size comes from extracted PDF text, before summarization.

Simple estimate:

estimated_tokens = text_characters / 4

Better estimate: use a tokenizer such as tiktoken, but rough char/4 is usually enough for routing.

So the routing script does:

  1. Extract text from PDF.
  2. Count characters.
  3. Estimate tokens.
#
  1. Compare against thresholds.

Example rule:

Use local if:
  pages <= 5
  AND estimated_tokens <= 8000

Otherwise:
  use Hulk

I’d use both page count and token estimate, not page count alone. A 4-page dense math paper can be harder than a 12-page slide-style PDF.

How the skill uses routing

#

Important nuance: a skill is mostly instructions, not a deterministic router by itself.

So the reliable pattern is:

Skill tells agent:
1. Run the preflight helper script on the PDF.
2. Read the JSON result.
3. If route=local, call pdf with model="local-small/..."
4. If route=hulk, call pdf with model="hulk-large/..."

Example skill instruction:

When summarizing a PDF:
# 
1. Run `{baseDir}/paper_preflight.py <pdf_path>`.
2. Parse the JSON output.
3. If `route` is `local`, use model `local-small/small-tech-model`.
4. If `route` is `hulk`, use model `hulk-large/large-research-model`.
5. Call the `pdf` tool with that explicit model.

That gives you predictable behavior.

Final recommendation

Start with no sub-agent.

Use:

  • one OpenClaw Gateway on Local PC
  • two configured model providers: local + Hulk
golden sleet
#

Is there any specific tool/skill that I can use to read the paper and summarize it?

pliant badgeBOT
#

Yes: use the built-in pdf tool.

For your setup, the simplest pattern is:

Upload/provide PDF → OpenClaw `pdf` tool reads/extracts it → selected LLM summarizes it

Example request:

Summarize this PDF. Include TL;DR, main contribution, methods, results, limitations, and practical implications.

If you want to force Hulk:

# 
Summarize this PDF using model hulk-large/large-research-model.

For custom/local model providers, the pdf tool usually uses extraction fallback: OpenClaw extracts the PDF text locally, then sends the extracted content to your selected model.

For your routing workflow, create a small custom skill like paper_summarizer that says:

  • Use pdf for reading/summarizing papers.
  • If small paper → call pdf with local model.
  • If large paper → call pdf with Hulk model.
  • Return a fixed research-summary format.

So: specific tool = pdf tool.
specific skill = custom paper_summarizer skill wrapping the pdf tool.

Docs:

golden sleet
#

Do I really need a tool to summarize large pdf or my setup will take care of it?

What you recommend? Do I need to introduce a external skill/tool that performs summarizations? do you have any free tool like that?

pliant badgeBOT
#

You do not need an external summarization tool for the normal case.

Use OpenClaw’s built-in pdf tool + your configured models. Your setup handles the actual summarization as long as:

  • the PDF can be read/extracted,
  • the selected model has enough context,
  • pdfMaxPages / pdfMaxBytesMb are configured high enough for your use case.

What OpenClaw will not automatically know is your custom rule:

“If <= 5 pages use Local, otherwise use Hulk.”

For that, I’d add a custom skill, not an external summarizer.

My recommendation

Use this architecture:

# 
OpenClaw pdf tool
  + custom paper_summarizer skill
  + Local model provider
  + Hulk model provider

No external summarizer needed.

The skill should only do routing/instructions:

1. Check paper size.
2. Small paper → use local-small/model.
3. Large paper → use hulk-large/model.
4. Call OpenClaw pdf tool with the selected model.
# 
5. Format the summary.

When would you need an extra tool?

Only for pre-processing, not summarization.

Useful free/open-source helpers:

  • pdfinfo — page count
  • pdftotext — extract text
  • Python pypdf — page count/text extraction
  • Python PyMuPDF / fitz — stronger PDF extraction
  • tiktoken or rough chars / 4 — token estimate

These are just helpers for routing/chunking. The LLM still summarizes.

#

For very large PDFs

If papers are huge, don’t send the whole thing in one go. Use a map-reduce style workflow:

Extract/chunk paper
  ↓
Summarize each chunk with Hulk
  ↓
Combine chunk summaries into final summary

That can be described in your custom skill too.

Bottom line

  • No external summarizer: not needed.
golden sleet
#

can i place the openclaw gateway on Hulk machine ?

If I change the gateway location what are the benefits I get

pliant badgeBOT
#

Yes — you can place the OpenClaw Gateway on Hulk.

But I’d frame it like this:

OpenClaw Gateway should live on the machine that you want to be the “control plane.”
That machine owns:

  • sessions / memory / workspace
  • uploaded files
  • channel connections
  • cron / background tasks
  • model routing
  • default filesystem access

So if Hulk is always-on, powerful, and already hosts the large LLM, then putting the Gateway on Hulk is a good architecture.

Benefits:

#

  1. Lower latency to the large model
    If Hulk’s LLM is local to Hulk, OpenClaw can call it via 127.0.0.1 / local network instead of sending big prompts across machines.

  2. Better for large PDFs / research jobs
    Uploaded docs, extraction, chunking, summaries, and long-running tasks happen on Hulk instead of your smaller PC.

  3. Always-on assistant
    If Hulk stays running, OpenClaw keeps working even when your local PC sleeps.

  4. Cleaner architecture
    One central Gateway + optional nodes is the OpenClaw best-practice pattern.

  5. Local PC can become a node
    If you still need local PC browser/files/commands, pair it as a node instead of running a second Gateway.

Important tradeoff: if the Gateway moves to Hulk, then localhost means Hulk, not your local PC. So your small local model on the PC must be exposed over LAN/Tailscale, or you keep the Gateway on the PC.

golden sleet
#

Let say I have a lightweight LLM hosted on my Local PC using a custom host and port?
Can I able to connect it to the openclaw gateway.

Please assume there is already a heavy llm is running on remote Hulk machine along with openclaw instance

pliant badgeBOT
#

Yes — Hulk’s OpenClaw Gateway can call a lightweight LLM running on your Local PC, as long as Hulk can reach it over the network.

Key rule:

localhost from the Gateway means Hulk, not your Local PC.

So if the small model is on your PC, configure Hulk’s OpenClaw with something like:

{
  models: {
    mode: "merge",
    providers: {
      localpc: {
        baseUrl: "http://local-pc-tailnet-name:8000/v1",
        apiKey: "sk-local",
# 
        api: "openai-completions",
        request: { allowPrivateNetwork: true },
        timeoutSeconds: 180,
        models: [
          {
            id: "small-paper-model",
            name: "Local PC Small Paper Model",
            reasoning: false,
            input: ["text"],
            cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
            contextWindow: 32768,
            maxTokens: 4096
          }
        ]
      }
# 
    }
  }
}

Then the model reference becomes:

localpc/small-paper-model

Recommended architecture:

Discord / Chat
# 
   ↓
OpenClaw Gateway on Hulk
   ├── Hulk heavy LLM via http://127.0.0.1:PORT/v1
   └── Local PC small LLM via http://local-pc:PORT/v1

Use Tailscale/LAN/VPN, not public internet. If the Local PC model does not expose an OpenAI-compatible /v1/chat/completions API, put a small proxy like LiteLLM/custom adapter in front of it.

For your paper workflow:

  • ≤ 4–5 pages: route to localpc/small-paper-model
  • larger / complex PDFs: route to Hulk’s heavy model
  • No shared filesystem is required; the Gateway on Hulk owns uploads/workspace. The Local PC model just receives prompts over HTTP.
  • A node connection is not required for model calls. Nodes are for local PC tools like shell/browser/screen/camera.

Best practice: one Gateway on Hulk + both models configured as providers + optional Local PC node only if you need PC tools.