Yesterday, you asked a coding agent to add a keyboard shortcut in a repository. Today, you ask for a similar change. The agent might search the same files, inspect the same tests, and run into the same traps all over again. Exploration costs something on the first attempt. Why should we pay for it a second time?

I came across Singularity in a Show HN thread. The open-source project aims to turn completed code changes into reusable workflows: where to look, how to verify a change, and which pitfalls to avoid. When another task arrives, a previously learned workflow may provide useful steps to the agent.

That sounds promising. The part I wanted to investigate was different: once a memory has been retrieved, what makes it appropriate for the task and repository as they exist today?

I read Singularity at the pinned commit 9d241f2 and ran a small, model-free synthetic test of its matching rules. This is not an installation or end-to-end test of Singularity, nor a token-cost comparison in Claude Code or Codex. I tested independently adapted matching logic and looked for situations where that logic could recall the wrong memory.

Remembering a route through the code, not a whole chat

According to the project’s README at that commit, Singularity accumulates experience after successful changes and uses a model to consolidate repeated experience into workflows. A workflow might say which files commonly need editing for a type of feature, which test commands matter, and where earlier attempts failed.

That is different from storing an entire conversation. A chat transcript includes many exploratory steps that mattered only at the time. A reusable workflow tries to retain the sequence of operations worth repeating. This article addresses that workflow-step retrieval mechanism; it does not audit every other cache the project might have. Even when a step remembers a precise file location, the location needs to be checked again if the repository has changed.

There are also two distinct costs. Learning a workflow can require model calls. Selecting steps from already generated workflow cues need not. The project’s workflows-cues path represents the second approach.

That does not mean every Singularity path has zero model cost. In the pinned evaluation code, StepSelector.ts makes model calls to choose applicable steps. Meanwhile, Memory.ts describes workflows-cues as model-free cue selection. One evaluation path asks a model to select steps; the other checks previously generated textual cues. Their selection costs differ, but I did not measure total latency or tokens for either path on real tasks.

What the model-free matcher actually checks

I followed apps/cli/src/workflows/Cues.ts.

The basic procedure is straightforward. Normalize the task description to a consistent case, try to strip negative clauses involving words such as not, never or without, and check whether the remaining text contains cues generated for a workflow. A workflow is selected when a positive cue matches and no negative cue excludes it. Individual workflow steps can be filtered by their own cues as well.

This module is not asking a model whether two tasks are semantically similar. It behaves more like a curated table of string-matching rules. That makes selection cheap, deterministic and fast. It also means shared words are not proof of shared intent.

Suppose a workflow uses keyboard shortcut as a trigger. “Add a keyboard shortcut” is an obvious match. “Review keyboard shortcuts in documentation only” contains those same words but does not ask for an implementation change.

The source attempts to handle some explicit negation. That should not be confused with understanding every complicated negative sentence, implied constraint or cross-sentence intention. The matcher retrieves possible guidance; it cannot itself establish that following the guidance is correct.

Five synthetic inputs to probe that boundary

I manually adapted the relevant normalization, negative-clause filtering and positive/negative cue rules from the pinned Cues.ts into an independent test using only the Node.js standard library. It is not the upstream test suite and is not guaranteed to cover all upstream edge cases. I did not install Singularity, connect a model or operate on a real repository.

The script and machine-readable result record are kept in private research records rather than published as downloadable artifacts. Here are all five observed outcomes. This is a synthetic reproduction of source-inspired rules, not an end-to-end report about the CLI.

Artificial task input	Match result	What it illustrates
Add a keyboard shortcut	Match	Expected relevant recall
Fix the database connection	No match	Unrelated task excluded
Explicitly do not add a shortcut	No match	Simple negation handled
Review shortcut wording in documentation only	Match	Lexical overlap can cause a false recall
Add a shortcut, but the file in the remembered workflow was deleted	Match	Matching does not inspect the current file system

Expected outcomes were specified before execution according to the simplified rule set: match relevant tasks, exclude unrelated tasks and explicit negation, but still match a documentation-only request containing the trigger phrase. The deleted-file scenario was also expected to match because the predicate never checked whether that path still existed.

All five assertions produced their expected output. Crucially, the last two are deliberately undesirable outcomes. “5/5 passed” is not an accuracy score or evidence that five real tasks were handled correctly. It only confirms the predictions for this synthetic matcher.

The stale-file case matters most to me. Textual cue selection cannot tell whether a file has been moved, deleted or refactored since a workflow was learned. A later agent might inspect the file system and catch the discrepancy, but the obsolete route may already have been placed in front of it. A memory hit is a suggestion, not a proof of current repository state.

How to read the token-saving figures in the README

The project author reports a comparison on Excalidraw tasks. For one long task particularly relevant to the learned memory, reported tokens declined from roughly 1.90 million to 423,000, reported cost from about $0.81 to $0.30, and median turns from 28.5 to 9.5. Each side had only around three to four runs, with experiments concentrated in a small number of repositories.

Those figures are worth investigating, but they are author-reported results for particular tasks. New kinds of change or tiny one-off fixes could benefit much less. Learning workflows has its own cost as well.

Reducing file-reading tokens is not necessarily equivalent to reducing total engineering cost. A wrong recall may require additional investigation. A memory from before a major refactor may make a subsequent task harder rather than easier.

I did not rerun the author’s comparison or measure real tokens or dollars, so there is no independent savings percentage in this article. A meaningful estimate would require the same real tasks with and without memory, including the learning calls, repairs after wrong recalls, and final task-completion cost. That dataset is not available from my test.

How I would use this sort of memory

For repositories with frequently repeated operations, relatively stable structure, and predictable verification commands, workflow memory is worth trying. I would treat it as an index to inspect, not an instruction for the agent to execute blindly.

A useful workflow record could include the source commit, affected paths, last validation date and conditions under which the steps apply. Before using it, verify that the files still exist and the tests still work. If repeated recalls require manual correction, relearn or disable that workflow. These are safeguards I would recommend, not capabilities I have verified in Singularity’s current release.

I would also decide whether to install a memory system based on the repeatability of my tasks rather than a headline token-saving figure. If every assignment concerns another repository, language and problem, maintaining these memories may not pay off.

What I want next is a public comparison on the same set of real tasks that reports useful recall, false recall, stale memories, learning overhead and total completion cost together. Only then can we tell whether memory truly removes repeated exploration or merely moves some of that cost into maintaining the memory.

References: Singularity repository · pinned cue-matching source · author-reported results and caveats