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.
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.8msFiltered 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 12msPipeline 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 3msCross-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 18msFull-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 8msAt 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 type | Time |
|---|---|
| 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 entry | 3.1s |
| Building a custom view | 3.8s |
| Generating a report with chart | 5.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:
| Process | RAM |
|---|---|
| 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:
| Step | Time |
|---|---|
| OpenClaw gateway start | 1.2s |
| DuckDB connection open | 0.1s |
| Web frontend load | 0.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#
| Metric | DenchClaw (M4) | SaaS CRM |
|---|---|---|
| Simple query | <10ms | 100-800ms |
| Complex aggregation | <100ms | 500-2000ms |
| Page load | <500ms | 1-4s |
| Works offline | ✅ | ❌ |
| Network dependency | Only AI calls | Everything |
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 →