app

SOLIDWORKS Bridge

Public Made by Adom

by adom

Launch, model and quit SOLIDWORKS from any Adom container. Nothing is ever lost.

solidworksmcadcadbombridgeabadom-bridgedesktop-app
Overview Files Skills Discover Packages Releases Dependencies Issues2 Breadcrumbs Pull Requests Activity
main
solidworks-bridge / skills / solidworks-memory / SKILL.md
History Download
Drew Owens 0.10.9 source 32473a3 6d ago

name: solidworks-memory description: "How to keep SOLIDWORKS from running a Windows PC out of memory while an AI drives it - what the SOLIDWORKS Resource Monitor 'available committed memory is critically low' warning means, why SOLIDWORKS keeps memory after documents close, how to read the bridge's memory report before and during long runs, when and how to recycle a bridge-started session safely, and what never to close. Use before any long or repeated SOLIDWORKS run (test batteries, many new parts, batch exports, renders), whenever swx_status reports low commit memory, and whenever the user mentions the Resource Monitor warning, low memory, commit charge, SOLIDWORKS slowing down or a PC running out of memory. Trigger words - solidworks memory, resource monitor, committed memory critically low, commit charge, out of memory, low memory warning, solidworks slow, memory leak, recycle solidworks, long run, test battery, many parts."

Parent skill: solidworks-bridge

Keeping SOLIDWORKS from running the PC out of memory

What the warning means

  • [measured] The SOLIDWORKS Resource Monitor toast "Available committed memory is critically low. Close some applications immediately to reduce the commit charge" is about committed memory (the commit charge against the commit limit: RAM plus the page file), not free RAM. A PC can show gigabytes of free RAM and still be out of commit.
  • [measured] On 2026-10-14 it fired on a 31.4 GB laptop at 72.3 of 76.6 GB committed (94 %). The biggest holders were Fusion 360 (20.7 GB, running two days), SOLIDWORKS (10.6 GB), Chrome (10.2 GB over 51 processes) and WSL (4.7 GB).
  • Running out of commit makes allocations fail in every application, not only SOLIDWORKS: unsaved work anywhere on the machine is at risk. Treat the warning as urgent.

Why an AI-driven session grows

  • [measured] SOLIDWORKS does not give memory back when documents close. A session the bridge started for a test run held 10.6 GB committed with zero documents open, after roughly a hundred scratch parts were built and closed in it (about 100 MB per part).
  • [measured] Quitting that session through the bridge (swx_stop) returned about 16 GB of commit (72.3 to 56.1 GB): SOLIDWORKS plus its helper processes.
  • So the cost is per document created in the session, not per document open. Long runs (test batteries, swx_selftest {"level":"write"}, batch exports, many new_part scripts) are what fill the machine.

The measured curve, and what causes it

  • [measured] 2026-10-14 (hosted bridge 0.10.5, a freshly started SOLIDWORKS 2026): 12 times new_part plus a 20 x 20 x 10 mm box, then swx_reset_workspace, sampled after every close with swx_status.memory and GetDocumentCount. SOLIDWORKS's private bytes went 520 MB, 913 after part 1, 1191 after part 2, then a straight line of +83 MB per part to 2035 MB after 12. Its handle count went 2845 to 4539, about +125 per part, also linear. GetDocumentCount was 0 after every close: no hidden documents linger. Re-measured with 0.10.6: 538 to 1697 MB over 8 new parts (+85 MB and +125 handles each).
  • [measured] Reusing ONE document is the fix. Bridge 0.10.6: one visible part made with swx_new_document, then 12 builds with swx_run_script {"reuseDocument": <its path>} (each build's new_part becomes clear_part). Private bytes went 3260 to 3246 MB, handles 4373 to 4398, over all 12 builds: no growth at all.
  • [measured] Hidden documents cannot be modelled. A part created with visible:false (ISldWorks::DocumentVisible) cannot be activated: modelling it failed "could not activate 'Part1'". SOLIDWORKS selects only in the active document, and every modelling step selects something (a plane, a sketch, an edge, a face), so hiding is not a memory fix for modelling. From 0.10.7 the bridge refuses that up front (document_hidden) and makes everything visible by default.
  • [measured] The bridge does not pin the documents. swx_com_respawn (it restarts only the bridge's COM host, releasing every reference it holds, and never calls SOLIDWORKS) did not lower the handle count (4022 to 4056). So the per-document cost is SOLIDWORKS's own, kept until SOLIDWORKS restarts.
  • [measured] A respawn is not a saving to rely on. It freed 210 MB once (1697 to 1487 MB) and 0 MB once (2361 to 2361 MB, at the end of a full self-test). The self-test still ends with one, as hygiene, and reports what it freed.
  • [measured] A full self-test with one reused document (bridge 0.10.7, 2026-10-14): 15 documents instead of more than 32. SOLIDWORKS went from 507 MB to 2361 MB (a peak of 3922 MB while checks had parts open), handles from 2809 to 5122. Commit stayed "ok" (61.7 % to 70.0 %), nothing was throttled, and nothing was recycled.
  • [measured, unexplained] Creating the reuse part once raised SOLIDWORKS's private bytes from 1487 to 3437 MB (+1.95 GB) while it was open. After it was closed, SOLIDWORKS held 1772 MB, 285 MB more than before it was created. This happened once and has no explanation yet; record it if you see it again.

The incident that made the presence rule symmetric

  • [measured] 2026-10-14, hosted 0.10.7, Drew at the keyboard (closing Fusion) during a battery. From 23:19:32Z every swx_reset_workspace was refused for his presence (17 in a row), while every swx_run_script with new_part was allowed (18 parts). 18 of the bridge's unsaved scratch windows piled up on his screen.
  • Check times went from 14 s to 39 s, then a 7-minute stall. SOLIDWORKS reached 15.1 GB, the machine reached 91 % committed, and the session could not be quit the next morning, because documents were still open.
  • From 0.10.9 the rule runs both ways. While the user is at the machine, the bridge does not create documents for its own purposes: the self-test and batteries wait, then refuse with user_present. swx_reset_workspace closes the bridge's own scratch even while the user is present, except the active document. A battery that sees documentsLeftOpen, or a refused close, stops.

The rules

  1. Read memory before a long run, and between its steps. swx_status reports a memory block (commit used, limit and available; SOLIDWORKS's own committed bytes and handles; the largest holders). [measured: SOLIDWORKS's private bytes and handle count, read through the 12-part run on 2026-10-14] [unmeasured: the pressure verdict and the largest-holders list] If commit is CRITICAL before you start, do not start: tell the user what holds the memory. HIGH pressure held by other applications is not a reason to stop a run that reuses one document: it keeps SOLIDWORKS flat (measured).
  2. Recycle a session the bridge started, never one the user is working in. [measured] On the 3DEXPERIENCE edition 0.10.6 never recognised its own launch (attributedSolidworks was null). [measured, 2026-10-14] From 0.10.7 it does: swx_status.launch.attributedSolidworks.how read "ancestry" after a bridge launch; the one new sldworks.exe of the launch window is the fallback when ancestry cannot reach it. When SOLIDWORKS's OWN commit passes a budget (6 GB is a sensible default on a 32 GB PC), or commit is critical and SOLIDWORKS holds a real share of it, and the session was started by the bridge and has zero documents open: swx_stop {"userAuthorized": true, "reason": ...} then swx_start (1-3 minutes on a 3DEXPERIENCE edition). swx_stop refuses on its own when documents are open or the user is active; never work around that refusal.
  3. Close what you made as you go. swx_reset_workspace after each scratch document, or let the script close it. Closing does not free the memory, but it keeps the session recyclable.
  4. Never close the user's applications. Not Fusion, not the browser, not anything else, however much it holds. Report the largest holders with their sizes and let the user decide. Restarting a long-running Fusion or browser is the user's call.
  5. Never change the page file or SOLIDWORKS settings to make room. Those are the user's. (The bridge's hidden creation flips one session setting, DocumentVisible, for one NewDocument call and puts it back straight away, even when the creation fails. It never leaves it changed, and it ledgers both the flip and the restore.)
  6. Batch work reuses one document (flat); never one new part per item. New documents cost about 85 MB and 125 handles each until SOLIDWORKS restarts; builds in one reused document cost nothing (measured). Make ONE visible part with swx_new_document, then run each script with "reuseDocument": "<its path>". Its leading new_part becomes clear_part, which deletes every feature after the origin, and only in a part the bridge created. clear_part repeats its delete until the part is empty (0.10.8: measured, one pass left a sketch an earlier failed step had not used up). If the part still will not clear, the self-test runs that check in a fresh part instead of failing it, and the row says so (reuseFallback). swx_selftest {"level":"write"} does all this itself, reports documentsCreated, and ends by respawning the bridge's COM host (comRespawn.freedMb). [unmeasured] Between checks, the self-test recycles the bridge's own empty session only when SOLIDWORKS ITSELF is over its budget (the recycled list says when). It stops only when commit is critical, or when SOLIDWORKS is over budget in a session it may not end. High commit held by other applications is reported (memoryPressureSeen) and does not stop it.
  7. A refusal is not an obstacle to route around. [unmeasured] While commit is critical, verbs that create or load geometry answer low_commit_memory and change nothing; the reply names the holders and the safe remedy. ignoreMemoryPressure:true with a reason runs the verb anyway and is ledgered: use it only when the user says so.
  8. Hidden documents can't be modelled. [measured] visible:false creates a document SOLIDWORKS cannot activate, and every modelling step needs the active document, so swx_run_script refuses to model one (document_hidden). Everything is visible by default, including the self-test's parts. Use visible:false only for a document that is created to be saved or exported, never modelled.

Diagnosing by hand (read-only)

The commit numbers Windows shows in Task Manager > Performance > Memory as "Committed". From the container, a read-only PowerShell over ab can read Win32_PerfFormattedData_PerfOS_Memory (CommittedBytes, CommitLimit, PercentCommittedBytesInUse) and the top processes by PrivateMemorySize64. Report the numbers; change nothing.