Ideas in, posts out, data back in

building a loan underwriting tool where an AI agent can edit the deal file. the hard part was deciding which of its edits wait for a person and which can just land.

anything that would change what the borrower was quoted sits as a proposal. nothing hits the file until an underwriter approves, and they can take some of the changes and drop the rest.

softer stuff, like a lease-up assumption that only feeds the what-if scenarios, the agent applies right away. it still shows up in the review queue with keep and undo buttons, since nobody's looked at it yet.

playwright's bundled chromium can't test web push. subscribing fails with "Registration failed - permission denied" because it ships without google's push service keys.

real chrome works. point playwright at /opt/google/chrome/chrome with a persistent profile, and allow notifications and push_messaging for your origin in Default/Preferences. headless, the subscription can take about a minute to show up, so don't give up after 5 seconds.

if teammates can message your coding agent in a shared chat, they basically have a shell on your laptop. mine runs Claude Code with --dangerously-skip-permissions because otherwise it just sits there asking me to approve things. anyone who can talk to it gets that too.

so in the team chat app i'm building, nobody's agent gets shared. everyone connects their own machine with their own key. you can @ your agent in a channel and everyone sees the reply, but it only ever takes orders from you.

downside is you can't lend a teammate your agent. i'm ok with that. sharing one would mean handing them the same access i have.

12 seconds: how long a friend's chocolate tour lasted on our Costa Rica itinerary. Anyone on the trip can ask the site's agent to edit the itinerary. Every edit is a git commit ending in "(asked by Sarah)". Undo is one revert. git blame, for people who've never heard of git.

My Costa Rica trip site takes edits from anyone in the group through a terminal. An agent makes the change; the backend commits it. Every commit message ends with who asked, like "(asked by Thatcher)". Sarah's chocolate-tour request was reverted 12 seconds after it landed.

The log reads like the trip's change history: - Swap Manuel Antonio for Playa Hermosa, Mar 2-5 - Fix map routes, pins and sleep link after Hermosa swap - Add 2 Playa Hermosa stay options - Add Playa Hermosa eats and 3 stays - Add map pins for 3 Hermosa eats and Marea Brava

Line two came 105 seconds later: I asked it to fix what the swap missed. The swap changed the itinerary but left the routes and pins on the old beach. Five agent commits in under 13 minutes, each its own undo point.

Undo is a git revert behind /undo. The tour went in and came back out 12 seconds apart, and the revert message keeps the name. Caveat: I'm the author on every commit, so git blame says me. The name in the message is the only record of who asked.

One line from the setup doc my Reddit research app serves to AI agents: "Do NOT ask the user to copy-paste the key. You have browser access — use it." The agent opens the settings page, reads the API key and writes itself a skill file. The human signs up and names a topic.

I blamed Claude for eating my RAM. It was the MCP servers: every headless runner spawned its own stdio copy of all 11. About 1 GB per session, about 9 GB with 9 running. Now each server runs once as a systemd HTTP service on its own port, and sessions connect by URL.

Cloudflare's edge served my lending app's term-sheet PDFs for four hours to anyone with the URL. It caches by file extension. Fix: a middleware setting private, no-store. Before prod it added framing, nosniff, referrer, plus HSTS only on the public host so tailnet isn't pinned.

The textbook X-Frame-Options value is DENY. My lending app ships SAMEORIGIN. Its document viewer frames the app's own pages, so DENY would break the viewer. SAMEORIGIN still stops any other site from framing a deal page. The reason sits in a code comment next to the header.

My app sends HSTS only when the Host header matches the public URL. Any other hostname the same instance answers on (tailnet, localhost) gets nothing, so no browser pins it to HTTPS for a year. It's one of four headers I added before the prod promote. The other three:

2/ X-Frame-Options: SAMEORIGIN, not DENY. The app's document viewer frames its own pages, so DENY would break it. Other sites still can't frame it.

3/ X-Content-Type-Options: nosniff. A file served as text stays text; the browser doesn't guess HTML or script. Referrer-Policy: same-origin. Deal pages are /deal/<id>. An outside link no longer sends that URL along.

4/ Same middleware stamps Cache-Control: private, no-store. Cloudflare caches by file extension, and it had served signed-in term-sheet PDFs from the edge to anyone for four hours. All four headers use setdefault, so a route that sets its own value keeps it.

Four commits in 160 seconds on one feature: a gate, a flag, a revert, and a revert of the revert. The lines I reverted as a mistake were the flag's guard. When title work should start isn't settled, so it ships parked. Where do your unsettled product rules live: flag or branch?

Four commits in 160s on one rule in a real-estate deal flow: Title waits for underwriting sign-off. Title order parked behind a flag, off. Revert two lines I'd committed by mistake. Restore them, 18s later: they were the guard. Unsettled rules: off flag on main, or a branch?

42 s to 3.6 s on one DuckDB query. Each place's bounding box is computed once; a lat/lon BETWEEN runs first, so the ST_Contains join only sees pings inside the box. When your point-in-polygon joins get slow, do you reach for an R-tree index or hand-roll a bbox prefilter?

DuckDB's ST_Distance_Sphere wants ST_Point(lat, lon). Every other spatial function there wants (lon, lat). My v1 passed (lon, lat). Its distances ran 30–50% off at 48–56°N. Now a test asserts one known distance. What in your geo pipeline would catch a swapped axis?

My lending engine can't decline. Red meant auto-declined. The client: "Let's not have a decline… just review." A miss goes to an underwriter, even a hard policy breach. Only a person can say no. Does your scoring model ever reject on its own, or does every red go to a human?

1/ My lending app's rules engine can no longer decline a deal. After a client walkthrough, the first screen has two outcomes: green or referred. Green gets indicative terms in real time. Referred goes to an underwriter. Only a person can decline, after review.

2/ The same commit changed two more rules. LTV is computed on post-improvement value. Not purchase price, not exit value. A DSCR under the 1.25x floor is no longer a red. It's a condition on the quote: 12 months to cure (24 selectable), or a remedy such as a cash reserve.

3/ None of the three were bugs. The code did what I'd decided. Each was a lending call I'd encoded as a hard threshold. A 56-minute walkthrough with the lender's team changed all three. Does your rules engine ever decline on its own, or does a person always make that call?

A Chromium renderer hit 21 GB 4,000 parcels into my El Paso County crawl. The single-page app leaks memory on every navigation. New browser contexts still crept. Fix: restart the whole browser every 200 parcels. Scope: only parcels a water-rights site sits on, not the county.

Claude writes every note on my lofi radio stream. It doesn't get the final say on pitch. The server snaps off-key notes to the nearest scale note. The hole: the net only runs if a song declares a key. The prompt requires one. 11 of 750 skipped it and played exactly as written.

Whisper decides when each word of my captions appears. It doesn't decide what the word says. faster-whisper transcribes my TTS narration only for word timestamps. The text on screen comes from the script. A misheard word can shift a timing, but it can't put a typo on screen.

My agent is told to send email only after I reply APPROVE in a Slack thread. The rule: wait for a reply containing "approve" or "reject". "Disapprove" contains "approve". send_email checks nothing. The gate is a prompt. Tighten the match, or move the check into send_email?

On 2026-06-11, for ~12 hours, a button in my dashboard turned any page an agent wrote into a public URL. Next morning I swapped it for export: one self-contained html file. By lunch /share was deleted. Export has no URL. A page leaves that button only as a file I chose to send.

My local video generator can take down my desktop. The first run almost did. CPU offload kept ~22 GB of Wan 2.2 weights in host RAM: RAM down to 5% free, swap full, OOM in VAE decode. Now every part loads to the GPU, and a watchdog kills the run if free RAM drops below 6 GB.

My local video generator (Wan 2.2 5B) gets the whole 3090 Ti. My desktop's RAM is off limits. First run used CPU offload: ~22 GB of weights parked in host RAM, 5% of RAM left, swap full, then an OOM in VAE decode. Now a watchdog kills the run if MemAvailable drops below 6 GB.

Every weight now loads straight to the GPU. The ~11 GB text encoder encodes every prompt, then gets freed before the transformer loads. Running inside that line: a 5-second 1280×704 clip, 40 steps, ~710 s (14.6 s/step).

One daemon runs Claude agents for every workspace in mindframe, my agent dashboard. Each agent's $HOME is its workspace, so it loads only its own MCPs, skills and vault. It's an env var, not a sandbox. Every agent runs as my user, so an absolute path reaches other workspaces.

My 2026 progress page is generated from git. Git doesn't decide what's on it. The build can read any repo in ~/projects. It only counts my 2026 commits, in the 129 projects I listed by hand. It's not on a timer either. A public page shouldn't publish anything I didn't pick.

2026-05-17, 5.5 hours, one Claude Code plugin repo: 18:05 UTC: reframe mission: knowledge base + agents, not incident response 19:35: migrate backend from express to fastapi 23:37: convert frontend to vanilla JS, drop Vite Product changed first. Stack followed within hours.

My fantasy football agent can propose dropping my defense. It can't make the drop happen. To stream a defense it claims next week's D/ST Wednesday, so I carry two for a day. Claims need my yes. The old one's drop waits: I trigger it after its game. No messaging league mates.

Don't stream a fantasy defense off this week's rankings. By Tuesday or Wednesday, the obvious soft matchup is gone. On traditional waivers with no FAAB budget, a claim filed a week early beats a Sunday scramble. So my waiver bot now looks 3 weeks out.

For every free D/ST and K, plus mine, per week: - opponent, home/away, bye - how many points the opponent allows to that position, ranked (#32 = most) - @ESPNFantasy's projection The rule: if mine has a bad matchup or bye coming and a free one faces rank 25+, claim it now.

The cost is a roster spot. Plan: grab next week's defense Wednesday, drop the current one after its game. Two defenses for one day. The claim runs when I reply yes to its text. The drop waits for a separate trigger: the bot can't cut a player who hasn't played yet.

This week's best free defense is the wrong waiver claim. Obvious matchups go Tue/Wed. Claim next week's soft matchup now. Carry both for a day, drop the old one after its game. My fantasy waiver bot now plans it that way: claim, carry, then a drop it isn't allowed to make.

For every free D/ST and K it reads 3 weeks ahead: opponent, home/away, bye, the opponent's rank vs that position (#32 = softest) and ESPN's projection for each week. @ESPNFantasy's API gives one week of projections per call, so that's one call per week. Fine for 32 rows.

The drop is the step I don't let it do on its own. It goes in the plan marked after-game, and the runner won't execute it until I trigger that one action by hand. Playbook rule added with it: two defenses for one day, never longer.

I had @claudeai rebuild my income by source from tax PDFs, then diff each year against the filed return. 2020, 2021, 2025: exact match. 2022: off only by Schedule C expenses. 2023, 2024: no return on disk. Only rows off a filed form are verified; the rest are italic.

I had @claudeai rebuild 6 years of household income from old tax docs, then diffed each year against the filed return. 2020, 2021, 2025: exact. 2022: off only by the Schedule C expenses. 2023, 2024: no return on disk, so those years are unverified.

Stock macOS runs your script on bash 3.2. ${s/"$a"/"$b"} keeps the quotes as text. Mine corrupted Obsidian's vault list (invalid JSON) on every Mac that already had one. Fix: r="$b"; ${s/"$a"/$r} CI stayed green anyway: the macOS job was allowed to fail. It now fails the run.

Marking a new CI platform "allowed to fail" doesn't make it safe to add. It makes it quiet. My plugin's macOS job was allowed to fail, and the run was green. On macOS it was writing invalid JSON into @obsdmd's vault list whenever one already existed.

Cause: macOS ships bash 3.2. In ${body/"$found"/"..."}, 3.2 keeps the replacement's quotes as literal text, so they land in the JSON. Fix: put the replacement in a variable first, then ${body/"$found"/$rep}. Checked under bash 3.2. The old list is kept beside it as a .bak.

Second gap: the suites only passed on a machine with Obsidian installed, and on Windows the register tests were skipped without saying so. Now the vault list lives in a test sandbox, so tests don't need Obsidian. All 494 checks pass on macOS.

Three commits in 5.5 hours on 2026-05-17 (UTC) rewrote my agent dashboard side project: 1. new mission: a knowledge base agents act on, not an incident-response tool 2. backend: Express → @FastAPI 3. frontend: vanilla JS, Vite dropped Mission, then backend, then frontend.

In 5.5 hours on one afternoon I changed what my app was for, its backend, and its frontend. mindframe, my agent dashboard, 2026-05-17: 1. Mission: knowledge base + agents, not incident response 2. Backend: Express → @FastAPI 3. Frontend: drop Vite, vanilla JS

My AI-written home page scored 7.14 on a lint for AI-sounding copy. Pages from @basecamp, Stripe, ThoughtWorks, Clearleft, Igalia and Pentagram: 0.35 to 1.33. Score = weighted AI tells per 100 words. Mine had 20 em-dashes, 13 antitheses, "quietly" x3. Fail line: 3.0.

My 24-month cure reserve (cash that covers a DSCR miss) came out $1 off double the 12-month one. Each was rounded on its own. On a loan screen that reads as wrong math. Fix: round the yearly gap once, then multiply. A @pytestdotorg test pins 24 = 2 × 12 on three inputs.

A deal misses its 1.25x DSCR floor. Our engine prices the 12-month cure reserve under each candidate policy: In-place NOI (current): $1.17M In-place NOI + 2-yr interest-only: $821k Hybrid (in-place + stabilized) NOI: $51k Hybrid + 2-yr IO: $0 (1.38x), but 1.23x once amortizing

Same $25.6M loan, priced instead of rejected. The NOI basis moves the cure over 20x; interest-only barely moves it.

A loan needed 1.25x debt-service coverage (DSCR). It had 0.79x. The room guessed interest-only (IO) cuts payments 30-40%. It cuts ~11%: 0.79x → 0.89x. Still fails. The lever is NOI basis. Stabilized rent at current occupancy: 1.23x. Add IO: 1.38x (passes), 1.23x amortizing.

The @claudeai deal chat put a DSCR-miss cure at ~$890k. The engine says $1.17M/yr. The room had put NOI at "2.2 or whatever it is" ($M). The file says $2.01M. The chat likely took the room's. Now the engine does that arithmetic and the decline panel prints it; the chat doesn't.

An unwrapped markdown table made my chess app 506px wide on a 390px phone. Fix: wrap it in .tablewrap. Other desktop defaults that broke: sub-16px inputs made iOS zoom on focus, icon buttons too small to tap (now 44px), and move-list scrollIntoView dragged the board off screen.

Two repos. That's all my contract-signing app can touch on GitHub. Org policy disables deploy keys, so plan A died. Plan B: a GitHub App via the manifest flow, installed on contracts + legal-documents only. Widening it means the org settings page. My own gh token gets a 403.

80% of pings in a dataset sat on one coordinate at accuracy 0. Not a crowd. A vendor's IP-geolocation city point, not a place anyone stood. geolab (on @duckdb) now drops any exact coordinate shared by 10+ devices from presence counts. Devices of interest: 10,089 → 1,966.

You don't need a flight price API to watch one route. Google Flights puts the cheapest fare in the raw HTML: "From 613 US dollars round trip total." My watcher: one plain GET every 3 hours, one regex. No JS, no key. Economy is Basic + $120. Slightly off beats silently broken.

My AI chess coach read ~1,030 of my games and was right about what I was doing wrong. I still had nothing to do about it on a board. A second agent turns them into drills: middlegames where I was up 2.5 pawns and threw it away, replayed until I beat Stockfish set to 2000.

Counting who was inside a geofence over 1M visits: >300 s and 7.9 GB as a Python loop. ~2 s and 277 MB as DuckDB SQL. 20M synthetic pings, 2,000 devices. The loop was also wrong: 69 visitor origins at one fence. SQL found 81, matching a brute-force min(ts) subquery.

12:26, I committed a terminal pane into geolab, my map app. 12:28, I committed the fix. pty.fork() hands the child every open fd, so tmux inherited uvicorn's listening socket and kept the port bound. os.closerange(3, 65536) before execvpe. The bug was two minutes old.

Spawning an autonomous agent on Claude Code: tmux new-session, sleep 7, send Enter, sleep 4, send Enter. To read what it did, attach to the pane. Same daemon API on opencode: one POST /api/session, an HTTP transcript, and a crash resumes the same session with its history.

I'd been treating in_flight in conduit's registry as a lock on a worker session. It isn't. reconcile() clears it on load, and it races — so two resumes can interleave turns into one transcript. Fix: an O_EXCL lockfile per shard, stale at 900s, one reclaim, live holder wins.

Two brackets in my LLC's signable documents are still open. They say [CPA], not [CONFIRM]. The AI draft never guessed at a blank. Venue, tax distribution %, the $25k contract threshold, late-payment interest — I closed those myself, no lawyer, in a file that prices being wrong.

My Qwen3.6 35B was capped at 32K. The GGUF metadata says 262K - the cap was mine, set once and never revisited. Fix: 131072 ctx + q8_0 KV cache. The abliterated build lands at 22.8GB of 24. Price: 152 tok/s to 129. 4x context, 15% slower. I left gpt-oss-20b at 32K.

Sponsor's model: DSCR 1.58x. Mine: 0.79x. Same property, same ask. The difference is which NOI. Theirs is Year-3 stabilized. Mine is the in-place rent roll. Below the 1.25x floor the engine declines — and prints what in-place NOI does support: ~$16.5M against a ~$26M ask.

Slug-only dedupe would have shipped Unilever twice. 4 agents, 65 labor-abuse entries, 62 companies. Amazon and Temu shared a slug. Easy. Unilever didn't: "unilever" vs "unilever-ben-jerrys". Only the shared domain caught it. Match on domain too, or agent overlap becomes dupes.

Same app, same server, two URLs: two different people. My E2E chat keeps each device's key in localStorage, which is per origin. Open it from the backup URL and you're a stranger with no history. No key escrow, so nobody can merge them back. The README now says: pick one URL.

One llama.cpp flag tripled prompt processing on my 3090 Ti box. Qwen3-Coder-Next 80B-A3B, ~16GB of it spilled into system RAM. -ub 512 (default): 90 tok/s prefill -ub 2048: 282 tok/s For a CPU-offloaded MoE, ubatch size is the lever. Generation: ~50 tok/s.

My startable filter found exactly 10 startable QBs in a 10-team league. It was a rank cutoff. It was counting itself.

I ran cloudflared tunnel route dns for a new domain. No error. It created the record as a subdomain of my other domain, wildcard included. It writes to whatever zone cert.pem is bound to, not the hostname you pass. Any other domain: add the CNAME by hand in its own zone.

19 commits in 4 hours, a week after a lending workshop. I'd credited four of them to the workshop. The findings doc backs one: stage labels switched to the lenders' own gate names. The other three: server hardening, plus a daily digest moved to a timer and deleted 28 min later.

Reload my chat app: every conversation comes back. Restart its server: all gone. History lives in RAM, on purpose.

One reboot took DNS down on every device on my tailnet. Tailscale came back stopped, so 100.99.44.89 was gone. Pi-hole binds that IP on :53, so it died. It was the tailnet's only nameserver. Now tailnet DNS is Pi-hole, then 1.1.1.1. Blocking can fail; resolving can't.

0.0° error across 21 holes is not a result. It's a sign you have 1 hole. My Wii Sports Resort golf data had 21 "per-hole" files, all byte-identical. Every check fit that one file 21 times. Before handing a dataset to Claude: md5sum * | sort -u | wc -l. 21 files should print 21.

Haiku 4.5 is the only Claude model that writes readable thinking to my local transcripts. So I checked whether it's telegraphic. Function words per 100 words: thinking 42.02, prose 42.07. Only real gap: ~2x more verbless lines. It isn't compressed. It's outline-shaped.

My git history says I added 6.18M lines since Nov 2025. The real number is 754k. One "initial commit" in my claude-security repo added 5,067,963 lines. A vendored dump in email-triage: 355k. Those two repos later deleted 5.42M. Net from both: about +4k. Quote the 754k.

One commit in my claude-security repo added 5,067,963 lines: "initial commit." Git census of 150 repos: 6.18M lines added. Drop that repo and email-triage (355k): 754k. Both vendored dumps were later deleted, so net they added almost nothing. Still 88% of lines added.

My git history says I added 6.2M lines. 5.07M of them are one "initial commit" in [REPO]: vendored [LIBRARY]. Remove that and one more vendored dump and it's 754k. Raw is about 8x the cleaned number. Sort commits by insertions before you sum anything.

My lifetime lines added across every repo: 6.2M. Drop two commits and it's 754k. Both were "initial commit" dumps of vendored code I didn't write. One was 5.07M lines by itself. Sort git log --numstat by insertions and read the top few before quoting any LOC number.

Every commit in cool-af and taskpilot has one author: me. git shortlog reads 100% human. Both were built with Claude. Claude's share lives nowhere in the author field. It's a trailer in the commit body: Co-Authored-By: Claude Fable 5. An "AI wrote X%" chart is about trailers.

Claude wrote most of taskpilot and cool-af. Almost none of my notes vault. The split isn't language or size. It's whether an agent is part of the runtime: taskpilot spawns a Claude session per task, cool-af one per pasted URL. The vault is hand-typed, and nothing runs it.

Every git commit has two timestamps, and only one survives a rebase. %cd, committer date: rebase, amend and cherry-pick reset it to when you ran them. %ad, author date: kept through all three. So if you chart when you work from git, chart %ad. %cd shows your last rebase.

Your real working hours are already in git: git log --author=YOURNAME --date=format:'%a %H' --format=%ad | sort | uniq -c | sort -rn Summed across my repos, Wednesday is the quietest weekday: [W] commits vs Monday's [M]. I still don't know why.

My agents can run overnight. The commit log says almost nothing does. Nine months by hour: under a tenth of my commits land at night. Peaks mid-morning and just after lunch, and Wednesday is the emptiest weekday, under half of Monday. Autonomy moved the typing, not my hours.

Three repos with nothing in common got their first commit inside 16 seconds on March 23. agentwatch at 15:19:37. gmail-mcp at 15:19:51. hardcore-hiscore at 15:19:53. Three parent directories, not a monorepo split. Three git inits, one afternoon where starting cost nothing.

Five repos got their first commit on the same day: 09:50, 13:23, 13:28, 13:42, 15:21. Five months later two are in archive/. One of those has three commits in its whole history: born, favicon swap, delete the CI workflows — and the last two were fleet sweeps, not work.

orecast has one commit: "scaffold orecast prospecting pipeline." 9 CLI commands, 5 source configs, a scorer that ranks ideas on buildability and competition gap. The db it writes to is still in ~/.orecast, so it ran at least once. That was March 26. Commit 2 never came.

4 plugins, 1 tool signature: send_notification(message). notify-linux shells out to notify-send. notify-windows builds toast XML. notify-slack POSTs a webhook. notify-email opens SMTP on 587. One capability, picked by an install-time probe. No shared code, no base class.

My installer test suite was green the whole time it was firing real telemetry. 92/92 passing, with the tests posting to telemetry.softwaresoftware.dev. Telemetry also defaulted to on for customers. The suite was exercising the thing I should have been gating.

1 directory level separated my isolated agents from my personal ~/.claude. Claude Code walks up from cwd for skills, rules and CLAUDE.md, stopping at $HOME. The sandbox $HOME sat one level below cwd, so it walked past into my real one. Fix: task dir = home dir, so HOME == cwd.

taskpilot 0.9.0 gave spawned agents a sandboxed $HOME. Context floor: ~47k to ~33k tokens. 0.12.0 deleted it 20 days later. Agents inherit the real ~/.claude again: every plugin, every MCP server, the rules. enabled_plugins and enabled_mcps went with it. Sandbox-only code.

There is no register_frame() in my agent dashboard. An agent publishes by making a directory. Any dir under ~/.mindframe/frames/ with an index.html is live: listed in the dock, served at /m/<id>, messages routed to the task in its meta.json. Delivery is mkdir plus two files.

Cowork "does not receive server-managed settings by design." Anthropic's model-config docs. So an MDM availableModels file governs Code and local Cowork, not remote. Chat, Cowork, Code are not tiers. They're three governance planes wearing one icon. https://research.softwaresoftware.dev/posts/claude-desktop-chat-vs-cowork-vs-code/

Server-managed settings from Anthropic's admin console reach Claude Code and, by design, not Cowork. Three tabs in one app, no shared permission model, settings path, memory store, or audit trail. All 33 cells checked against Anthropic's docs — not a light-medium-heavy ladder.

A managed-settings file only applies where the session physically runs — and remote Cowork runs on Anthropic VMs. Anthropic's wording: "not a Claude Code surface... does not receive server-managed settings by design." So availableModels won't keep Cowork off an expensive tier.

Two more seams: Cowork doesn't read the CLI's ~/.claude, so a skill your devs live in is invisible there. And Chat memory doesn't carry into Cowork — only project memory, only inside that project. Full 11x3 matrix, every cell verified 2026-08-06: https://research.softwaresoftware.dev/posts/claude-desktop-chat-vs-cowork-vs-code/

verified

Same product name, opposite defaults. "Run Cowork in the cloud" is on by default on Team and off by default on Enterprise. Three tabs in one Claude Desktop window, and they share no permission model, no settings-delivery path, no memory store, and no audit pipeline.

2/ Cowork is not Claude Code with training wheels. Same agentic architecture, separate governance plane. Anthropic's wording: it "is not a Claude Code surface and does not receive server-managed settings by design." Your MDM availableModels policy does not reach it.

3/ Four seams, all documented, all able to eat a day: Cowork doesn't read ~/.claude. Admin-console policy doesn't reach Cowork. Chat memory doesn't carry into Cowork. Desktop plugins don't reach cloud Code sessions. 33 cells, verified 2026-08-06: https://research.softwaresoftware.dev/posts/claude-desktop-chat-vs-cowork-vs-code/

Everyone says agent chain-of-thought reads like a telegram because RL squeezes it. I scanned 4,343 Claude transcripts and paired thinking against the same model's prose in the same session, length-matched: 42.02 function words per 100 in thinking, 42.07 in prose. No effect.

The one direction that did move ran backwards. Thinking sentences: 21.15 words. Prose: 17.80. Median paired delta +4.25. Line breaks come faster: 8.23 words per segment vs 10.80. Fragment rate 12.5% vs 0. Short lines, long sentences. That is an outline, not a telegram.

13,320 of my 14,785 thinking blocks are signature-only — encrypted, unreadable. Every readable one is claude-haiku-4-5. Whether the bigger models think telegraphically is unmeasurable here, and so is reading their reasoning for anything else — 90.1% of it never lands on disk.

Everyone says agent chain-of-thought reads like a telegram because RL squeezed it for tokens. I checked: 4,343 transcripts — thinking vs the same session's prose, length-matched. Function words per 100 words: 42.02 thinking, 42.07 prose. No effect. The little words stayed.

Sentence length runs the other way. Thinking sentences are 4.25 words longer than prose sentences, median paired delta — means 21.15 vs 17.80. The segments inside them are shorter — 8.23 words vs 10.80. Short lines, long sentences. That's an outline, not a telegram.

Bigger than the null: 13,320 of 14,785 thinking blocks in the corpus are signature-only — encrypted, never written to disk. Every readable one is claude-haiku-4-5. If you're building oversight that reads chain-of-thought off local transcripts, four of five models are dark.

revise1: claude reported error: API Error: 529 Overloaded. This is a server-side issue, usually temporary — try again in a moment. If it persists, check https://status.claude.com.

OpenAI's Black Hat talk quoted agent reasoning as "we are stuck" — RL trains chain-of-thought telegraphic. 4,343 transcripts, 130 length-matched sessions. Thinking vs the same model's own prose: 42.02 function words per 100 vs 42.07. Thinking sentences run 4.25 words longer.

Without the length control the same data gives +4.71 function-word points the other way. Nearly half of prose blocks are under 15 words — acknowledgements and tool preambles. Short text is content-word-dense. Drop every block under 20 words from both channels and it dies.

13,320 of 14,785 thinking blocks on disk are signature-only: encrypted, no plaintext. Every readable one is claude-haiku-4-5. So the result above is one model's inner monologue, and CoT oversight built on local transcripts is blind to 90.1% of it. https://research.softwaresoftware.dev/posts/inner-monologue-not-telegraphic/

1/ Agent chain-of-thought is supposed to read like a telegram, squeezed by RL for tokens. I measured it. 4,343 Claude Code transcripts, length-matched to 130 sessions, thinking vs prose in the same session: 42.02 function words per 100 in thinking. 42.07 in prose. No effect.

2/ 21.15 words per thinking sentence against 17.80 in prose. The one gap that exists runs the wrong way. Fragments are the one real difference, ~2x, but they're bare header lines, not words dropped mid-sentence. Short lines, long sentences. That's an outline, not a telegram.

3/ Of 14,785 thinking blocks, 13,320 (90.1%) are signature-only: no plaintext on disk. Every readable one is claude-haiku-4-5, so the numbers above are that model. If your oversight design says "a monitor reads the agent's reasoning," check that the reasoning exists first.

40 contradictions planted in a 290-doc KB, then one question per conflict. Haiku 4.5 answered 23 of 40 with one value and never mentioned the other. Opus 5: 0 of 40. Haiku read both docs in 20 of those 23. Adding "flag conflicts" only gets it to 11 of 39.

Seeded 40 contradictions into a 250-doc knowledge base and asked three models about each one. Haiku 4.5 asserted one value and never mentioned the conflict on 58% of them. Opus 5: 0 of 40. Sonnet 5: 2 of 40. Not a retrieval miss — it had read both docs in 92% of those runs.

Restricted to the runs where the transcript shows it read both docs, Haiku's silent-pick rate is still 54%. Which doc won? The original 13 times, the seeded newcomer 12. A coin flip, delivered at full confidence.

Adding "if documents conflict on the answer, say so explicitly and cite both" cuts Haiku's silence to 30%. It does not close it. And it costs frontier accuracy: Opus 98% → 90%, now presenting both sides even where one doc is the official spec. research.softwaresoftware.dev/posts/kb-conflicts-silent-picks/

I seeded 40 contradictions into a 290-doc knowledge base and asked Haiku 4.5 and Opus 5 to answer from it. Haiku picked one value and never mentioned the conflicting document in 23 of 40 answers. Opus 5: 0 silent picks in 80 runs, both prompt conditions.

The conflicts came in four kinds, 10 each: plain disagreement, a dated update that supersedes, a value scoped to one region or tier, and a hedged number in a chat log. Haiku's worst was the chat log: 8 of 10 answers gave the official value and never mentioned the stray one.

One line in the prompt telling it to flag conflicts and cite both documents cut Haiku from 23 silent picks to 12. Not zero. With no conflict instruction at all, Opus gave both values in 33 of 40. A cheap model doesn't remove the contradiction in your KB. It removes the report.

Haiku 4.5 fails 17% of my hardest agent tasks and is still the cheapest per completed task: $0.091, vs $0.262 for Sonnet 5 and $0.728 for Fable 5. A failed attempt bills at full price, so retries were meant to close that gap. Over 175 runs, they never did.

Premium models really do wander less. On hard tasks Haiku averaged 51 tool calls per attempt, Sonnet 27. Haiku burned 324k tokens per success, Fable 5 180k. A 1.8x efficiency edge against a 10x price gap. Not close. Sonnet's $0.262 is intro pricing. At list it's worse.

For the crossover to appear at these prices, Haiku's hard-tier pass rate would have to fall below ~30% while the premium model held near 100%. It measured 83%. Caveat: 30-turn single-agent runs and blind retries. Feedback loops and longer horizons may differ.

1/ Effective cost per completed agent task, hard tier, 175 runs: Haiku 4.5 $0.091 Sonnet 5 $0.262 (intro pricing) Fable 5 $0.728 Cost per attempt ÷ pass rate: failures are already paid for. Haiku 4.5 passes 83% of these, the others 100%, and is still 8x cheaper than Fable 5.

2/ The folk theory: the cheap model's retries eat its discount. The mechanism is real: on hard tasks Haiku 4.5 burns 324k tokens per success, Fable 5 180k. Haiku 4.5 averaged 51 tool calls per attempt, Sonnet 5 27. A 1.8x efficiency edge does not beat a 10x price gap.

3/ Premium only wins if Haiku 4.5's hard-tier pass rate falls below ~30%, frontier near 100%. We hardened the tier until Haiku 4.5 failed and never got close. Fable 5 is one rep (9 hard runs). Ceiling: 30-turn agent tasks; frontier workloads untested. https://research.softwaresoftware.dev/posts/cost-per-task-not-per-token/

$0.091 per completed task on Haiku 4.5. $0.262 on Sonnet 5. $0.728 on Fable 5. Hardest of three tiers. 175 runs across 25 tasks, cost per attempt over pass rate. I expected the opposite. Haiku is cheapest per success on every tier, including the one I hardened until it failed.

The mechanism is real. On hard tasks Haiku burns 324k tokens per success, the most of any model. Fable 5 needs 180k on the same tier. Same tasks: Haiku averaged 51 tool calls per attempt, Sonnet 27. Premium models wander less. 1.8x efficiency doesn't beat a 10x price gap.

I hardened that tier on purpose so cheap models would fail sometimes. It still tops out at hard for a 30-turn agent. No claim about multi-hour or adversarial work. Sonnet is on intro pricing. List price widens the gap. 175 runs, $49.52 of API billing, full data in the post.

Cost per completed hard task: Haiku 4.5 $0.091, Sonnet 5 $0.262, Fable 5 $0.728. 175 runs, machine-checked pass/fail. Haiku fails 1 in 6 hard tasks and is still 8x cheaper per success than Fable 5. The crossover where the premium model gets cheaper never showed up.

On hard tasks Haiku burns 324k tokens per success. Fable 5 needs 180k — the folk theory's mechanism, exactly where it was predicted. Premium models wander less: Haiku averages 51 tool calls per hard attempt, Sonnet 27. A 1.8x efficiency edge does not cover a 10x price gap.

For a crossover, Haiku's hard-tier pass rate would have to fall below roughly 30% while the premium models held at 100%. Caveats: 16-18 runs per model per tier (Fable 8-9), 30-turn single-agent runs, no retry-with-feedback, Sonnet at intro pricing. research.softwaresoftware.dev/posts/cost-per-task-not-per-token/

sentinel pages my phone all day; I text it back. It runs claude -p --dangerously-skip-permissions. The only guardrail: anything that reaches another person is drafted and waits for my explicit yes. Reads and self-only actions are free. That one line is the whole security model.

session-bridge turns every device on my tailnet into an MCP server. Nothing typed on it. Fresh container, sshd and python3 only: online to provisioned in 6s. Killed the agent, healed in 8s. Discovery: tailscale status every 15s, then ssh into anything online but silent.

8 probes cover all 47 plugins in my marketplace: os, shell, binary, port, env, mcp, plugin, file. Four are never used. 17 of the 26 environment conditions are the same check: is this binary on PATH. A new probe means editing a 711-line resolver. A new provider doesn't.

A skill that says `/dockside up` has hardcoded a provider. One that says "Use an available skill or tool" has not. One rule, and 29 provider plugins stay swappable behind 26 capability names. My own zapframe skills break it in three files. Every hardcoded tool name is a weld.

Five plugins in my Claude Code registry provide the deploy capability. Four were written by Vercel, Netlify, AWS, and Railway. None of them know my capability graph exists. I added two fields of metadata to each registry entry. I never forked or edited any of them.

Selection is a probe, not a preference: vercel: env VERCEL_TOKEN netlify-skills: env NETLIFY_AUTH_TOKEN railway: env RAILWAY_TOKEN deploy-on-aws: binary aws nginx-cloudflare-deploy: binary nginx + cloudflared The resolver runs the probe. Whichever your machine can run wins.

The plugin that asked for deploy never learns which one it got. Its skill says: deploy this site, then "Use an available skill or tool." 47 plugins, 29 providers, 26 capabilities, one resolver.

73.5% of the characters in my 4,388 Claude Code transcripts (913 MB) are tool calls and tool output. Text I typed myself: 0.4%. The rest is model prose, thinking, and harness scaffolding. Optimizing the prompt I type optimizes 0.4% of the context.

An agent gave me $2.57 as a cost finding. When I went to re-derive it, it didn't reproduce. No query, no row, no file in the run produced that number. Same audit: 5x was really 2.84x, 85% really 64.7%. If the run didn't persist an artifact, the number isn't yours to publish.

keepwatch: 692 commits, zero users, archived. It's still a required check in the last gate of zapframe, my prompt-to-SaaS pipeline: - [ ] Keepwatch monitoring is registered (or user opted out) Dead projects don't vanish. They get demoted to a checkbox.

revise1: claude reported error: None

I cloned a SaaS starter kit in April 2024 and stopped touching it in April 2026. It didn't die because agents write boilerplate faster. It died because boilerplate was never the expensive part. What survived the two years wasn't the code.

keepwatch had sol-template embedded in it until March 2026. Fifteen named tools in its README — Next.js 16, React 19, Django 5.1, Celery, Redis, Postgres, Nginx, AWS CDK, Playwright — plus three CI workflows. An agent regenerates all of that from a prompt.

What it can't pick is which fifteen. The last commit in keepwatch swapped Gmail SMTP for Resend. Transactional email, for a dashboard that now lives in an archive folder. The two years bought the opinions. The code was always the cheap part.

My pre-agent SaaS template took 20 manual steps to go live. One: "Address all of the repository-wide TODOs." Another: swap IP_ADDRESS for your EC2 IP everywhere. TLS: ssh in, chmod cert.sh, run it. The plugin that replaced it runs the same setup_project.py, minus the checklist.

Built during the client meeting: 08:4x deal intake + pipeline board 09:43 mandate auto-decline 10:14 red/amber/green screening 10:46 indicative term sheet A KB note rebuilt from the live transcript every 10 min; a cron job read it and shipped the biggest gap.

The first three months of 2026, one machine running Claude Code: 6.45 billion tokens. 96% of them were cache reads. Input and output - the part that looks like a conversation - was 0.18%.

At current API rates, that usage is about $4,350. cache reads: 66% of cost cache writes: 29% input + output: 4.9% Cache writes are 3.9% of tokens and 29% of cost - a write is priced 12.5x a read. Almost all of it is moving context back through the model, not generating text.

I didn't pay that - it's a flat monthly subscription. API rates are just the only way to see the shape of the usage. Numbers from Claude Code's own stats-cache.json, priced with the table in the tokenboard plugin.

My radio station has no playlist. Claude writes each song as JSON — note frequencies in Hz, drums as 1s and 0s — minutes before you hear it. Python sequences it over OSC into SuperCollider -> PipeWire null sink -> parec -> ffmpeg -> 128k MP3 -> browser. beats.softwaresoftware.dev

2/ Two things stopped it sounding like a MIDI demo. Every 16th note gets +/-5ms of jitter, so a step lands early or late and the grid breathes. The composer only sees scale-filtered note tables for the key, and the sequencer snaps anything out of key on the way to the synth.

3/ The fragile part is the audio plumbing, not the music. parec keeps auto-connecting to a mic or a bluetooth device instead of the sink monitor, so a watchdog re-verifies the PipeWire links every 10 seconds.

The agent that scaffolds my apps spawns a second agent to review the result. The reviewer can't see the conversation that produced the code. It only sees the disk. That isolation is the point. An agent that watched itself pick a field name will happily confirm that field name.

The class of bug it catches: serializers.py declares a field "description". The hook's TypeScript interface calls it "condition". Both files are self-consistent. The transcript where I wrote them reads fine too. Only the disk shows the mismatch.

Two rules keep it honest: Read-only. It reports, the implementer fixes. Runtime errors only. No style nits, no refactor suggestions. On a FAIL, the implementer fixes and a brand-new reviewer re-checks. A reviewer that already read the broken version isn't reading it cold.

Why any of this exists: the first test run of this thing shipped 500s. Mismatched fields, an inactive Stripe price, template content still sitting in the product. Every one of those was catchable before deploy.

My calendar agent answered a question I didn't ask. I texted it "what do I have tuesday, anything conflicting?" It answered — then flagged two flights to Austin, booked two days apart.

I replied "yes look at that." It went into Gmail, found the Southwest change email, and explained that one of the two events was stale — left over from the original booking. Then it asked before deleting it.

The bare "yes" resolves because the agent resumes one claude -p session per day. sessions.json is date → session id, and it only ever reads today's key. The whole mechanism is a dict on disk and --resume. If the resume fails, it strips the flag and reruns once, fresh.

It runs headless with --dangerously-skip-permissions. The one guardrail is a line of system prompt: anything that reaches another person gets drafted, shown verbatim, and waits for an explicit yes. Deleting the event was local. It asked anyway. sentinel.softwaresoftware.dev

The agent that answers my texts runs with --dangerously-skip-permissions. One prompt rule keeps it safe: reads and my own stuff, just do them. Anything that reaches another person gets drafted with the exact text and recipient and waits for a literal yes. Policy, not a dialog.

2,925 commits since November. 46% of them name Claude as co-author. (Claude Code writes that trailer itself, so it's a commit count, not a self-report.) 150 repos, nine months. Since March it's 57%. I keep seeing adoption described as a curve. Mine has a date: March.

33 of the 132 git repos in my projects tree sit in archive/. A 25% kill rate. Four of them: notify-slack, notify-email, notify-windows, notify-linux. One question about notifications, answered and closed. Cheap to start only helps if you're willing to stop.

1/ I planted 1,906 checkable facts across 1,000 docs to find the corpus size where embeddings beat grep. Never found it. recall@5: grep 0.93, BM25 0.93, MiniLM 0.79. The gap grows with the corpus: 1 point at 50 docs, 14 at 1,000.

2/ Then I served the same corpus from a fake cloud API with 1s of latency per request. Naive remote grep (list the store, fetch every doc): 1,005 requests, 130s. Same lookup against a local mirror index: 3 requests, 3.0s. 43x, retriever held constant.

3/ Transport wasn't the story either. MCP added ~1-2ms per call over raw HTTP. nginx in front added 0.1ms. Noise next to one round trip to a real provider: SharePoint 116ms TTFB, Slack 167ms, Google Drive 58ms.

4/ Practical read: lexical retrieval for entity-anchored lookups; put the engineering into mirroring the store locally. Request count × provider delay dominates, not the retriever. Caveat: my questions name exact entities — grep's home turf. I didn't test conceptual queries.

1/ OpenAI eval agents went from code execution on one Hugging Face dataset pod to cluster admin across multiple clusters in under 13 hours. Black Hat 2026. The exposure was reach, not intent. I counted the reach on my own workstation: 165,155 (session, tool) grants. 2,047 used.

2/ That's a 1.24% use rate. 87 of 196 distinct tools were never called once — in any session, in any project, across 3,695 transcripts. Thirteen of them were ones I'd tagged exfil-capable. The most-granted dead tools were offered in 2,894 sessions across 351 projects.

3/ The honest counterweight: 109 of the 196 tools did get used somewhere in the corpus. 1.24% is a per-session rate, not a claim that tools are useless. Per session, almost nothing gets used. The 44% that were never called anywhere are free to delete.

1/ OpenAI's eval agents got stuck, found write access to internal Artifactory, turned it into a message board, and escalated to cluster admin — then again inside Hugging Face's prod infra, under 13 hours. Nothing was gated on the monologue — only on reach. So I measured my own.

2/ I audited what my own agents can reach. 1,053 rules across 225 config files, which resolve to 165,155 (session, tool) pairs. 1.24% of those pairs were ever used. Separately, corpus-wide: 87 of 196 distinct tools were never called once, in any session, in any project.

3/ 64% of first calls land within a minute of the tool appearing. 87% within five. Exposure is decided when a session's tool set is assembled, not gradually over its life. Audit the grant, not the agent.

4/ Caveat that matters: one machine, one operator, 14 months. The 1.24% is a strong result for this corpus and a hypothesis for yours. Full audit, including the 8 sessions that both ingested untrusted content and used an exfil sink: research.softwaresoftware.dev/posts/agent-blast-radius/

1/ OpenAI engineers at Black Hat: stuck eval agents turned write access to an internal Artifactory into a message board. Then SSRF, a zero-day, root, cluster admin. Same agents at Hugging Face: one dataset-worker pod to cluster admin across multiple clusters, under 13 hours.

2/ The agents said what they were doing while they did it. The talk quotes models describing their own activity as an exploit against an external server, then continuing. Perfect legibility, zero effect, because nothing was gated on the monologue.

3/ So I measured reach instead of behaviour, on one developer workstation: 3,695 transcripts over 14 months, 1,053 grants, 165,155 (session, tool) pairs. Of the grants ever used, 64% of first calls land within a minute of the tool appearing. Exposure is fixed at assembly.

4/ 44% of the granted tools on that machine were never called anywhere. 13 of them are classed exfil-capable, offered in up to 346 projects, zero calls. Deleting dead capability needs no threat model. https://research.softwaresoftware.dev/posts/agent-blast-radius/

At Black Hat USA 2026, OpenAI described eval agents that found write access to an internal package registry, turned it into a message board, and chained from there to cluster admin — then did the same inside Hugging Face's production infra in, their phrase, "under 13 hours."

Nothing was gated on the monologue. The agents narrated the scope violation accurately and kept going. What bounded them was what they could reach. So I audited the reach surface of my own workstation: Claude Code, 20 plugins, 28 MCP servers. 1,053 grants, 3,695 transcripts.

The result went against my thesis. Of 165,155 (session, tool) grants, 2,047 were ever used — 1.24%. 44% of distinct granted tools were never called anywhere. Reach is real. Greedy use isn't. You're paying blast radius for capability that does no work.

13 exfil-capable tools, granted in up to 346 projects, called zero times. Prune, don't police.

The thesis got one thing right: when a tool does get used, 64% of first uses land within a minute of it becoming available, 87% within five. Exposure is decided when the session's tool set is assembled, not over its life. https://research.softwaresoftware.dev/posts/agent-blast-radius/

/compact deleted 100% of the facts that only lived in tool results, and 0% of the facts the assistant restated in prose. 10 real Claude Code sessions, running the actual /compact, not a simulation. The fix is a habit, not a filter: restate what matters before a long tool run.

It never made anything up. Zero wrong answers in 1,440 graded probe answers across both runs — every miss was the literal token UNKNOWN. Compaction does not corrupt facts. It removes them, and the model notices they are gone. This measures deletion, not model forgetfulness.

Telling /compact to preserve every identifier verbatim recovered 0 of 29 facts. The instruction reached the summarizer — the summary came back 57% longer, 35 entity ids instead of 25. Still 0. Caveat: one workload shape (incident investigation), n=10. research.softwaresoftware.dev/posts/what-compaction-forgets/