DEV Community: Md Ayan bag

Claude Code /compact vs /clear: When to Use Each (With My Numbers)

Md Ayan bag — Sat, 24 Oct 2026 18:38:07 +0000

Last week Claude Code compacted my conversations 67 times. I didn't type /compact once. Every one of them was auto-compact, firing in the middle of work.

I only noticed because I wrote a small script that reads Claude Code's session logs on my Mac. The median compaction happened at 969,037 tokens. The turn right after it still carried about 106,000.

Note: I used Claude Code to help write the log script and to draft this post. The numbers come from my own machine, from 237 sessions over 7 days.

If you've wondered whether to run /compact or /clear, or why Claude Code keeps compacting your conversation, this is what I learned and the rule I follow now.

What /compact actually does

/compact asks Claude to summarize the conversation so far, then replaces the history with that summary. You stay in the same session.

The summary is written by the model, not by you. It usually keeps the goal and the recent steps. It often drops the small stuff: the exact error message from an hour ago, why you rejected an approach, which test was flaky.

You can steer it. Anything you type after the command becomes instructions for the summary:

/compact keep the failing test names, the API shape we agreed on, and the files we touched

That one habit fixed most of my "why did it forget that" moments.

What /clear actually does

/clear throws the conversation away. The next message starts a fresh context with your CLAUDE.md, settings and tools loaded again, and nothing else.

It's the cheapest thing you can do for your usage limit, because Claude Code re-sends the whole context on every turn. A clean session at 20k tokens costs a fraction per turn of one dragging 200k behind it.

The catch is obvious. If you're halfway through something, /clear forgets it.

Claude Code compact vs clear: the rule I use

Finished the task? /clear. Don't compact a conversation you no longer need. The summary of yesterday's bug is pure overhead for today's feature.

Mid-task, first time it gets heavy? /compact with instructions. One compaction with a clear "keep X, Y, Z" is fine.

Mid-task, long work, or it already compacted once? Write a handoff, then /clear. More on that below.

[[IMG1]]

Why it keeps compacting too often

The search "claude code compacting conversation too often" is real, and I was the case study. Three things caused it for me.

Long sessions. 139 of my 237 sessions ran 80 or more model turns. Those sessions produced 99% of all the context I sent that week. Auto-compact is a symptom of a session that should have ended earlier.

Big tool output. A full test run, a lockfile read, a build log. Each one lands in context and stays there. Pipe noisy commands through tail -n 40 and ask Claude to read line ranges instead of whole files.

A heavy baseline. CLAUDE.md files, MCP tool lists and skill descriptions load before you type anything. Run /context to see what your session is carrying, and you'll know how much room you really have.

Compacting 55 different sessions in a week wasn't bad luck. It was me never closing the window.

The handoff: the option most people skip

A handoff is a short note Claude writes to a file before you clear. You then start the new session from the note. It works like /compact, except you can read it, fix it, and keep it.

Here's the prompt I use. Paste it when context is above about 60%:

Write .claude/HANDOFF.md, under 40 lines, facts only:
## Goal (1-2 lines)
## Done (what is finished and verified)
## Next (the exact next 1-3 steps)
## Key files (paths and line numbers, no contents)
## Gotchas (decisions made, what failed and why)

Then run /clear and start with:

Read .claude/HANDOFF.md and continue from "Next".

The new session starts at your baseline plus about a thousand tokens. Compare that with the 106k my sessions carried after an auto-compact.

The note is also better than a summary in one way that matters: it records why. "We tried caching in Redis, it broke the tests, don't do it again" survives a handoff. It rarely survives a compaction.

Common mistakes (I made all of them)

Compacting twice in a row. A summary of a summary loses detail every time. If you're about to compact a second time, write a handoff instead.

Clearing mid-debug. You lose the stack traces and the list of things you already ruled out. Write the handoff first, even a five-line one.

Turning auto-compact off and forgetting. You can disable it in /config. Then you hit the context limit and the session just stops being useful. If you turn it off, watch your context percentage instead.

Not looking at the number. Put context usage in your status line. Claude Code passes the percentage to status line scripts, so you see 60% coming instead of meeting a compaction at 95%.

How to check your own numbers

Claude Code stores every session as a JSONL file under ~/.claude/projects/. Each compaction is logged as a line with "subtype": "compact_boundary", and it records how many tokens the session had before it.

This one-liner counts your compactions:

grep -h '"compact_boundary"' ~/.claude/projects/*/*.jsonl | wc -l

If that number is high, your sessions are too long. That's the whole diagnosis.

What I use now

I got tired of pasting the handoff prompt and writing status line scripts on every machine, so I packaged my setup. Full disclosure: I built it and sell it.

It includes a /handoff command that writes the note and reloads it after /clear, a status line that warns at 60% context, a hook that blocks junk file reads, and an audit script that prints numbers like the ones in this post. Everything above works without it. If you want it set up in two minutes, it's the Claude Code Limit Saver Kit.

The short version

/clear when the task is done. /compact once, with instructions, when it isn't. After that, write a handoff and start clean.

Run the grep above and tell me your count in the comments. Mine was 89 all-time, 67 of them last week, and I'd like to know if I'm the worst.

Originally published on Medium.

How I Stopped Hitting Claude Code Usage Limits

Md Ayan bag — Sat, 24 Oct 2026 18:37:04 +0000

"You've hit your usage limit." I saw that message three times in one week, every time in the middle of a task, with half-written code open in front of me.

So I stopped guessing and measured. I wrote a small script that reads Claude Code's own session logs on my Mac. The result was embarrassing: my median session peaked at 252,696 tokens. 160 of my 230 sessions that week went past 150k. My largest hit 967k.

Note: I used Claude Code to help build the audit script and draft this post. The numbers and screenshots are from my own machine.

Here is what was actually eating my limit, and the nine fixes that work. Most of them are free and take five minutes.

Why Claude Code usage limits drain so fast

Claude Code re-sends the whole conversation to the model on every turn.

Your CLAUDE.md, every MCP tool definition, every file it opened, every test log it printed, every message you sent. Turn 80 pays for turns 1 to 79 again.

So your limit isn't eaten by your questions. It's eaten by context size times number of turns. A session sitting at 200k tokens carries ten times more per turn than one at 20k.

Every fix below shrinks one of those two numbers.

1. Put the limit where you can see it

You can't manage what you only see when it's too late. Claude Code's status line receives your context percentage and, on Pro and Max, your 5-hour and weekly limit usage. Most people never turn it on.

Save this as ~/.claude/gauge.py:

import json, sys
d = json.load(sys.stdin)
ctx = (d.get("context_window") or {}).get("used_percentage") or 0
rl = d.get("rate_limits") or {}
five = (rl.get("five_hour") or {}).get("used_percentage")
week = (rl.get("seven_day") or {}).get("used_percentage")
print(f"ctx {ctx:.0f}% | 5h {five or 0:.0f}% | week {week or 0:.0f}%")

Then add this to ~/.claude/settings.json and restart:

"statusLine": {"type": "command", "command": "python3 ~/.claude/gauge.py"}

Now you see the problem building instead of meeting it at 100%.

2. One task per session, then /clear

This was my biggest leak. 137 of my sessions ran 80+ model turns, because I kept working in the same window all afternoon.

Finished a feature? Run /clear before the next one. Mid-task and context is above 60%? Ask Claude to write a short handoff note to a file (goal, what's done, next steps, key files), then /clear and point the new session at that note.

/compact vs /clear: compacting keeps a summary in the same session. It's fine once. Do it four times and you're dragging a blurry, still-heavy history around. A 40-line handoff plus a clear is cheaper, and you decide what survives.

3. Stop Claude from reading junk files

One accidental read of a lockfile or a minified bundle can add tens of thousands of tokens that ride along for the rest of the session.

Add deny rules to your project's .claude/settings.json:

{
  "permissions": {
    "deny": [
      "Read(./node_modules/**)", "Read(./dist/**)", "Read(./build/**)",
      "Read(./package-lock.json)", "Read(./pnpm-lock.yaml)", "Read(./**/*.min.js)"
    ]
  }
}

And name exact places in your prompts. "Fix the null check in src/lib/auth.ts around getUser" costs a fraction of "fix the login bug".

4. Keep CLAUDE.md under about 1,000 tokens

CLAUDE.md is loaded on every single turn. So is every CLAUDE.md in parent folders, which surprised me: mine was quietly pulling in a 1,800-token file from my home folder.

Keep it to the stack, the commands, where things live, and the few gotchas that bit you before. Move long docs into a docs/ folder and reference them by path. Claude opens them only when it needs them.

5. Turn off MCP servers you aren't using

Every MCP server injects its full tool list into context, on every turn. Run /mcp and disable what this project doesn't need. Three focused servers beat twelve "just in case" ones. The same goes for plugins you installed once and forgot.

6. Plan before Claude writes code

Press Shift+Tab for plan mode on anything non-trivial. Fixing a wrong approach after 40k tokens of code costs far more than reading a 2k-token plan and saying "no, do it this way".

Batch your asks, too. One message with three clear changes beats three back-and-forth turns that each re-send everything.

7. Use a cheaper model for mechanical work

Use your heaviest model for design and hard bugs, and switch with /model for renames, tests and docs.

Subagents can run on a lighter model too. Add model: haiku to an agent's frontmatter in ~/.claude/agents/ and send it the searching and boilerplate. The noise stays out of your main context.

8. Make Claude write less code

Ponytail is a free, MIT-licensed skill that pushes Claude to reuse what exists and skip speculative abstractions, without dropping validation or security. Its published benchmark on real Claude Code tasks shows about 54% less code and about 22% fewer tokens. I've had it on for weeks.

9. Measure every week

Your feeling about usage is wrong. Mine was. Claude Code keeps every session as a JSONL file under ~/.claude/projects/, with token counts on every response, so you can measure exactly how big your sessions get.

That's what my audit script does. It prints what your setup costs before you type a word, then your real session sizes for the week.

What I packaged up

Doing all of this by hand on every machine got old, so I turned my setup into a kit. Full disclosure: I built it and sell it.

It has the full limit gauge with colours and reset timers, a hook that blocks junk reads automatically, a /handoff command that saves the note and reloads it after /clear, the audit script, a local cost dashboard, a lean CLAUDE.md template and a 3-page playbook. It installs with one command and uninstalls with one command.

Everything in this article works without it. If you'd rather have it set up in two minutes, it's here: Claude Code Limit Saver Kit.

The short version

Your limit isn't spent on your questions. It's spent on carrying context. Watch the gauge, clear between tasks, block junk reads, keep CLAUDE.md lean, and measure.

What's your worst session? Run the numbers and tell me in the comments. I read every one.

Originally published on Medium.

Just Got a 256 GB MacBook? Set It Up So It Doesn’t Fill Up in a Year

Md Ayan bag — Thu, 22 Oct 2026 17:04:33 +0000

The MacBook Neo starts at $599 with 256 GB. The base MacBook Air has the same.

That’s plenty on day one. macOS takes about 25 GB, and you look at the 200-something GB left and think you’ll never fill it.

(I wrote this with help from an AI assistant. Every number is measured on my own Mac.)

I thought that too. My MacBook Air has a 245 GB disk. Today it has 4.13 GB free, and the biggest thing on it is not my photos or my projects. It’s a grey bar called “System Data” at 142.69 GB.

This post is the setup I’d do on a new 256 GB Mac, knowing what I know now. Most of it is free and built into macOS.

What actually fills a small Mac

Not what you’d guess. I measured mine folder by folder:

App data, 39.31 GB. The private folders apps keep in ~/Library/Application Support: databases, offline content, downloaded models. It grows quietly, and it stays behind when you delete the app.
Shared Library and Homebrew, 31.88 GB. That one’s on me. I’m a developer. If you don’t install command-line tools, yours will be small.
System caches and temp files, 10.93 GB. macOS manages these. Leave them alone.
Developer and AI caches, 7.8 GB. Package caches and AI models in hidden dot-folders.
Caches, 4.11 GB. Safe to clear, but they regrow.

The lesson: on a small disk, the problem isn’t one big file. It’s a hundred apps each keeping “just a little” data.

Step 1: Ten minutes in System Settings, before you install anything

General › Storage. Turn on Optimize Storage (removes TV shows you’ve watched) and Empty Trash Automatically (deletes Trash items after 30 days).
Photos › Settings › iCloud › Optimize Mac Storage. If you have a big photo library and an iCloud plan, this alone can save tens of gigabytes. Full photos stay in iCloud and download when you open them.
iCloud Drive › Optimize Mac Storage (in System Settings › your name › iCloud). Old files you haven’t opened stay in the cloud.
Messages › Settings › General › Keep messages: 1 year. Years of videos people sent you add up. Only do this if you’re fine losing old threads, or if Messages in iCloud has them.

Step 2: Don’t back up your iPhone to the Mac

One iPhone backup can be bigger than everything else in your home folder. If you plug your phone in and Finder offers to back it up “to this Mac”, say no and use iCloud Backup instead.

Already have one? Open Finder, click your iPhone in the sidebar, then Manage Backups to see the size and delete old ones.

Step 3: Install fewer apps, and uninstall properly

Every app you try for a day leaves files in your Library folder after you drag it to the Trash. Settings, caches, sometimes gigabytes of downloaded content.

Two rules I’d follow on a new Mac:

Try apps in the first week, then decide. Keep what you used. Delete the rest while you still remember what you installed.
Remove the leftovers too. Look in ~/Library/Application Support, ~/Library/Caches and ~/Library/Containers for folders named after the app. Or use an uninstaller that does it for you.

To see the biggest folders yourself (this deletes nothing):

du -sh ~/Library/* ~/.[!.]* 2>/dev/null | sort -h | tail -15

One catch: du counts APFS clones at full size, so a folder can look far bigger than it really is. Check free space before and after you delete anything.

Step 4: Put big files somewhere else

Videos and old projects: an external SSD. A 1 TB one often costs less than Apple’s storage upgrade.
Downloads: sort by size once a month. Installers (.dmg, .pkg) are safe to delete after you’ve installed the app.
Time Machine: plug in a drive in week one. It backs everything up, and it means you can delete with less fear.

Step 5: Watch the number, not the warning

macOS warns you when the disk is almost full. By then you have a few gigabytes and no idea what changed.

Write down your free space today. Check it once a month. If it drops 20 GB in a week, something changed that week, and you’ll know where to look.

What I use to keep an eye on it

Doing step 5 by hand got old, so I built Tidy Mac. Full disclosure: it’s my app.

It shows your free space in the menu bar, with a 7-day and 30-day trend. Its Home screen splits “System Data” into named parts, like the chart above. And Clean sorts caches into “Safe to clear”, “Worth a look” and “Kept”, so you don’t have to guess:

Everything goes to the Trash first, and History has Undo. It’s free to download and look around, and the first 500 MB of cleaning is free. After that it’s Pro, $9.99 once for 2 Macs. No account, and your files never leave your Mac.

You don’t need it to follow this checklist. Steps 1 to 4 are free and do most of the work.

How much free space does your Mac have right now? Tell me in the comments, with the size of the disk. I’m curious how fast everyone else’s fills up.

His Mac Cleaner Freed 3 GB. The Other 40 GB Was Hiding in “System Data”.

Md Ayan bag — Thu, 22 Oct 2026 04:50:29 +0000

A developer friend's MacBook Air kept saying the disk was almost full. He was already paying for CleanMyMac. He ran its clean-up, and it freed about 3 GB.

Then he looked inside the grey bar every Mac owner has learned to hate: System Data. About 40 GB came back from inside it.

The cleaner wasn't broken. It was looking in the wrong places. On a developer's Mac, most of the space isn't caches or logs. It's build files, simulators, package caches and old installers, all filed under System Data.

Check your own Mac in one command

It only measures; it deletes nothing.

du -sh ~/Library/Developer ~/Library/Caches ~/.npm ~/Library/Containers/com.docker.docker ~/Library/Application\ Support/MobileSync/Backup 2>/dev/null

A missing line means the folder doesn't exist (or Terminal needs Full Disk Access). Anything over 5 GB is worth a look.

1. Xcode build files

~/Library/Developer/Xcode/DerivedData rebuilds itself on the next build. Quit Xcode, then empty it.

2. Simulators and device support

xcrun simctl delete unavailable

Remove old simulator runtimes in Xcode → Settings → Components (Platforms in older Xcode).
~/Library/Developer/Xcode/iOS DeviceSupport keeps a folder per iOS version per device. Delete the old ones; Xcode copies them again when needed.

3. Package caches

npm cache clean --force
brew cleanup --prune=all
pip cache purge

Old node_modules in projects you no longer touch add up too. npm install brings them back.

4. Old installers

find ~/Downloads -maxdepth 1 \( -name "*.dmg" -o -name "*.pkg" \) -exec du -sh {} +

Plus any "Install macOS" app in Applications.

Not on his Mac, but check yours

iPhone backups: Finder → your iPhone → Manage Backups.
Docker: docker system df, then docker system prune for what's unused.
Time Machine snapshots: tmutil listlocalsnapshots /. Leave them; macOS removes them when it needs space.

What not to delete

Anything under /System, or whole folders in ~/Library. Delete specific items, never the parent.
~/Library/Mobile Documents (that's iCloud Drive).
Anything inside the Photos library.

When in doubt, move it to the Trash and empty it a week later.

Is a cleaner worth paying for?

If you don't write code and your photos live in iCloud, probably not: turn on the recommendations in System Settings → General → Storage.

If System Data is huge and you'd rather not hunt folder by folder, an app that names every part of it saves the time.

Full disclosure: I build Tidy Mac, the app my friend used. The download is free and shows everything filling your Mac; cleaning past the first 500 MB is $9.99 once, for two Macs. Full case study: CleanMyMac freed 3 GB, Tidy Mac found 40 GB.

How big is your System Data? Tell me in the comments.

Written with help from an AI assistant. The 3 GB and 40 GB figures are from my friend's Mac.

Build a chat-style intake flow from your server with six curl calls

Md Ayan bag — Wed, 21 Oct 2026 03:30:00 +0000

Every "conversational" intake form I have built from scratch ended up the same way: a state machine in a route handler, a switch on the current question, hand-written validation for each field, and a branching table nobody wanted to touch after launch. Then product asks for "ask a follow-up if the answer is vague", and now there is a model call in the middle of the state machine too.

The alternative is to let a form engine drive the conversation and keep only the UI. This tutorial walks through chatform's headless API: you open a session on a published form, post answers, and the engine tells you what to ask next, what was rejected and when the conversation is complete. Everything below comes from the docs at chatform.in/docs; I have not invented any response fields.

What you need

A published chatform form. Every question has a ref like q_email; that is how you address it.
A secret key from Settings → API keys. It starts with sk_live_ (or sk_test_, which writes rows flagged as test data and never fires webhooks). Keep it on your server.
curl and jq. The Node snippet at the end uses the built-in fetch, so Node 18 or newer.

Export two variables so the commands below paste cleanly:

export CHATFORM_SECRET_KEY=sk_test_...
export FORM_ID=...

1. Check the key

curl https://api.chatform.in/v1/me -H "x-api-key: $CHATFORM_SECRET_KEY"

This returns the organization the key belongs to, its scopes, and what is left of the plan. If this call fails, nothing else will work, so start here. A 401 with code invalid_api_key means the key is not one the API knows. You can also send the key as authorization: Bearer sk_..., but never in a query string; /v1 refuses keys in URLs.

2. Read the form's questions

curl https://api.chatform.in/v1/forms/$FORM_ID -H "x-api-key: $CHATFORM_SECRET_KEY"

Note the ref of each block. If the form is not live you get not_published; the draft is readable with ?view=document, but it takes no responses until you publish it.

3. Open a session

A session is a conversation on a published form, driven by you instead of the hosted page.

curl -X POST https://api.chatform.in/v1/forms/$FORM_ID/sessions \
  -H "x-api-key: $CHATFORM_SECRET_KEY" \
  -H "content-type: application/json" \
  -d '{"hiddenFields": {"plan": "trial"}}'

Response:

{
  "sessionId": "chs_…",
  "respondentToken": "…",
  "expiresAt": 1788592149473,
  "streamUrl": "/v1/sessions/chs_…/events",
  "greeting": "Hi! Let's get started.",
  "question": { "ref": "q_email", "type": "email", "title": "What's your email?" }
}

The body also accepts externalId (your own id for the respondent, up to 200 characters) and expiresIn in seconds, between 300 and 2,592,000. Save sessionId:

export SESSION_ID=chs_...

Two things worth knowing. The close date, response ceiling and submission cap of the hosted form all apply here. The form password and captcha do not, because an API key is stronger proof than a password and there is no browser to solve a captcha.

The respondentToken is the piece that makes a browser front end safe. It is scoped to this one session and expires, so you hand it to the page and keep the secret key on the server. If a request carrying a secret key arrives with an Origin header, the API refuses it with secret_key_in_browser and tells you to rotate the key.

4. Answer the question

curl -X POST https://api.chatform.in/v1/sessions/$SESSION_ID/messages \
  -H "x-api-key: $CHATFORM_SECRET_KEY" \
  -H "content-type: application/json" \
  -d '{"type": "structured", "ref": "q_email", "value": "maya@northwind.co"}'

There are two message shapes. structured is an answer to a specific question, what a form control would produce. text is free text the engine interprets against whatever it just asked:

{ "type": "text", "text": "we're about a dozen people" }

Either way the reply is the whole turn:

{
  "accepted": true,
  "assistantMessages": ["Got it. And what's your role?"],
  "question": { "ref": "q_role", "…": "…" },
  "validation": null,
  "complete": false,
  "awaitingSubmit": false,
  "events": [{ "seq": 7, "type": "answer_recorded", "…": "…" }],
  "answers": { "q_email": "maya@northwind.co" }
}

Your loop is: render assistantMessages, render question, collect an answer, post it, repeat. A rejected answer is not an HTTP error. You still get accepted: true, plus a validation object with ref, code and message, and the same question again. The message is the same text a respondent would see, so you can show it as is.

When the engine reaches an ending, question is null and ending carries ref, title, bodyMd and a kind of success or screen_out.

5. Submit

Forms default to showing a review step before finishing. When awaitingSubmit is true, the session is waiting for exactly one thing:

curl -X POST https://api.chatform.in/v1/sessions/$SESSION_ID/actions \
  -H "x-api-key: $CHATFORM_SECRET_KEY" \
  -H "content-type: application/json" \
  -d '{"action": "submit"}'

Without this, such a form can never complete. The same endpoint takes skip, stop, restart and edit (with a ref), so back buttons and "start over" links are one call each.

6. Read state, or catch up after a drop

curl https://api.chatform.in/v1/sessions/$SESSION_ID \
  -H "x-api-key: $CHATFORM_SECRET_KEY"

Session state includes status, currentRef, answers, awaitingSubmit, completedAt and a summary array of { ref, title, display }, which is handy for a review screen.

The events endpoint has two modes. With accept: text/event-stream it is a server-sent event stream, and every event carries a seq. Without that header it returns a JSON page:

curl "https://api.chatform.in/v1/sessions/$SESSION_ID/events?since=12" \
  -H "x-api-key: $CHATFORM_SECRET_KEY"

That returns { events, latest_seq, has_more }. Keep the highest seq you have seen and you can resume exactly where you left off.

The same loop in Node

const BASE = "https://api.chatform.in/v1";
const headers = {
  "x-api-key": process.env.CHATFORM_SECRET_KEY,
  "content-type": "application/json",
};

async function openSession(formId) {
  const res = await fetch(`${BASE}/forms/${formId}/sessions`, {
    method: "POST", headers, body: JSON.stringify({}),
  });
  return res.json(); // { sessionId, respondentToken, question, ... }
}

async function answer(sessionId, ref, value) {
  const res = await fetch(`${BASE}/sessions/${sessionId}/messages`, {
    method: "POST", headers,
    body: JSON.stringify({ type: "structured", ref, value }),
  });
  return res.json(); // { accepted, validation, question, complete, awaitingSubmit, ... }
}

Hand sessionId and respondentToken to the page; keep everything else behind this module.

Errors you will actually hit

Every error uses one envelope: { "error": { "code", "message", "issues", "request_id" } }. The request_id is also the X-Request-Id header on every response, so log it.

401 unauthorized, invalid_api_key, api_key_disabled, api_key_expired. Wording is identical on purpose; read the code.
403 secret_key_in_browser, origin_not_allowed, insufficient_scope. A key with only form:read cannot start a session.
403 on opening a session means the form is closed, capped, or over its response ceiling.
404 is also what you get for a form that belongs to another tenant. That is deliberate.
400 invalid_request with issues[] naming each bad field, or malformed_json for a JSON content type with a body that is not JSON. An empty body counts.
202 on a message is not a failure. An interview turn may involve a model call. Past the deadline you get 202 with sinceSeq and a pollUrl. Pass ?deadlineMs= to pick your own deadline, up to 25 seconds.
429 rate_limited with Retry-After in seconds. Retry it. 402 limit_reached means the monthly quota is spent and retrying is futile.

Where to go next

GET /v1/blocks returns every question type with its config schema, the shape you receive and the shape you send. Build your renderer against that and new block types will not surprise you.
File questions are answered by uploading: register an intent, PUT the bytes, confirm.
Forms with sign-in emit auth_required and accept Google, phone or email proof on dedicated routes.
If you would rather not write the HTTP, there is a typed JavaScript client and React bindings.

Disclosure: I work on chatform. This post was drafted with AI assistance and checked against the docs by hand. The full headless reference, including streaming, verified answers and payments, is at chatform.in/docs/headless.

81% of People Abandon Forms. Here's How I Get Them Back Without Rebuilding Anything.

Md Ayan bag — Tue, 20 Oct 2026 17:00:00 +0000

Most people who open your form will not finish it. In The Manifest's survey, 81% said they had abandoned at least one online form recently. Across the industry the number that gets quoted is around 67% of starts never reaching submit.

I work on chatform, a form builder, so I see these numbers every day across other people's forms. That's my stake, and I'll say when I'm talking about my own product. I used an AI assistant to help outline this and wrote and checked the rest myself.

What follows is the order I'd fix things in, starting with changes that cost nothing and work in any form tool, including Google Forms. The product comes last, and you won't need it for most of this.

First, find the question where they leave

Abandonment is not a single number. It's a cliff at one question. Nine times out of ten it's a field asking for more than the person wants to give at that point: a phone number, a budget, a home address for a digital product.

Most builders show a drop-off per question somewhere in their analytics. If yours doesn't, split the form into two pages and compare submissions on page one against page two. That's a crude funnel and it's enough to find the cliff.

Once you know the question, you have three options: make it optional, move it later, or delete it.

Make the phone number optional

I know sales wants it. A required phone field is the single most common reason people quit a form. Make it optional and ask for it again in the thank-you email. You'll lose a few numbers and gain a lot of completed forms, and a completed form with an email is a lead you can still call once they reply.

Say how long it takes, and show progress

In the Loqate survey, people said they often don't know whether finishing a form is worth the effort. Tell them: "Eight questions, about three minutes." Multi-step forms without a progress indicator abandon about 20% more than forms that show where you are. Both fixes are a sentence and a checkbox in most tools.

Put the easy questions first

Ask for the name before the budget. Ask for the kind of project before the email. People who've answered three easy questions have invested something, and they finish more often than people who hit a wall at question one. This is the same reason a chat feels lighter than a page of fields: one small ask at a time.

Keep what they've already typed

This is the one most people skip, and it's where the real money is. If someone answers five of eight questions and closes the tab, those five answers are gone in most form tools unless you turn on partial saving. Gravity Forms calls it partial entries, HubSpot users ask for it in the community forum every month, and the newer builders have it as a toggle.

Turn it on. A half-finished response with a name and an email is still a lead. It's also how you find out which question is the cliff, because you can see exactly where each person stopped.

Then email them a way back

Here's what almost nobody does. The person who left at question six was interested enough to answer five. A reminder that lands them on question six, with the first five already filled in, is the cheapest lead you'll ever recover.

This isn't a hunch. Sauermann and Roach's 2013 study in Research Policy on survey reminders found that varying the timing and wording of follow-ups raised response rates, and that the people who come back after a reminder are not the same people who would have answered anyway.

How to do it with no special tool: collect the email as question one or two, turn on partial saving, and once a day export the partials and send a short plain-text email with the form link. It takes ten minutes a day. It works.

Fix the answers, not just the count

Completion is only half the problem. The other half is what's in the completed forms. Ask "what went wrong with the last tool you tried" on a page of fields and you'll get "it was bad", "n/a", and "pricing". Those are rows you throw away.

Xiao and colleagues published a study in ACM Transactions on Computer-Human Interaction in 2020 comparing a standard web survey with a chat-based one that asked a follow-up when an open answer was thin. The chat version got longer, more specific answers to the open questions. People will say more when something asks them to.

If your tool can't follow up, the manual version is to write the follow-up into the question itself: "What went wrong, and what were you trying to do when it happened?" Two-part questions get two-part answers.

What I built when the manual version got old

Doing the export-and-email loop by hand every morning is fine for a month. Then it's a chore, and the follow-up questions you wrote into the form get skipped by the people in a hurry anyway.

So this is the part I work on. chatform runs the form as a conversation. When a free-text answer is too thin to use, it asks one more question in plain words and records the real answer. Choices and scales are matched exactly and never sent to a model. When someone leaves, it saves every answer they gave and emails them up to three times, four hours, then a day, then three days later, with a link that opens on the question they stopped at. If they've finished in the meantime, the reminder is dropped.

Full disclosure: I'm on the team that builds it. The free plan has unlimited responses; the follow-up emails and partial responses are on the paid plan. If the manual loop above is already working for you, you don't need it. If you'd rather not run the loop by hand, the chatform home page has a live form you can try before signing up.

The order, one more time

Find the question where people leave.
Make the phone number optional.
Say how long it takes and show progress.
Put the easy questions first.
Save partial answers.
Email a way back to the exact question.
Ask a follow-up when the answer is thin.

Do the first four this afternoon. They're free in every tool. Then look at your completion rate next week and decide whether the last three are worth automating.

AI disclosure: I used an AI assistant to help outline and structure this post. The facts and prices were checked by hand on 20 October 2026.

Originally published on Medium.

Typeform Gives You 10 Free Responses a Month. I Tested 6 Tools That Don't.

Md Ayan bag — Tue, 20 Oct 2026 14:00:00 +0000

Typeform's free plan stops at 10 responses a month. Not 10 per form. Ten across your whole account. I found this out the way most people do: a form I had shared in a newsletter went quiet on day three, and the dashboard told me the rest.

I work on chatform, a form builder, so I have an obvious stake here. I'll label my own tool clearly and I'll tell you where the others beat it. I used an AI assistant to help structure this piece and checked every price against the vendor's own pricing page on 20 October 2026.

No WordPress plugins, no enterprise survey suites. Just six tools you can sign up for today, the real free limit on each, and what breaks when you outgrow it.

Why the 10-response cap matters more than it sounds

Ten responses is a demo, not a plan. A contact form on a small site gets more than that in a week. The first paid plan, Basic, is $25 a month billed yearly or $39 billed monthly, and it caps you at 100 responses. Plus is $79 for 1,000. Business is $129 for 10,000.

So the question is never "is Typeform good". It is. The question is whether you want to pay per answer for a form that mostly asks for a name and an email.

Here's what I found when I rebuilt the same six-question lead form in each of these.

1. Tally: the best free form builder, full stop

Tally gives you unlimited forms and unlimited responses on the free plan. The editor works like a Notion page: you type a question, press slash, pick a block. It is the fastest builder on this list by a wide margin.

Where it falls short: the form is a page of fields or one-per-screen, and that's it. Custom domains, team seats and removing the Tally badge are on Pro at $29 a month. There's no AI, which is a feature or a gap depending on what you need.

Pick Tally if you want a clean form, unlimited answers, and nothing clever.

2. Youform: the closest copy of Typeform's look

If what you like about Typeform is the one-question-at-a-time feel with big type and a progress bar, Youform is the nearest match. Unlimited forms and responses free, and Pro starts at $20 a month billed yearly.

Where it falls short: it's a format, not a conversation. It shows the next card whatever you typed in the last one. Integrations are thinner than Typeform's.

3. Fillout: the one to pick if your data lives in Airtable or Notion

Fillout's free plan gives you 1,000 responses a month, and paid starts at $15 a month billed yearly. Its strength is writing straight into Airtable, Notion, Google Sheets and about fifty other tools without a Zapier step.

Where it falls short: 1,000 a month is generous, but it is still a cap. The builder has a lot of surface area, which is good once you learn it and slow on day one.

4. Formbricks: the open-source option you can self-host

Formbricks is AGPLv3 and free to run on your own server with Docker. The hosted cloud has a free plan of 250 responses a month. It was built for in-app product surveys first, so it's strong on targeting who sees a survey and when.

Where it falls short: if you don't want to run a server, 250 a month is the smallest free number on this list. The link-form experience is plainer than the in-app one.

Pick it if "we must own the data" is a requirement and you have someone who can keep a Docker container alive.

5. Google Forms: free, unlimited, and ugly on purpose

I'm including it because it is the honest answer for a lot of people. Any Google account, unlimited responses, straight into Sheets. Nobody has ever been fired for using it.

Where it falls short: the design is the design. Logic is basic. People fill it in like a tax form, which is to say fast and with as few words as they can get away with.

6. chatform (I work on this one)

Full disclosure: this is the tool I help build, so weigh what follows accordingly.

The free plan has unlimited responses, with a fair-use ceiling of 10,000 a month, across up to 100 forms. Logic, scoring, signatures, file uploads, Google Sheets and webhooks are all on Free. Pro is $16 a month billed yearly.

The reason it exists is not the price. It's that every tool above records whatever lands in the field. If someone types "it was bad" into "what went wrong", that's the row you get. chatform runs the form as a chat and asks one more question when the answer is too thin to use, then records the real answer. Choice and scale answers are matched exactly and never sent to a model; only free text is read.

It also emails people who leave halfway, with a link back to the question they stopped on. That part is on Pro.

Where it falls short: no video questions. One native integration (a spreadsheet feed) plus webhooks and an API, where Typeform has hundreds of connectors. The template gallery is a few hundred, not thousands. There's no Typeform importer, though you can paste the URL of your existing form and it drafts the questions from it.

You can try it without an account on the chatform vs Typeform page, which also lists its gaps in a table.

The honest decision tree

You want the cleanest free form and nothing else: Tally.
You want it to look like Typeform: Youform.
Your data lives in Airtable or Notion: Fillout.
You must self-host: Formbricks.
You don't care how it looks: Google Forms.
Your problem is thin answers and people who leave halfway: chatform.
You need video questions and a huge integration catalogue, and the budget is there: stay on Typeform.

Before you switch, export

Whatever you move to, your old responses stay in the old tool. Export them first. And remember every link you've ever shared points at the old form, so replace the embed on your site and update the link in your bio before you cancel.

If you've hit the 10-response wall and tried something I missed, tell me in the responses. I'll add it with the same "where it falls short" line as everything else.

AI disclosure: I used an AI assistant to help outline and structure this post. The facts and prices were checked by hand on 20 October 2026.

Originally published on Medium.

Updating to macOS 27 Golden Gate? Check Your "System Data" First

Md Ayan bag — Tue, 20 Oct 2026 06:02:43 +0000

The Mac subreddits are full of the same post this week. Someone updates to macOS 27 Golden Gate, opens Storage settings, and finds "System Data" at 150 GB. Deleting documents doesn't move the bar. Sometimes it grows back after they've deleted 100 GB.

I haven't updated yet. I'm still on macOS 26 Tahoe, and my System Data was already 147 GB of a 245 GB disk. So before installing Golden Gate, I split that grey bar into its parts.

Why deleting documents doesn't help

Storage settings only names a few things: Apps, Documents, Photos, Mail, iCloud. Everything else lands in System Data: app data, caches, backups, snapshots, swap. So the "Documents" number is small, and the grey bar is where the space actually went.

What was inside mine

App Support Data, 37.55 GB. Folders apps keep in ~/Library/Application Support. On my Mac it's mostly AI tools; the Claude desktop app alone is 13 GB.
Shared Library & Homebrew, 31.92 GB. Developer tools in /opt/homebrew and shared app data.
Virtual memory (swap), 20.44 GB. Memory macOS parked on disk. A restart clears most of it.
Other Library data, 13.54 GB, and App Containers, 4.9 GB. More per-app data.
Not measurable, 11.21 GB. Parts macOS won't let any app measure directly.
System caches and temp files, 10.62 GB, plus Caches, 4.77 GB. Rebuilt on their own.
Developer and AI caches, 8.43 GB. Package and model caches.
System assets and AI models, 3.83 GB. Apple Intelligence and other downloaded system parts.

Why it jumps after a macOS update

Time Machine local snapshots. macOS keeps snapshots on your own disk. Files you delete stay inside them, which is why space doesn't come back after a big cleanup.
Re-indexing. After an update, Spotlight and Photos re-scan everything. That fills caches and swap for a day or two.
Apple Intelligence. Its models download after the update and count as system storage.
The installer itself. A major update needs roughly 20–40 GB free. Near full, it fails or the Mac crawls.

What to do before updating (10 minutes)

Restart. That alone clears most swap.
Check snapshots in Terminal. If the first command lists any, the second removes them. Backups on your external drive aren't touched.

tmutil listlocalsnapshots /
sudo tmutil thinlocalsnapshots / 999999999999 4

Open Finder › your iPhone › Manage Backups and delete backups of old devices.
See your biggest app folders:

du -sh ~/Library/Application\ Support/* 2>/dev/null | sort -h | tail

If you use Homebrew: brew cleanup --prune=all
Start the update with at least 30–40 GB free.

What not to delete

Anything in /System, your ~/Library/Preferences, and the folders of apps you still use. Manage Photos, Mail and Messages from inside those apps. And never "clean" the whole Library folder: move things to the Trash one at a time, so a mistake costs nothing.

Full disclosure: I build Tidy Mac, the app in the screenshot. It splits System Data into named parts like these and moves what you pick to the Trash with Undo. You don't need it for the steps above. If you just want to know whether one folder is safe to delete, there's a free checker, and a longer guide to System Data on macOS 27.

Drafted with AI assistance. Every number is from my own Mac.

Homebrew Was Using 25.6 GB of My Mac. Anaconda's Cache Alone Was 5 GB.

Md Ayan bag — Tue, 20 Oct 2026 04:55:16 +0000

Last week I found AI coding tools hiding 32 GB on my MacBook. Claude, Codex, Cursor and Gemini were all sitting inside the grey "System Data" bar that macOS won't let you open.

So I kept going. The next biggest thing in there wasn't an app at all. It was Homebrew: 25.6 GB in /opt/homebrew.

I don't think of Homebrew as big. You type brew install, something appears, you move on. But every install leaves things behind, and a few of them are enormous.

Anaconda: 9.17 GB, and 5.21 GB of it is a cache

I installed Anaconda once for a data course. It's still here: 9.17 GB, plus an 882 MB copy of its installer that Homebrew keeps.

More than half of that, 5.21 GB, is anaconda3/pkgs: a copy of every package conda has ever downloaded, kept so the next install is faster. Your environments don't need it.

conda clean --all

That removes the cached packages and tarballs and leaves your environments alone. If you don't use conda anymore at all:

brew uninstall --cask anaconda

That's the whole 9.17 GB plus the installer copy.

Flutter: 4.1 GB

The Flutter SDK lives in /opt/homebrew/share/flutter. If you build Flutter apps, keep it. If you tried it once, brew uninstall --cask flutter gives back 4 GB.

Three Java versions: about 1 GB

I had openjdk, openjdk@17 and openjdk@11 installed side by side. Before removing an old one, check what still depends on it:

brew uses --installed openjdk@11

If that prints nothing, it's safe to brew uninstall openjdk@11.

Things you installed once and forgot

Hadoop (1.59 GB), MongoDB, Pandoc, Go. Each one was a reason at the time. This lists only the packages you installed, not their dependencies, which makes forgotten ones easy to spot:

brew leaves

The two commands everyone should run

brew cleanup --prune=all   # old versions and every cached download
brew autoremove            # dependencies nothing needs anymore

Neither touches anything you still use.

Why macOS calls this "System Data"

/opt/homebrew isn't in your home folder, so macOS's Storage settings can't put it under Apps or Documents. It goes into System Data, alongside app caches and AI models. On my Mac, "Shared Library & Homebrew" alone was 32 GB of the 147 GB System Data bar.

The rule I follow now: caches are always safe, SDKs you don't use are the biggest wins, and anything with your data in it is a decision you make on purpose.

I build Tidy Mac, which is how I measured all of this. It breaks System Data into named parts like this one, and anything you clear goes to the Trash first. The commands above work without it.

Drafted with AI assistance. Every number was measured on my own Mac.

AI Coding Tools Were Quietly Using 32 GB of My Mac. Claude Alone Took 13.

Md Ayan bag — Mon, 19 Oct 2026 20:23:09 +0000

My MacBook told me its disk was almost full. 5.5 GB free out of 245 GB. My Pictures folder is 93 MB. My Documents folder is under 40 MB.

So where did 240 GB go?

macOS had an answer, sort of: "System Data", 147 GB. More than half the disk, in one grey bar, with no way to click into it.

I measured what was inside it, folder by folder. The surprise wasn't old caches or forgotten installers. It was the AI tools I use every day. Claude, Codex, Cursor, Gemini and a couple of local models were holding about 32 GB between them, and almost none of it shows up anywhere you'd think to look.

Why it all hides in "System Data"

macOS's Storage settings only name a few things: Apps, Documents, Photos, Mail, iCloud. Everything an app saves for itself lands in ~/Library/Application Support or in hidden folders in your home folder like ~/.codex and ~/.cache. macOS counts all of that as System Data.

AI tools are the heaviest users of exactly those places. They download runtimes, sandboxes and models, and they keep every session you've ever had.

Here's what I found on my Mac, measured with APFS clones counted once (so the numbers match what you'd actually get back):

Claude desktop app: 13.08 GB, of which 10.22 GB is one folder, vm_bundles
Gemini / Antigravity (~/.gemini): 5.31 GB
Codex (~/.codex): 3.6 GB, plus 1.99 GB of runtimes in ~/.cache/codex-runtimes
Cursor: 3.56 GB, mostly 2.83 GB in globalStorage
Claude Code (~/.claude): 2.8 GB, 2.61 GB of it old session transcripts
Hugging Face model cache: 952.8 MB
Whisper speech models: 628.9 MB

That's roughly 32 GB. On a 256 GB MacBook, that's one eighth of the disk.

What each one is, and what's safe to delete

Claude desktop: ~/Library/Application Support/Claude
The 10 GB vm_bundles folder is the virtual machine image Claude uses to run tasks in a sandbox. People on Reddit and in Claude's GitHub issues report the same 10–13 GB. You can delete it with Claude quit, but if you use those features it downloads again. Cache and Code Cache (about 500 MB here) are safe to clear any time.

Claude Code: ~/.claude/projects
Every conversation is saved as a JSON file so you can resume it, and a single long session can pass 100 MB. Delete old project folders you'll never resume; you only lose the ability to pick those sessions back up.

Codex: ~/.codex and ~/.cache/codex-runtimes
Runtimes and packages Codex downloads to run code. The cache folder re-downloads when needed, so it's safe to clear if you're short on space today.

Gemini and Antigravity: ~/.gemini
Google's Antigravity IDE keeps its data and backups here. If you tried Antigravity once and moved on, this is easy space back. If you use it daily, leave it.

Cursor: ~/Library/Application Support/Cursor
Careful with this one. User/globalStorage holds Cursor's settings and chat history database, so don't delete it blindly. Old folders in User/workspaceStorage, for projects you've deleted, are safe to remove.

Hugging Face and Whisper: ~/.cache/huggingface and ~/.cache/whisper
Downloaded models. Delete the ones you don't use (huggingface-cli delete-cache lets you pick); anything you delete downloads again the next time a tool asks for it.

Check your own Mac in 30 seconds

du -sh ~/Library/Application\ Support/* 2>/dev/null | sort -h | tail -10
du -sh ~/.[!.]* 2>/dev/null | sort -h | tail -10

The first line shows the ten biggest app data folders. The second shows the ten biggest hidden folders in your home. If you use AI coding tools, I'd bet at least three of them are in those lists.

The rule I follow now

Caches and downloaded models are safe: they come back on their own. Anything that holds history (chat databases, session transcripts) is yours: decide it on purpose. And nothing gets deleted permanently on the first pass. It goes to the Trash first, so a mistake costs you nothing.

Full disclosure: I build Tidy Mac, the app in these screenshots, because I got tired of doing this with du every few weeks. It names what's inside System Data, including AI tools and developer caches, with sizes that match Disk Utility, and everything goes to the Trash with Undo. It's a one-time purchase, no subscription.

But you don't need it to fix this. The two commands above and ten minutes will find most of it. If you want to go deeper on any one folder, I wrote up what's in Application Support, the Hugging Face cache and what System Data really is.

If your Mac says it's full and you use Claude, Codex or Cursor, start with those folders. Mine had 32 GB waiting.

du Said Chrome Was Using 67 GB on My Mac. APFS Said 2. Here's a Script to Tell the Difference

Md Ayan bag — Sun, 18 Oct 2026 04:36:25 +0000

My MacBook Air was down to 18 GB free, so I went hunting. The biggest folder on the whole disk, according to du, was this:

/private/var/folders/…/X/com.google.Chrome.code_sign_clone   67G

Inside: 48 full copies of Google Chrome. None of them the version I actually have installed.

Then I measured it the way APFS actually stores it, and the 67 GB turned into about 2. Here's the folder, the trap, and a 30-line Swift script that measures any folder the same way.

(Written with help from an AI assistant. Every number and command was run on my own Mac.)

Check yours (read-only)

ls "$(getconf DARWIN_USER_TEMP_DIR)/../X/com.google.Chrome.code_sign_clone" | wc -l
du -sh "$(getconf DARWIN_USER_TEMP_DIR)/../X/"*

Mine printed 48 and 67G.

From what I can tell, Chrome makes one of these each time it launches after an update. The running browser keeps a validly signed copy of itself while the new version is swapped in underneath. They're meant to be temporary. On my Mac they weren't: 3 copies of Chrome 154 and 45 of 155.0.8059.40, while /Applications has 155.0.8059.80.

The trap: `du` doesn't understand clones

APFS can clone a file. The clone looks like a full copy to every tool, but it shares blocks with the original until one side changes. Chrome makes its copies as clones.

du, Finder's Get Info and most disk-map apps add every clone up at full size. 48 × ~1.4 GB = 67 GB that mostly doesn't exist.

APFS will tell you the truth, you just have to ask through getattrlist:

ATTR_CMNEXT_CLONEID: which clone family a file belongs to
ATTR_CMNEXT_EXT_FLAGS: bit 0 means "may share blocks"
ATTR_CMNEXT_PRIVATESIZE: bytes that belong only to this file

So: for each clone, count its private bytes, and count the shared part once per family.

The script

import Foundation

// Usage: swift realsize.swift <folder>
// Counts APFS clones once: each clone adds only its private bytes,
// and the shared blocks are counted once per clone family.
func attrs(_ path: String, _ bits: UInt32, _ n: Int) -> [UInt64]? {
    var al = attrlist(); al.bitmapcount = u_short(ATTR_BIT_MAP_COUNT); al.forkattr = bits
    var buf = [UInt8](repeating: 0, count: 4 + 8 * n)
    return buf.withUnsafeMutableBytes { b in
        guard getattrlist(path, &al, b.baseAddress, b.count, 0x21) == 0 else { return nil }
        return (0..<n).map { b.loadUnaligned(fromByteOffset: 4 + 8 * $0, as: UInt64.self) }
    }
}
let root = CommandLine.arguments[1]
var naive: Int64 = 0, real: Int64 = 0, families = Set<UInt64>()
let e = FileManager.default.enumerator(atPath: root)!
while let rel = e.nextObject() as? String {
    let p = root + "/" + rel
    var st = stat(); guard lstat(p, &st) == 0, st.st_mode & S_IFMT == S_IFREG else { continue }
    let full = Int64(st.st_blocks) * 512; naive += full
    // ATTR_CMNEXT_CLONEID | ATTR_CMNEXT_EXT_FLAGS; flag 1 = may share blocks
    if let c = attrs(p, 0x100 | 0x200, 2), c[1] & 1 != 0, let priv = attrs(p, 0x8, 1)?[0] {
        real += Int64(priv)
        if families.insert(c[0]).inserted { real += full - Int64(priv) }  // shared part, once
    } else { real += full }
}
let g = 1_073_741_824.0  // GiB, same unit as du -h
print(String(format: "du-style: %.1fG   on disk: %.1fG", Double(naive) / g, Double(real) / g))

0x21 is FSOPT_ATTR_CMN_EXTENDED | FSOPT_NOFOLLOW. You need Xcode's command line tools for swift.

On the Chrome folder:

$ swift realsize.swift "$(getconf DARWIN_USER_TEMP_DIR)/../X/com.google.Chrome.code_sign_clone"
du-style: 67.3G   on disk: 2.1G

67 GB on paper, about 2 GB on disk. Still waste (those clones keep old Chrome versions' blocks alive), but a 30× smaller problem.

It's a simplification: a file's "shared" part can be shared with files outside the folder, so treat the result as "roughly what deleting this folder gives back". (My app's stricter version credits those blocks to whichever file owns them, and lands on 1.8 GB for the same folder.) The honest final check is always df -h / before and after (and empty the Trash).

Should you delete them?

Probably fine, with two rules: quit Chrome completely first (Cmd-Q), and expect them back after the next update. Open the folder with:

open "$(getconf DARWIN_USER_TEMP_DIR)/../X"

…and drag com.google.Chrome.code_sign_clone to the Trash. Expect a GB or two back, not 67.

Why I care

Clones are everywhere now: Finder's Duplicate, pnpm's store, Chrome's copies. Any disk tool that sums file sizes will show you folders bigger than your drive, and you'll delete things expecting space you never get.

I ran into this while building Tidy Mac, a Mac cleaner. Full disclosure: it's mine. It counts clones once like the script above, labels what's safe to clear, and moves everything to the Trash first.

How many copies did your Mac have? Post your ls | wc -l in the comments. I'm curious if anyone beats 48.

'It Was Bad.' 'Bad How?' — What Happens When You Let a Form Ask a Follow-Up Question

Md Ayan bag — Thu, 01 Oct 2026 17:40:44 +0000

Every form you've ever built has shipped with the same silent bug: it accepts whatever someone types and moves on.

Someone writes "it was bad" in a feedback field, and your form says, in effect, great, thanks — and stores three useless words forever. Nobody follows up. Nobody asks "bad how — the price, or something it couldn't do?" The person who typed that answer probably has a clear reason. Your form just never asked for it.

That's not a UX nitpick. It's a data quality problem that gets worse the more forms you ship, and it's the specific thing we set out to fix with Chatform.

The gap isn't completion rate, it's answer quality

Most form-builder benchmarking obsesses over completion rate: did the person finish all the fields? That's measurable, so it's what gets optimized. But a 100%-complete form full of one-word non-answers is not a win — it's a worse failure mode than abandonment, because it looks like success in your dashboard.

There's actual research behind this, not just a hunch:

Xiao et al. (ACM Transactions on Computer-Human Interaction, 27(3), 2020) found that conversational, one-question-at-a-time interfaces produce meaningfully higher-quality open-ended answers than static multi-field forms — people elaborate more when they're asked, not just prompted.
Sauermann & Roach (Research Policy, 42(1), 2013) showed that follow-up contact (not just the initial ask) is what recovers a huge share of otherwise-lost survey responses — the first send is never the whole story.

Put those together and you get the actual shape of the problem: forms lose good data twice — once when an answer is too thin to be useful, and again when the person leaves before finishing at all. Static forms have no mechanism for either.

What "asking a follow-up" actually requires

This is the part that's interesting as a builder, not just as a marketer. Making a form ask a good follow-up question isn't "add a chatbot wrapper around your fields." A few concrete problems you have to solve:

1. Deciding what counts as "thin." A one-word answer to "what's your name?" is correct. A one-word answer to "what went wrong?" is not. You can't apply a single length heuristic — the bar for "sufficient" depends on the question itself, so the system needs context on what each question is actually trying to learn, not just a character count.

2. Knowing when to stop. A follow-up engine that always asks "can you say more?" is worse than no follow-up at all — it's just friction with extra steps. The harder (and more important) problem is recognizing a good answer immediately and moving on without asking twice.

3. Staying grounded instead of hallucinating next steps. If someone asks the form a question mid-flow — "wait, who sees my answers?" — the honest answer has to come from something the form owner actually wrote, not a plausible-sounding guess. That's why Chatform's follow-up and Q&A layer is grounded in a knowledge base you provide, not freeform generation: the form can say "Only the Northwind team. Nothing is shared outside it." because that's literally in the docs it was given, not because it sounds reasonable.

4. Following up after they leave, not just while they're there. The Sauermann & Roach finding above is why abandonment recovery can't just be a "continue where you left off" link — it has to be timed (a few hours, then a day, then a few days later tends to outperform a single nag) and it has to resume at the exact question they stopped on, not the start.

None of these are exotic AI problems, but they're also not "just add GPT to a textarea" — they're closer to interview design translated into a state machine, which is why most form builders that bolt on "AI" do a single rewrite pass on the question text and call it done.

What this looks like end to end

Concretely, in Chatform a form is built from: a persona (who's asking), a goal (what the conversation needs to get to), and an optional knowledge base (what it's allowed to answer from). From there:

Thin answers get a specific, context-aware follow-up — not a generic "could you elaborate?"
Questions mid-form get answered from your docs, then the conversation picks back up exactly where it left off
People who abandon get an email that returns them to their unfinished question, not the top of the form
Everything still exports to the structured fields you'd expect — short text, email, number, address, scored fields — the conversation is the interface, not the data model

And because most teams don't start from zero, you can point it at an existing Typeform, Google Forms, Tally, Jotform or Youform link and it rebuilds the same questions and logic as a conversation, so switching isn't a rebuild-from-scratch decision.

Where this doesn't matter

Worth being honest about the edges: if your form is three fields and none of them are open-ended ("email," "company size," "yes/no"), a follow-up layer buys you nothing — there's no thin answer to catch. This is specifically a tool for forms where the value is in the free-text answer: qualification, applications, research, onboarding, feedback. If every field on your form is a dropdown, stick with whatever you're using.

Try it

Free tier is actually free — unlimited responses, 200 AI conversations a month, 100 forms, no card required: chatform.in. There's a live demo form on the homepage if you want to see the follow-up behavior before building anything.

Curious what this community has run into on the data-quality side specifically — not completion rate, but the "technically answered, but useless" problem. Anyone handled this a different way (progressive profiling, mandatory minimum character counts, human follow-up calls)? Genuinely want to hear what's worked and what hasn't.