Standarized save memory regex between the this plugin and my other model dependent and context cleanup plugins.

Imported the more advanced acquirelock(current this plugin has a basic need of acquirelock but it's for future proof) and my improved ICID and CFN scan logics.

Loosened some constraints on a failing save memory condition where user's message was a save command or meta data that was fully scrubbed. Fixed the placement of the input scrubbing, I was cleaning the input too early in the chain. Loosening it so it would not be corrected at the first step but at the last step.

Moved some variables to module-level states living in config.ts

The following isn't new but I never specifically went over them and think users should know the leeway and options they have for the spelling of the save command.

(Example: svmem4 will be accepted and so will with store mmry msg4. the category is apple). Batch memory save requires a variation of through/to as a trigger and ending message number

Click to expand Picture of Save Memory command verbage

User says: save memory #, category <category_name>, name <memory_name>

• save memory message # works too.
• Usable delimiters are ; or , or .
• Keywords required as a prefix to be included are category and/or name.

If category and/or name are not provided during the initial user message, the user will be asked in the following assistant message.

Click to expand image of the exiting Save Memory Mode

Multi-Edit Coordinator: This coordinator now oversees the write actions, so there are not multiple read/write actions repeated to fulfill one request at a time. Now that responsibilities were taken away from the model serving as the middleman, these things must be explicitly handled in the backend. I had to refactor a lot of existing code into functions usable by the coordinator, but it was better than rewriting all the logics from scratch. Trade-off: a little more obscurity in the flow of each function, but I did my best trying to communicate ambiguity with descriptive function names and comments left behind.

file_name-persisting-memories-final-write.ready is now a coordination file created within the conversation folder to let PM catch up to the CC plugin and take the lead at executing its functions first. Persisting Memories plugin creates the .ready; Context Cleanup is expected to remove it. There may be abandoned .ready leftover files if your model crashes — they're 0KB so they just exist without any actual content. You may want to manually clean up any abandoned .ready files if you wish they're no longer relevant. Putting an automatic cleaner in one of the plugins would be unnecessary overhead.

file_name.lock: Lock files were added for cross-plugin compatibility with my Context Cleanup tool. This counters race conditions while a conversation.json is being updated/modified (written) — the lock makes the loser wait for its turn while the winner gets priority to complete their task.

Removal polling: When triggering memory seed edits, appending message # to the assistant message, and save memory commands that are missing fields to be provided, polls the conversation file every 100ms or 500ms depending on the condition if the .lock file originated from another plugin or its own plugin. The more aggressive polling is when the .lock belonged to another plugin — this way this plugin can act quicker to an external .lock release.

A memories folder will be created at C:\Users\USERNAME\.lmstudio, and a .json file that retains the relationship between the chat session and its conversation file will be stored in C:\Users\USERNAME\.lmstudio\conversations.

Injection markers: Memories will be injected within blocks of BEGIN and END markers containing the memory seed category/memory_name. These markers allow for later removal of the memory.

Internal Chat ID: The preprocessor will append a one-time InternalChatID [ICID] to mark the chat session. This marker helps identify the session and tie it to the corresponding conversation file. I've added fail-safes to recover the [ICID] marker when users purposely or accidentally delete the user message which contained the tag.

Conversation mapping: The plugin stores a relationship file that maps internal chat IDs to conversation file names. It keeps only the newest 15 relationships. C:\Users\USERNAME\.lmstudio\conversations\ChatSessionConversationRelationship.json

LM Studio also reinitializes plugins whenever it decides to, so reliable long-term storage of variables in outer scopes is not fully reliable and just used temporarily for the turn or as long as they're available. That includes storing current values in the Config Schematics. When values are lost, the backend code will re-establish them when needed.

Path safety: Memory names are normalized, but not to correct misspellings. It's easiest to copy and paste the memory name from the list displayed in Available Memories into the text field of Memories to Inject.

In-memory pool: The available memory pool is kept in memory and updated when files are deleted. Plugin UI updates may be delayed because of LM Studio plugin behavior, but on the backend these values are properly updated.

I had only 3 options to fully execute this: rely on the unreliable model, modify the conversation.json real-time, or use predictionLoopHandler.

• PredictionLoopHandler was a complete flop — it overtook and dictated its own custom structure, making it less widely compatible and affecting tool calls. The time spent experimenting wasn't wasted though and did play a very small part in my final route.
• Rely on the unreliable model — that was my original "easier" approach. On most days the model worked fine; on bad days it refused to comply with instructions and everything important became suggestions up to self-interpretation, finding leeway in definitive language, and repeated patterns became established rules rather than actually following the rules given.
• Real-time conversation.json editing — the most complex method which had to respect what already is and build around the flaws and natively lacking features. The only downside to this was the 2-second time window mandatory at the last token of the assistant's response. It's really imperceptible in real-world situations. The signifier that the backend has completed is when you see a message # appended after the assistant's message. If you mess it up, no harm no foul — the backend logic won't break and things will continue fine in future turns.

The multi-edit coordinator I created is a key part to this working with less overhead. Instead of independently executing individual write functions one by one with each one carrying sometimes duplicated overhead, the coordinator figures out which functions want to execute, gathers their parameters, and does it all in one chained action. I had to refactor a lot of existing code into functions usable by the coordinator, but it was better than rewriting all the logics all over again. Trade-off: a little more obscurity in the flow of each function, but I did my best trying to communicate ambiguity with descriptive function names and comments left behind.

The file lock I created is key to letting this plugin work with my other cleanup plugin. If other plugins utilize the same file locking mechanic, this would be compatible with those plugins too. The .ready file is also key to forcing Context Cleanup to give priority of execution to Persisting Memories — otherwise CC reaches the lock creation 5–8ms faster on my system which may cause bugs like cleaning up messages that were required for the memory creation/associations.

Why is there a toolsProvider.ts even if these explicit functions aren't handled by tools anymore? LM Studio did not give me a native way to poll changes real-time to the Delete Memory text field — promptPreprocessor is limited to when the user fires off a new user message so it doesn't work. The only way to achieve real-time variable monitoring was to keep the toolsProvider enabled and letting the memory deletion trigger logic exist there.

Injected context will be hidden from the user, but visible to the assistant. User can ask the assistant to read out the injected memory if you wish to see it.

LM Studio's SDK does not have full support to make this implementation easy. The methods chosen to accomplish this feature were mandatory during the time of creation of this plugin.

The plugin assumes LM Studio Windows 11 conversation files are accessible under the configured root directory at C:\Users\USERNAME\.lmstudio\conversations.

The Memory bubbles displayed on the plugin do not update real-time. Again, another limitation of LM Studio not giving a way to send updated data upstream back to the plugin UI. The memory bubbles will update when the tool reinitializes, so when it's left idle for awhile then interacted with, or if you click the trashcan "reset" button. There are already validation checks in the backend to prevent any bugs, so don't worry about it. If you choose memories that aren't available, nothing will happen. If you add, remove, or delete memories that aren't active or exist, nothing will break — it'll just be a visual bug of the UI that will refresh upon its next initialization.

Standarized save memory regex between the this plugin and my other model dependent and context cleanup plugins.

Imported the more advanced acquirelock(current this plugin has a basic need of acquirelock but it's for future proof) and my improved ICID and CFN scan logics.

Loosened some constraints on a failing save memory condition where user's message was a save command or meta data that was fully scrubbed. Fixed the placement of the input scrubbing, I was cleaning the input too early in the chain. Loosening it so it would not be corrected at the first step but at the last step.

Moved some variables to module-level states living in config.ts

The following isn't new but I never specifically went over them and think users should know the leeway and options they have for the spelling of the save command.

(Example: svmem4 will be accepted and so will with store mmry msg4. the category is apple). Batch memory save requires a variation of through/to as a trigger and ending message number

Click to expand Picture of Save Memory command verbage

User says: save memory #, category <category_name>, name <memory_name>

• save memory message # works too.
• Usable delimiters are ; or , or .
• Keywords required as a prefix to be included are category and/or name.

If category and/or name are not provided during the initial user message, the user will be asked in the following assistant message.

Click to expand image of the exiting Save Memory Mode

Multi-Edit Coordinator: This coordinator now oversees the write actions, so there are not multiple read/write actions repeated to fulfill one request at a time. Now that responsibilities were taken away from the model serving as the middleman, these things must be explicitly handled in the backend. I had to refactor a lot of existing code into functions usable by the coordinator, but it was better than rewriting all the logics from scratch. Trade-off: a little more obscurity in the flow of each function, but I did my best trying to communicate ambiguity with descriptive function names and comments left behind.

file_name-persisting-memories-final-write.ready is now a coordination file created within the conversation folder to let PM catch up to the CC plugin and take the lead at executing its functions first. Persisting Memories plugin creates the .ready; Context Cleanup is expected to remove it. There may be abandoned .ready leftover files if your model crashes — they're 0KB so they just exist without any actual content. You may want to manually clean up any abandoned .ready files if you wish they're no longer relevant. Putting an automatic cleaner in one of the plugins would be unnecessary overhead.

file_name.lock: Lock files were added for cross-plugin compatibility with my Context Cleanup tool. This counters race conditions while a conversation.json is being updated/modified (written) — the lock makes the loser wait for its turn while the winner gets priority to complete their task.

Removal polling: When triggering memory seed edits, appending message # to the assistant message, and save memory commands that are missing fields to be provided, polls the conversation file every 100ms or 500ms depending on the condition if the .lock file originated from another plugin or its own plugin. The more aggressive polling is when the .lock belonged to another plugin — this way this plugin can act quicker to an external .lock release.

A memories folder will be created at C:\Users\USERNAME\.lmstudio, and a .json file that retains the relationship between the chat session and its conversation file will be stored in C:\Users\USERNAME\.lmstudio\conversations.

Injection markers: Memories will be injected within blocks of BEGIN and END markers containing the memory seed category/memory_name. These markers allow for later removal of the memory.

Internal Chat ID: The preprocessor will append a one-time InternalChatID [ICID] to mark the chat session. This marker helps identify the session and tie it to the corresponding conversation file. I've added fail-safes to recover the [ICID] marker when users purposely or accidentally delete the user message which contained the tag.

Conversation mapping: The plugin stores a relationship file that maps internal chat IDs to conversation file names. It keeps only the newest 15 relationships. C:\Users\USERNAME\.lmstudio\conversations\ChatSessionConversationRelationship.json

LM Studio also reinitializes plugins whenever it decides to, so reliable long-term storage of variables in outer scopes is not fully reliable and just used temporarily for the turn or as long as they're available. That includes storing current values in the Config Schematics. When values are lost, the backend code will re-establish them when needed.

Path safety: Memory names are normalized, but not to correct misspellings. It's easiest to copy and paste the memory name from the list displayed in Available Memories into the text field of Memories to Inject.

In-memory pool: The available memory pool is kept in memory and updated when files are deleted. Plugin UI updates may be delayed because of LM Studio plugin behavior, but on the backend these values are properly updated.

I had only 3 options to fully execute this: rely on the unreliable model, modify the conversation.json real-time, or use predictionLoopHandler.

• PredictionLoopHandler was a complete flop — it overtook and dictated its own custom structure, making it less widely compatible and affecting tool calls. The time spent experimenting wasn't wasted though and did play a very small part in my final route.
• Rely on the unreliable model — that was my original "easier" approach. On most days the model worked fine; on bad days it refused to comply with instructions and everything important became suggestions up to self-interpretation, finding leeway in definitive language, and repeated patterns became established rules rather than actually following the rules given.
• Real-time conversation.json editing — the most complex method which had to respect what already is and build around the flaws and natively lacking features. The only downside to this was the 2-second time window mandatory at the last token of the assistant's response. It's really imperceptible in real-world situations. The signifier that the backend has completed is when you see a message # appended after the assistant's message. If you mess it up, no harm no foul — the backend logic won't break and things will continue fine in future turns.

The multi-edit coordinator I created is a key part to this working with less overhead. Instead of independently executing individual write functions one by one with each one carrying sometimes duplicated overhead, the coordinator figures out which functions want to execute, gathers their parameters, and does it all in one chained action. I had to refactor a lot of existing code into functions usable by the coordinator, but it was better than rewriting all the logics all over again. Trade-off: a little more obscurity in the flow of each function, but I did my best trying to communicate ambiguity with descriptive function names and comments left behind.

The file lock I created is key to letting this plugin work with my other cleanup plugin. If other plugins utilize the same file locking mechanic, this would be compatible with those plugins too. The .ready file is also key to forcing Context Cleanup to give priority of execution to Persisting Memories — otherwise CC reaches the lock creation 5–8ms faster on my system which may cause bugs like cleaning up messages that were required for the memory creation/associations.

Why is there a toolsProvider.ts even if these explicit functions aren't handled by tools anymore? LM Studio did not give me a native way to poll changes real-time to the Delete Memory text field — promptPreprocessor is limited to when the user fires off a new user message so it doesn't work. The only way to achieve real-time variable monitoring was to keep the toolsProvider enabled and letting the memory deletion trigger logic exist there.

Injected context will be hidden from the user, but visible to the assistant. User can ask the assistant to read out the injected memory if you wish to see it.

LM Studio's SDK does not have full support to make this implementation easy. The methods chosen to accomplish this feature were mandatory during the time of creation of this plugin.

The plugin assumes LM Studio Windows 11 conversation files are accessible under the configured root directory at C:\Users\USERNAME\.lmstudio\conversations.

The Memory bubbles displayed on the plugin do not update real-time. Again, another limitation of LM Studio not giving a way to send updated data upstream back to the plugin UI. The memory bubbles will update when the tool reinitializes, so when it's left idle for awhile then interacted with, or if you click the trashcan "reset" button. There are already validation checks in the backend to prevent any bugs, so don't worry about it. If you choose memories that aren't available, nothing will happen. If you add, remove, or delete memories that aren't active or exist, nothing will break — it'll just be a visual bug of the UI that will refresh upon its next initialization.