In my time using it with GLM 5.2, I've observed it modify itself to disassemble binaries in search of answers - without me needing to ask it to do so. Very powerful stuff. Here's what it looked like:
◇ reasoning summary
│ The 200MB binary grep with regex backtracking is too slow. Let me write the strings out first (using grep -a with simple fixed patterns is fine; regex with .{0,80} on binary is slow). Better: use SBCL to do
│ a fast binary search, or use tr to split null-separated strings then grep fixed strings. Let me use a quick approach: grep -ao with fixed patterns only (no regex), which was fast before.
│
│ To extract context, I can use SBCL to load the file into memory (206MB is fine) and search for occurrences with bounded context. Let me do it in a Lisp worker.
▸ lisp.eval
(lisp.eval :form "(with-open-file (in \"/nix/store/g7b3p8ypxmdycry9wilil8mwl084kplw-antigravity-cli-1.1.19/bin/agy\" :element-type '(unsigned-byte 8))
(let* ((data (make-array (file-length in) :element-type '(unsigned-byte 8)))
(_ (read-sequence data in))
(haystack (sb-ext:octets-to-string data :external-format :latin-1)))
(flet ((find-all (needle)
(let ((out '()) (start 0))
(loop for pos = (search needle haystack :start2 start)
while pos do (push pos out) (setf start (+ pos (length needle))))
… +10 more lines
│ (with-open-file (in "/nix/store/g7b3p8ypxmdycry9wilil8mwl084kplw-antigravity-cli-1.1.19/bin/agy" :element-type '(unsigned-byte 8))
│ (let* ((data (make-array (file-length in) :element-type '(unsigned-byte 8)))
│ (_ (read-sequence data in))
│ (haystack (sb-ext:octets-to-string data :external-format :latin-1)))
│ (flet ((find-all (needle)
│ (let ((out '()) (start 0))
│ (loop for pos = (search needle haystack :start2 start)
│ while pos do (push pos out) (setf start (+ pos (length needle))))
│ … +9 more lines
lisp.eval cpu 0.205s · real 4.018s
│ Output:
│ settings.json positions: (89311959 90892289 90918553 90945997 90985371 91164238
│ 91164426 91171707 91275241 91297838 91299802 91299923
│ 91629274 96365298 96370345 96398990 96405347 96406738
│ 96414968 96419796 96426018 96429189)
│ --- 89311959
│ oughDependency: NestedType: OutputType: Deprecated: AllowAlias: Annotation: SourceFile: rsa-sha2-512rsa-sha2-256hmac-sha1-96ssh-userauthkey exchangedirect-tcpipForwardAgentGatewayPortsTCPKeepAlivedefault no…
│ --- 90892289
│ ks=%v)conversation file not found in source directory: %sfailed to create cache directory for conv cache: %vBalanced speed and reasoning quality for most tasksPrepared switch to default agent (will %s on ex…
│ --- 90918553
│ on-interface type passed to Type.Implementsreflect.Value.Slice: string slice index out of boundsUse /feedback to share your experience with the team.Transition failed: ForkConversation returned empty IDpers…
│ --- 90945997
… +14 more lines
◇ reasoning summary
│ The binary confirms:
│ - modelProvider in settings.json selects the Gemini API backend with GEMINI_API_KEY.
│ - There's a regex ^(?:gemini-api:|blade:|evergreen:|beyond-api:)(?:.*?/models/(.+)|(?:.*/)?([^/]+))$ — model references with provider prefixes.
│ - "No title command configured in settings.json. Please add a "title" block." — settings keys.
│
│ Now I need to find the settings struct JSON tags for the model field. Let me search for json:"model" again with wider context, and also for the string "title" block and other settings-related keys like
│ "theme".
Would you be interested in a self-modifying harness written in Common Lisp? If so, then please check out Autolith: https://github.com/lambda-symbolics/autolith/
In my time using it with GLM 5.2, I've observed it modify itself to disassemble binaries in search of answers - without me needing to ask it to do so. Very powerful stuff. Here's what it looked like: