AI CRM for M4 Mac: Benchmarks and Performance

DenchClaw running on M4 Mac is fast — DuckDB queries in milliseconds, agent responses in seconds, browser automation smooth and snappy. Here's what you can expect.

Mark Rachapoom
Mark Rachapoom
·7 min read
AI CRM for M4 Mac: Benchmarks and Performance

The case for a local-first CRM has always been partly about performance — no network latency, no server cold starts, no database round-trips to a distant data center. Running DenchClaw on an M4 Mac makes this case exceptionally well.

Here's a realistic look at what you can expect: query performance, agent response times, memory usage, and how DenchClaw fits into the M4's architecture.

Why M4 Changes the Calculus#

The M4 chip family (M4, M4 Pro, M4 Max) brings several characteristics that directly benefit a local AI CRM:

Unified Memory Architecture: CPU, GPU, and Neural Engine share the same memory pool. This means DuckDB queries, the Node.js agent runtime, and Chromium (for browser automation) aren't fighting for separate memory pools with slow transfers between them. On a MacBook Pro M4 Max with 128GB unified memory, you can run DenchClaw, a browser agent with multiple tabs, your development environment, and several subagent sessions simultaneously without paging.

Neural Engine: The 38-TOPS Neural Engine in M4 Max accelerates on-device AI inference. While DenchClaw currently delegates LLM calls to cloud APIs (Anthropic, OpenAI), the Neural Engine benefits local embedding models — used for semantic search and the RAG layer.

NEON SIMD: DuckDB's vectorized execution engine benefits from ARM SIMD instructions. Column scans and aggregations run efficiently on M4's vector units.

NVMe SSD Speed: Even the base M4 MacBook Pro gets ~4GB/s NVMe read speeds. DuckDB's columnar format is I/O-efficient, but fast NVMe means even cold-query performance is good.

Query Performance Benchmarks#

Tested on M4 Pro MacBook Pro (14-core CPU, 24GB unified memory), with a DenchClaw workspace containing:

  • 5,000 people entries
  • 1,200 companies
  • 800 deals
  • ~200 entry documents

Simple lookups:

-- Find a contact by email
SELECT * FROM v_people WHERE "Email" = 'sarah@stripe.com';
-- Result: 0.8ms

Filtered table view (what renders when you click a saved view):

SELECT "Full Name", "Email", "Company", "Status", "Last Contacted"
FROM v_people
WHERE "Status" = 'Lead'
ORDER BY "Last Contacted" ASC NULLS FIRST;
-- 3,000 rows in 12ms

Pipeline aggregation:

SELECT "Stage", COUNT(*) as deals, SUM(CAST("Value" AS NUMERIC)) as total
FROM v_deals
GROUP BY "Stage";
-- 800 rows → 6 aggregate rows in 3ms

Cross-object join (deals with company details):

SELECT d."Title", d."Value", d."Stage", c."Name" as company, p."Full Name" as contact
FROM v_deals d
LEFT JOIN v_companies c ON d."Company" = c.id::VARCHAR
LEFT JOIN v_people p ON d."Contact" = p.id::VARCHAR
WHERE d."Stage" NOT IN ('Closed Won', 'Closed Lost')
ORDER BY CAST(d."Value" AS NUMERIC) DESC;
-- 650 rows in 18ms

Full-text search (agent finding a contact by partial name):

SELECT "Full Name", "Email", "Company"
FROM v_people
WHERE lower("Full Name") LIKE '%sarah%'
   OR lower("Email") LIKE '%sarah%';
-- 47 matches in 8ms

At 100,000 entries (a large enterprise CRM), most queries still complete under 100ms. At 1,000,000 entries, simple filtered queries return in 200-400ms.

Agent Response Times#

End-to-end time from you typing a query to the agent's complete response:

Query typeTime
Simple fact lookup ("how many leads do I have?")2.1s
Filtered view ("show leads from SF, sorted by date")2.8s
Complex analysis ("summarize my pipeline health")4.2s
Creating a new entry3.1s
Building a custom view3.8s
Generating a report with chart5.1s

The dominant time cost is the LLM API call (Anthropic Claude round-trip: ~1.5-2s). DuckDB execution is a tiny fraction of the total. If you configure a local Ollama model, you trade output quality for faster response at the cost of the network call.

Memory Usage#

DenchClaw's memory footprint on a fresh installation:

ProcessRAM
OpenClaw gateway (Node.js)~180MB
DuckDB (loaded database)~45MB (5K entries)
Web frontend (browser tab)~120MB
Total~345MB

With browser agent active (Chromium running):

  • Add ~400MB for Chromium base
  • Add ~80MB per open tab

On an M4 MacBook Pro with 16GB+ unified memory, this is invisible in daily use.

DuckDB's memory usage scales with query complexity, not database size. Running a large aggregation query temporarily uses ~200-400MB; it's released when the query completes.

Startup Time#

After initial installation, subsequent starts:

StepTime
OpenClaw gateway start1.2s
DuckDB connection open0.1s
Web frontend load0.8s
First interaction ready~2.3s total

DenchClaw can be configured to start at login via launchctl, so localhost:3100 is available immediately when you open your browser.

Battery Impact#

On M4 MacBook Pro (plugged-in idle, DenchClaw running in background, no active queries):

  • CPU: ~0.5-2% (mostly event loop polling)
  • Memory: ~345MB baseline
  • Battery impact: Negligible (comparable to having a browser tab open)

During active use (agent responding, DuckDB queries, browser agent running):

  • CPU: 15-40% during active processing
  • Returns to baseline within seconds of completion

The M4's efficiency cores handle the DenchClaw idle processes. You won't notice it on battery.

Running Multiple Subagents#

DenchClaw can spawn multiple subagent sessions for parallel work. On M4 Max:

  • 5 concurrent subagents: comfortable, ~1.5GB RAM total
  • 10 concurrent subagents: workable, ~3GB RAM
  • Each subagent adds ~200-250MB and some CPU during active execution

The M4 Max's 14-core CPU handles parallel workloads well. Subagents waiting on LLM API calls (which is most of the time) use near-zero CPU.

Comparison: Local vs. Cloud CRM Performance#

MetricDenchClaw (M4)SaaS CRM
Simple query<10ms100-800ms
Complex aggregation<100ms500-2000ms
Page load<500ms1-4s
Works offline
Network dependencyOnly AI callsEverything

The local performance advantage is real and noticeable. SaaS CRMs have network latency, server-side processing queues, and shared infrastructure bottlenecks. A local DuckDB query just... runs, instantly.

Frequently Asked Questions#

Does DenchClaw use the M4's Neural Engine?#

Currently, LLM inference is cloud-based. The Neural Engine benefits local embedding models for semantic search. Future roadmap includes on-device LLM support via Ollama, which will leverage the Neural Engine more heavily.

Will DenchClaw work on older Macs (Intel)?#

Yes. DenchClaw supports macOS 12+ on both Intel and Apple Silicon. Performance on Intel is still good — DuckDB is well-optimized for x86 — but unified memory benefits are Apple Silicon-specific.

Does the browser profile copy work on M4?#

Yes. The Chrome profile copy works on M4 Macs exactly as on Intel. The browser agent uses Chromium's ARM build.

How much disk space does DenchClaw use?#

The OpenClaw runtime: ~150MB. The DenchClaw workspace (database, skills, apps): starts at ~20MB, grows with your data. A full workspace with thousands of entries and documents is typically 100-500MB.

Can I run DenchClaw on an M4 iPad (via Sequoia)?#

Not directly — DenchClaw requires Node.js which isn't available on iOS/iPadOS natively. Dench Cloud (dench.com) provides iPad access via the managed hosting option.

Ready to try DenchClaw? Install in one command: npx denchclaw. Full setup guide →

Related articles

Keep reading

View all