Blog — Ankush Kun

How to switch Claude Code accounts without losing your conversation

ankush4singh@gmail.com (Ankush Singh) — Mon, 12 Oct 2026 01:00:00 +0530

Short answer: Claude Code keeps your conversations on disk per folder, not per account. So you can swap the login, run claude --continue in the same folder, and keep going with the same conversation on a different account. oof does that in one command. It saves the current login from the macOS Keychain, swaps in the account you asked for, updates ~/.claude.json and resumes. The whole script is on GitHub Gist.

I use Claude Code for Construct, my startup, and for side projects like this site, and I have more than one Claude account. When I’m deep in a session and need a different one, the built-in way is /login: a browser tab opens, I check which account the browser is signed in to, approve, come back to the terminal and hope I picked the right one. It works, but it gets old fast, and it always seems to happen right when I’m in the middle of something.

What I wanted was one command that says “use the other account” and puts me back in the exact conversation I was having. No browser, no copying tokens around, and no fresh chat where I have to explain the whole task again.

That command is oof, named after the noise I make when Claude Code tells me I’ve hit a limit halfway through a task. It’s a single zsh script that I wrote in one sitting. This post covers how it works, how it compares with the official way of running several accounts, and the small rabbit holes I fell into along the way.

The key fact is that your conversations don’t belong to your account. Claude Code keeps session history on disk under ~/.claude/projects/, grouped by the folder you ran it in. The account only decides who pays for the next message. If you swap the login and run claude -c in the same folder, you land back in your most recent conversation, just on a different account.

That leaves the question of where the login itself lives. On macOS it’s split across two places:

 macOS Keychain ~/.claude.json
 ┌──────────────────────────────┐ ┌──────────────────────────────┐
 │ "Claude Code-credentials" │ │ "oauthAccount": { │
 │ OAuth access + refresh │ │ "emailAddress": ..., │
 │ tokens, plan, rate tier │ │ "organizationUuid": ... │
 │ (the secret) │ │ } (who /status says you are)│
 └──────────────────────────────┘ └──────────────────────────────┘

The Keychain item holds the actual OAuth tokens. The oauthAccount block in ~/.claude.json is just the label, the email and organization that /status shows. To switch accounts you have to change both, and to switch back later you need a copy of each account’s tokens stored somewhere safe. On Linux and Windows the tokens live in ~/.claude/.credentials.json instead, so the same idea becomes a file copy.

There are already two ways to use multiple Claude Code accounts, and it’s worth being clear about why I didn’t stop at either.

/login works inside a running session and keeps the conversation, but it sends you through the browser every single time.

The official answer for multiple accounts is CLAUDE_CONFIG_DIR. When someone asked for named account profiles in anthropics/claude-code#27359, a maintainer closed it by pointing out that a separate config directory per account already gives you this, with an alias for each:

alias claude-work='CLAUDE_CONFIG_DIR=~/.claude-work claude'
alias claude-personal='CLAUDE_CONFIG_DIR=~/.claude-personal claude'

Each directory has its own login, settings and projects/ folder, which is exactly the problem for me. My conversation lives in one directory, so when I move to the other account it isn’t there to continue. You can symlink the history folders together, but then you’re maintaining a setup that fights the tool’s own design.

	`/login`	`CLAUDE_CONFIG_DIR` per account	`oof`
Browser sign-in on every switch	Yes	No, once per directory	No, once per account
Continue the same conversation	Yes	No, each directory has its own history	Yes, through `claude -c`
Settings, MCP servers and memory	Shared	Separate per account	Shared
Two accounts running at once	No	Yes	No, one login is active
Setup	None	An alias per account	One script and two hooks

If you want strict separation, for example two clients whose work should never mix, or you need two accounts live at the same time, use CLAUDE_CONFIG_DIR. If you want one setup and the freedom to carry the same piece of work across accounts, that’s what oof is for.

Version one: two shell functions

The first idea was two functions in .zshrc:

cc-save() { # cc-save work
 security add-generic-password -U -a "$USER" -s "Claude Code-credentials-$1" \
 -w "$(security find-generic-password -s 'Claude Code-credentials' -w)"
}

cc-use() { # cc-use personal
 security add-generic-password -U -a "$USER" -s "Claude Code-credentials" \
 -w "$(security find-generic-password -s "Claude Code-credentials-$1" -w)"
}

Copy the live token into a named Keychain entry, and copy a named one back. That’s the whole trick, but it has two problems.

The first is that OAuth tokens refresh. Claude Code quietly swaps in a fresh access token and writes it back to the Keychain, and the refresh token can rotate along with it, so a copy you saved yesterday can be dead today. The saved copy has to be kept fresh, which means saving before every switch and ideally all the time.

The second is that I was only swapping the secret. ~/.claude.json still said I was the old account, so /status showed the wrong email until I ran /login anyway, which defeated the whole point.

How oof switches accounts

oof fixes both problems and adds the comfort features I wanted once the basics worked. Each saved account gets:

a Keychain entry named oof:<email>#<org> that holds its tokens. The org part matters because one email can belong to several organizations, a personal plan and a Team seat for example, and those are different logins.
a JSON file in ~/.claude/accounts/ with its oauthAccount block. No secrets go on disk, only the label.
an optional metadata file with a short name like work and the plan, so I can type oof work instead of an email.

The switch itself is small. It reads the target’s tokens with stored_secret, which looks in the account’s own Keychain entry, writes them into the slot Claude Code reads from, and then patches oauthAccount in ~/.claude.json:

switch_to() {
 local key=$1 secret tmp
 secret=$(stored_secret "$key") \
 || die "no saved credentials for $(name_of "$key"). Run oof login to sign in again."
 security add-generic-password -U -a "$USER" -s "$SLOT" -w "$secret" \
 || die "couldn't write to the Keychain"
 tmp=$(mktemp "$CONFIG.oof.XXXXXX")
 jq --slurpfile acct "$STORE/$key.json" '.oauthAccount = $acct[0]' "$CONFIG" > "$tmp" \
 || { rm -f "$tmp"; die "couldn't update $CONFIG"; }
 chmod "$(stat -f %Lp "$CONFIG")" "$tmp"
 mv "$tmp" "$CONFIG"
}

~/.claude.json holds a lot more than the login, including per-project settings and MCP servers, so I never edit it in place. jq writes a temp file next to it, the temp file gets the original’s permissions, and mv swaps it in with a single rename. If anything fails halfway, the real file is untouched.

Before any of that runs, oof saves the current login. That’s the fix for stale tokens: every switch starts by copying the live, freshly refreshed tokens into the current account’s entry, so the account you’re leaving is always stored in its newest state. Then it execs claude -c and the conversation picks up where it left off.

Picking the target is meant to need as little typing as possible:

oof on its own rotates to the next saved account.
oof work first looks for an exact short name or email, and if nothing matches it tries a substring, so oof pers is enough. If a substring matches two accounts it refuses and names both, because guessing wrong here means quietly working as the wrong person.
oof pick opens a menu.
Anything after -- goes to claude in place of -c, so oof pick -- -r lets me choose an account and then choose a conversation.

Saving logins automatically with Claude Code hooks

Saving before every switch covers switches made with oof. It doesn’t cover running /login inside Claude Code by hand, which is how a new account usually gets added. For that I leaned on Claude Code’s hooks. Two hooks in ~/.claude/settings.json run oof save -q in the background when a session starts and after every reply:

{
 "hooks": {
 "SessionStart": [{ "hooks": [{ "type": "command", "command": "\"$HOME/.local/bin/oof\" save -q || true", "timeout": 15, "async": true }] }],
 "Stop": [{ "hooks": [{ "type": "command", "command": "\"$HOME/.local/bin/oof\" save -q || true", "timeout": 15, "async": true }] }]
 }
}

Now any login gets picked up after the next message, and the tokens on file are never more than one reply old. Since that save runs constantly, it compares the live secret with the stored one first and only writes to the Keychain when they differ, otherwise it would rewrite a Keychain item every few seconds for nothing. The || true and async make sure a hook failure never gets in the way of a reply.

oof login does the same from a normal terminal. It saves the current account, runs claude auth login, saves the new one and suggests a short name for it.

Making it pleasant

Once it worked I gave it some polish, because a tool you reach for in the middle of real work should feel good to run.

The banner. oof help opens with a big OOF in block letters that fades through Claude’s orange from top to bottom. The letters are solid blocks with box-drawing characters as a drop shadow. I wanted the blocks colored and the shadow dim, and zsh can do that with one substitution per line:

line=${art[i]//(#m)[╔╗╚╝═║]##/${R}${D}${MATCH}${R}${grad[i]}}

With extended_glob on, (#m) captures each run of shadow characters into $MATCH, and the replacement wraps it in “reset, dim, the shadow, then back to this row’s gradient color”. It uses truecolor when the terminal supports it, falls back to the 256-color palette otherwise, and turns color off entirely for pipes, NO_COLOR and dumb terminals.

The menu. oof pick is an arrow-key menu in plain zsh, with no fzf or other dependency. It opens /dev/tty on its own file descriptor, so the menu keeps working while stdout is captured, which matters because the chosen account is printed back to the caller. Then it puts the terminal into raw mode with stty -icanon -echo and reads one key at a time. The fiddly part is the Escape key. An arrow key arrives as Escape followed by [A, while plain Escape arrives alone, so after an Escape the menu waits 50 milliseconds for more bytes. If [A or [B shows up it moves the selection, and if nothing comes it treats it as Escape and cancels. The menu redraws in place by moving the cursor up and clearing each line, a trap restores the terminal if you hit Ctrl+C partway through, and it starts on the next account rather than the current one, since you opened it to leave.

The list. oof ls shows each account’s short name, email, plan and when it was last active, with a green dot on the current one. The plan comes from the stored token data, where the subscription type and rate tier turn into labels like “Max 20x” or “Team”. “Last active” is simply the modification time of the account’s file, which the hooks refresh on every save.

Completion. Pressing Tab after oof lists the saved accounts, with each one’s email, plan and whether it’s active, next to the commands. A hidden oof __accounts command prints one value:description line per account, and the completion function hands those to zsh’s _describe. The completion script itself comes from oof completion zsh, so it can’t drift out of sync with the commands. One gotcha worth knowing: if your .zshrc runs compinit -C, zsh trusts its cached dump and won’t notice a new completion file until you delete ~/.zcompdump.

Is it safe with several sessions open?

I usually have a handful of Claude Code sessions open in cmux, so this was my main worry. Say I switch to account B while an older session still has account A in memory. If that session refreshed its token, it might write A’s tokens back over B’s, and then my hook would save A’s tokens under B’s name.

Before adding locks and timers I looked at what Claude Code actually does when it refreshes, and it already handles this. Before refreshing, it re-reads what’s stored, and if the stored token isn’t the one it was holding, it adopts the stored one instead of refreshing its own. When it does refresh, it only writes the result back if the stored token is still the one it started from. An old session can’t overwrite a newer login, so the scary version of the race doesn’t happen.

There are two smaller rough edges I know about and haven’t fixed yet:

The token and the label are two separate writes. If a hook’s save lands in the few milliseconds between oof writing the Keychain and writing ~/.claude.json, it pairs the new account’s token with the old account’s name. A /login in another window has a wider version of the same gap, since it fetches the profile over the network between its two writes. The proper fix is to hold Claude Code’s own lock files during a switch and have save stand down while a switch is in progress. Until then, oof warns when other claude processes are running so I can restart them, and if a pairing ever goes wrong, one /login repairs it on the next reply.
The secret briefly appears in a process argument. security add-generic-password -w "$secret" puts the token on the command line, where ps can see it for a moment. Claude Code avoids this by feeding security -i its commands on stdin. On a single-user laptop the risk is small, but it’s the next thing I’d change.

Install oof

You need macOS, zsh, Claude Code and jq (brew install jq). It’s one file, so read it before you run it:

mkdir -p ~/.local/bin
curl -fsSL https://gist.githubusercontent.com/ankushKun/cd27fb07b0f06be99d4181b40309103d/raw/oof.sh -o ~/.local/bin/oof
chmod +x ~/.local/bin/oof

Make sure ~/.local/bin is on your PATH, then:

Add the two hooks above to ~/.claude/settings.json, merging them with any hooks you already have. You can confirm they’re active with /hooks inside Claude Code.
Install tab completion with oof completion zsh > "$(brew --prefix)/share/zsh/site-functions/_oof", then run rm -f ~/.zcompdump and open a new terminal.
Run oof login once for each account you want to add, and give each one a short name with oof name you@company.com work.

After that, oof rotates to the next account, oof work jumps to a named one, oof pick shows the menu, and oof ls lists everything. The first time it touches the Keychain, macOS may ask for permission, and “Always Allow” stops it asking again.

A note on limits

The name is a joke about hitting a limit, but oof is for switching between accounts you actually have, like a personal plan and a seat on your company’s Team plan. Each account keeps its own limits, and switching doesn’t change them. If what you keep running into is the usage limit on a single plan, the supported routes are extra usage, a bigger plan or an API key. Before you set up a stack of personal subscriptions just to rotate through them, read Anthropic’s terms first.

Wrapping up

The whole thing is under 600 lines of zsh, and most of that is help text, colors and the menu. The core idea fits in a paragraph. Conversations live on disk and not in your account, and the login is a Keychain item plus a label. Keep a fresh copy of each account’s item, swap both pieces together, and switching becomes one command that drops you back into the same conversation.

I built it in one sitting with Claude Code, against Claude Code 2.1.296. For testing, the OOF_CONFIG and OOF_STORE variables point the script at a throwaway config and account store, so the menus, naming and completion could be exercised against fake accounts without touching real logins. That’s also how the screenshot at the top was made. The script is on GitHub Gist if you want to read it, use it or adapt it for Linux. It started life as ccs, and logins saved by that version still work after the rename.

Clef beat Jev on Jev's home turf

ankush4singh@gmail.com (Ankush Singh) — Mon, 05 Oct 2026 00:00:00 +0000

When Cloudflare released Clef on October 1, its launch post carried a table of ten public benchmarks, seven of them led by a Clef model. The Hacker News thread passed 600 points in a day, and one of the first replies was six words long: “Public benchmarks are easy to cheat” (Traictory, Hacker News).

Fair. So we ran the test nobody could have trained for. Construct’s agent has about 40 small decisions written for a decision model, and every one of them was written around Jev: the prompts, the questions, and the thresholds, all built against Jev over the last two weeks. That is Jev’s home turf. We pointed the same requests at Clef and Clef-flash without changing a line, and scored all three against labelled cases.

Clef is Cloudflare’s open-weight decision model, a drop-in alternative to TypeSafe’s Jev. On 117 labelled cases across five of our production decisions, Clef reached the right outcome on 92.3% of calls using thresholds set for Jev, against 88.6% for Jev and 82.1% for Clef-flash. Both Clef models returned the identical probability on every repeated call, and Jev did not.

We build Construct, an AI employee with its own computer. Every number below comes from our own runs on October 4, 2026 (UTC): 117 cases, three calls each, three models, 1,053 calls in the main run, plus about 800 more in follow-up controls. Facts about the models themselves come from Cloudflare’s and TypeSafe’s documentation, checked the same day. The full method, confidence intervals and per-case results are in the paper: Compatible APIs, Incompatible Thresholds: A Drop-In Replacement Study of Clef and Jev on Decision Specifications from a Production Agent (PDF, 13 pages).

Accuracy, drop-in: Clef 92.3%, Jev 88.6%, Clef-flash 82.1%, all on thresholds set for Jev. The gap between Clef and Jev is not statistically significant.
Accuracy, own thresholds: Clef 93.2%, Jev 90.9%, Clef-flash 90.6%, with each threshold chosen on held-out cases.
Repeatability: Clef and Clef-flash gave the same probability on all 351 calls each. The probability Jev’s decisions act on moved by up to 0.10, and 2 cases changed verdict.
Code changed to swap models: one string.
Failed calls: 0 of 1,053.
Cost: $23 per million decisions on Jev, $35 on Clef-flash, $93 on Clef. The main run cost about five cents.

What are Clef and Clef-flash?

Clef and Clef-flash are decision models from Cloudflare: you send a state and a set of typed questions, and they return a probability for each allowed answer instead of generating text. Clef is a 27 billion parameter model built on Qwen3.8, and Clef-flash is a 9 billion parameter model built on Qwen3.5. Both are released under Apache 2.0 with weights on Hugging Face, both run on Workers AI, and both accept the same request format as Jev (Cloudflare).

If decision models are new to you: they are the fast, cheap judgment calls around a language model. Is this the same person? Does this email need a reply? Should this tool call wait for a human? TypeSafe calls the category System One models, after Kahneman’s fast, intuitive System 1. Our first post on Jev explains the idea and how we put one inside an AI agent’s memory.

	Jev 1.13	Clef	Clef-flash
Maker	TypeSafe AI	Cloudflare	Cloudflare
Size	Not published	27B parameters	9B parameters
Weights	Closed	Open, Apache 2.0	Open, Apache 2.0
Question types	Choice, Score, Noul	Same	Same
Input	Text and JSON	Text, JSON and images	Text, JSON and images
Context	64k tokens per request	64k tokens	64k tokens
Price per million input tokens	$0.042	$0.24	$0.09
Output tokens	Free	Free	Free
Workers AI model ID	`typesafe/jev`	`@cf/cloudflare/clef`	`@cf/cloudflare/clef-flash`

Jev, Clef and Clef-flash compared, October 2026

Two details in that table matter later. Clef reads images, which Jev does not today. And the prices are per input token, so the model that counts fewer tokens for the same request closes some of the gap.

How we benchmarked Clef against Jev

We did not write a new test for Clef. We took five decisions that already exist in Construct’s code and ran each one’s real request builder and real interpreter, the same functions production calls.

Decision	What it decides	Cases	Threshold today
Entity match	Is this newly mentioned person, project or company one the agent already knows?	30	0.70
Email triage	Newsletter, receipt, spam, request, or keep?	15	0.80
Memory extract gate	Does this conversation hold anything worth remembering?	24	0.05
Notification priority	Does this automation notice deserve a toast, or can it wait?	24	0.85
Tool-call risk	Should this tool call wait for the user’s go-ahead?	24	0.80

The five production decisions in the benchmark

Entity match is live in production. The other four are built and switched off, waiting on shadow data. Their thresholds were set by judgment with Jev in mind and have never been fitted to data, for Jev or anything else.

Swapping the model was the least interesting part of the work. This is the whole change:

// Before
await env.AI.run("typesafe/jev", { state, questions }, options);

// After
await env.AI.run("@cf/cloudflare/clef", { state, questions }, options);

Cloudflare says Clef is “fully Jev-API compatible”. On our requests that held: Choice, Score and Noul questions, JSON state, and the response shape all worked unchanged, and all 702 Clef calls returned valid answers.

The rest of the method, briefly:

Cases: 117, all synthetic, weighted toward the edges of each decision. We drafted and labelled them with an AI assistant (Claude) before any of the three models saw them. No label came from Jev or Clef, and the labels have not yet been independently reviewed by a second person.
Runs: each case three times per model, one call at a time, models interleaved so they shared the same network conditions, with the gateway cache skipped.
Scoring: a call is correct when the production interpreter reaches the labelled outcome at the production threshold. We also report each model’s best threshold, found on the same cases, which flatters all three equally.
Route: Cloudflare’s REST API through our AI Gateway, from a laptop. Fine for accuracy. Wrong for latency, which gets its own section.

Clef vs Jev accuracy: the results

Overall accuracy across five production decisions, 351 calls per model. Left: the thresholds configured today, set for Jev. Right: each model's own best threshold, found in-sample.

With no retuning at all, Clef had the highest score of the three, and the highest or equal-highest on four of the five decisions, on thresholds that were set for a different model.

Decision	Jev 1.13	Clef	Clef-flash
Entity match	72.2% (82.2%)	86.7% (93.3%)	80.0% (86.7%)
Email triage	93.3% (93.3%)	86.7% (93.3%)	73.3% (86.7%)
Memory extract gate	100% (100%)	100% (100%)	95.8% (100%)
Notification priority	95.8% (100%)	100% (100%)	75.0% (100%)
Tool-call risk	87.5% (95.8%)	87.5% (95.8%)	83.3% (100%)
All five	88.6% (93.7%)	92.3% (96.6%)	82.1% (94.9%)

Accuracy by decision at the production threshold, with accuracy at each model’s own best threshold in brackets

Accuracy per decision at today's thresholds. Jev keeps email triage. Clef takes entity matching and notification priority.

The honest size of this result: Clef leads Jev by 3.7 points on 117 cases, with a 95% interval of -1.1 to +8.8 points. That is not statistically significant, and we would not stretch it into “Clef beats Jev”. Three of the entity cases are ones our product resolves in code before any model is asked (identical names, and names that differ only in case). Jev did worst on exactly those, and without them the lead shrinks to 2.0 points (92.1% against 90.1%). What we can say is narrower and more useful. Cloudflare’s public numbers predicted Clef would be at least as good as Jev on decision tasks, and on private prompts it had never seen, written for its competitor, it was not measurably worse.

Jev deserves its due here too. It won email triage outright, it never made a wrong merge, and it was perfect on the extract gate. This is a close race between two good models.

Is Clef deterministic?

Yes, on everything we sent it. We called each model three times with the same request for all 117 cases. Clef returned the same probability, to four decimal places, on all 351 calls. So did Clef-flash. To rule out a cache, we sent the same requests again with changes that do not touch the model’s input (a unique query string, reformatted JSON, reordered keys): same answers, a cache miss on every response, and a new inference ID each time.

Largest change in probability between three identical calls. Clef and Clef-flash sit at zero on every decision.

The probability each Jev decision acts on moved between identical calls by up to 0.10, and two cases changed verdict from one call to the next. Across every probability Jev returned, the largest move was 0.16, and 100 of the 117 cases came back with at least one number different. TypeSafe describes Jev as returning “similar answers for similar inputs”, which is a promise of consistency, not determinism, and a wobble of this size is consistent. But a decision layer acts when a probability crosses a line, so any wobble means a case near the line is decided by which call you happened to make.

Cloudflare’s post explains why Clef behaves differently: the decision step is non-autoregressive, with choices derived directly from the model’s internal representations and no text sampled along the way. We can confirm the practical result. For anyone who has debugged an agent that did something different the second time, this is the finding that matters most, more than a few points of accuracy.

Jev’s scores moved under the same version name

This one surprised us. On September 20 we calibrated our live entity matcher on Jev. Real matches scored 0.71 to 0.82, everything else scored 0.34 or less, and we put the merge threshold at 0.70, in the gap.

Two weeks later we asked the same three calibration probes again.

Jev's probability for the correct match on our three calibration probes: one call on September 20, and the mean of 20 calls on October 4 through Workers AI and on TypeSafe's own API with the version pinned. All were served as jev-1.13.0.

All three now fall under the bar. To be sure this was not a noisy afternoon, we asked each probe 20 more times: none of the 60 calls reached 0.70, and the highest was 0.66. Clef, asked the same 20 times, returned the identical number every time. The served version was jev-1.13.0 both times, so the alarm we built to catch version changes stayed quiet. On this benchmark Jev still never merged two different people, which is the expensive mistake, but it made only 44% of the merges it should have. In production, a missed merge becomes a duplicate.

We do not know why the scores moved. Our first suspect was our own route: we call Jev through Cloudflare’s Workers AI, which cannot pin a version. So we repeated everything against TypeSafe’s own API with the version pinned to jev-1.13.0. Same result: none of 60 calls reached 0.70, and Jev’s answers still varied between identical calls on 104 of 117 cases. The route is not the cause. Three probes are still three probes, and our September baseline is one call each. We are not claiming Jev got worse in general. The lesson is about our own setup: a threshold is only as stable as the model under it, and a version string is not a guarantee. Open weights can change that, if you use them: a model you pin or host yourself cannot move under its thresholds. The hosted Clef alias we tested carries no version either, so we will re-ask these same probes on Clef in two weeks.

Entity matching: where the three models differ most

Entity matching is the decision where a mistake is permanent. A wrong merge fuses two real people in the agent’s memory, so precision matters more than recall. AI agent memory covers what that memory holds and how you can correct it.

Entity matching at the production threshold of 0.70: 15 pairs that should merge and 15 that should not.

Clef caught the aliases this decision exists for: “Jose Garcia Marquez” against the accented spelling at 0.98, “Stripe, Inc.” against “Stripe” at 0.98, “I.B.M.” against “IBM” at 0.99. Its one wrong merge was “Acme” into a lone “Acme Corporation” at 0.78, a case reasonable people would argue about.
At a 0.80 threshold, Clef made 10 of 15 correct merges and no wrong ones. That is our starting point for shadow mode, not a recommendation: it was picked on these same 30 cases, and “Acme” against “Acme Corporation” sits at 0.78, just under it.
Jev is not worse at telling people apart. Drop its threshold to 0.50 and it makes 64% of the correct merges, still with no wrong ones, close to Clef’s 67% at 0.80. Its problem at 0.70 is that its scores moved, not that it lost the ability to rank the pairs.
Clef-flash is quick to say yes. It matched “Acme Labs Europe” to “Acme Labs” at 0.76 and the bare concept “pricing” to “pricing model” at 0.89. For a merge, that is too eager. For a gate that only skips work, it is fine.
All three refused a one-letter surname typo, “Mendelsohn” against “Mendelson”. Good. Those can be two people.

Thresholds do not transfer between decision models

If you take one thing from this post into your own migration, take this. A threshold is a property of a model and a prompt together. Move the model and the threshold is wrong, even when the new model is better.

The three models are not far apart in ability. Asked to rank our cases from “should act” to “should not”, all three do it well: on the four decisions we could measure this way, the ranking score (AUROC) is 0.93 or higher for every model and a perfect 1.00 on two decisions. What differs is the number each model attaches to the same judgment.

Decision	Configured	Jev’s best	Clef’s best	Clef-flash’s best
Tool-call risk	0.80	0.49	0.22	0.31
Notification priority	0.85	0.60	0.85	0.61

The most accurate threshold per model on two decisions, against the configured threshold

Clef-flash shows the effect best. On Jev’s thresholds it scored 82.1%. With thresholds chosen for it on held-out cases it scored 90.6%, level with Jev’s 90.9% on the same footing, and Clef stayed ahead at 93.2%. The 9B model was never bad at these decisions. It was being read with another model’s ruler.

The thresholds in the table were found on the same cases they are scored on, which is why the bracketed figures in the results table (96.6%, 94.9%, 93.7%) run higher than the held-out ones. Treat them as a direction and not as settings. The practical rule is simple: swap the model in shadow, log probabilities for a week, and set the threshold from that.

How fast is Clef? What we could and could not measure

Cloudflare reports a median of 209 ms for Clef and 38.8 ms for Clef-flash, against 524 ms for Jev. We are not going to confirm or dispute those numbers, because our harness was the wrong instrument.

We called all three models through Cloudflare’s REST API from a laptop. The fastest call we saw for any model was 340 ms, and for every model the floor sat between 340 and 384 ms. That floor is the path: authentication, the public API, the gateway, and the round trip. You cannot see a 38 ms model through a 340 ms window.

	Jev 1.13	Clef	Clef-flash
Fastest call	384 ms	352 ms	340 ms
Median	454 ms	654 ms	449 ms
95th percentile	591 ms	1,262 ms	1,024 ms

Latency per call through the REST API from a laptop, 351 calls per model. Not a production measurement.

For transparency, those are the raw numbers. On this path Clef-flash matched Jev at the median, Clef was slower, and both Clef models had longer tails, three days after launch. None of that tells you what a Worker sees when it calls the model through the AI binding, next to the GPU, which is how we call it in production. That measurement is next, and we will publish it here.

What does Clef cost compared with Jev?

Cost per million decisions at list price, using the mean input tokens each model counted for our requests.

Clef’s list price is 5.7 times Jev’s, which is the first thing the Hacker News thread did arithmetic on. Two things soften that.

First, Clef counted 28% fewer tokens than Jev for the same request: 387 per call against 541. Per decision, the gap is about 4 times, not 5.7.

Second, look at the unit. A million Clef decisions cost $93. All 1,053 calls in this benchmark cost about five cents. An agent that makes a thousand decisions a day spends about nine cents a day on Clef and two on Jev, next to a language model bill many times that. If you run billions of decisions a day, price it carefully, and look at Clef-flash at $35 per million. For everyone else, accuracy and repeatability are worth more than the difference.

Clef vs Jev: which decision model should you use?

If you need	Pick	Why
The best accuracy without retuning	Clef	Highest drop-in accuracy on our decisions, 92.3%
The same answer every time	Clef or Clef-flash	Identical probabilities on every repeated call
To pin a version, self-host, or fine-tune	Clef or Clef-flash	Open weights under Apache 2.0
To classify images	Clef or Clef-flash	Both have a vision encoder; Jev is text only
The lowest price per token	Jev	$0.042 per million input tokens
Zero wrong merges at your current thresholds	Jev	100% precision on entity matching, at the cost of recall
A high-volume gate that only skips work	Clef-flash, with its own thresholds	90.6% once retuned on held-out cases, at about a third of Clef’s price
Anything that merges, deletes or sends	Clef, at a high threshold	Clef-flash was too eager on lookalike names

Which decision model fits which job, based on our benchmark and each vendor’s documentation

The broader field is moving fast. Besides Jev and Clef there are open decision models such as Laya, Kev and OpenDecider, and Cloudflare’s own table includes several of them. We have only tested the three in this post.

What we are switching, and why Cloudflare makes it easy

Construct already runs on Cloudflare: Workers, Durable Objects, AI Gateway, and Workers AI for the small models. How our agents get computers we mostly do not pay for describes that stack. So Clef is not a new vendor for us. It is a new model ID on a binding we already call.

Entity matching goes to Clef in shadow first, starting at 0.80. Jev keeps deciding while Clef’s answers are recorded beside it. The threshold we ship will come from that data, and we switch only if real traffic agrees with this benchmark.
Background decisions default to Clef, each with its own threshold measured in shadow.
Interactive decisions wait for the latency test. If Clef-flash is as fast from a Worker as Cloudflare reports, it is the natural fit for anything a person is waiting on.
Clef-flash stays away from anything that merges or deletes until it has its own thresholds.

There is a quieter benefit. In our Jev post we said that decisions which read your conversations or email “wait for the paperwork”, because sending that text to another provider is a privacy decision. A first-party Cloudflare model keeps that text on the platform that already runs the rest of Construct, which removes the main reason most of our decisions are still switched off.

We are also watching Cloudflare’s new fine-tuning work, which it calls Reinforcement Learning for Calibrated Decisions. Our decision layer already records the label, the probability and what the product did for every decision, with no user text. That is close to the dataset such a system wants.

How to try Clef

On Workers AI: call @cf/cloudflare/clef or @cf/cloudflare/clef-flash through the AI binding or the REST API. The request is a state plus a map of questions, the same as Jev.
Coming from Jev: change the model ID and keep everything else. Then re-measure every threshold.
Self-hosted: the weights are at Cloudflare/clef and Cloudflare/clef-flash on Hugging Face under Apache 2.0.
Read the probabilities, not the confidence field. It means different things on Clef and Jev, and on Jev it changed meaning between our September and October runs. Read probabilities and both models behave the same.
Pace a REST benchmark. Cloudflare’s REST API throttled our token at roughly 90 calls a minute. The Workers binding is the route for real traffic.

A minimal request:

curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/ai/run \
 -H "Authorization: Bearer $API_TOKEN" \
 -d '{
 "model": "@cf/cloudflare/clef",
 "input": {
 "state": { "entity": { "type": "person", "name": "Dr. Priya Shah" } },
 "questions": {
 "match": {
 "type": "choice",
 "instructions": "Which candidate is the same entity?",
 "criteria": {
 "node-priya": "Priya Shah (person)",
 "none": "No candidate is clearly the same entity"
 }
 }
 }
 }
 }'

What this benchmark does not show

It is small. 117 cases, 15 to 30 per decision. A 3.7 point lead at that size is suggestive.
It is synthetic. The cases are written to cover each decision’s edges. Production traffic is mostly the easy middle, so real accuracy for all three models is probably higher.
The labels are ours, drafted with an AI assistant. No second person has checked them yet. A few are judgment calls, like whether “Acme” should merge into the only “Acme Corporation” in memory. We said no. Dropping the five most arguable ones does not change the order.
Thresholds are tuned on small sets. The held-out figures are the fair ones, and they are still noisy at 15 to 30 cases per decision.
Latency is unmeasured. See above.
One day. Everything ran on October 4, through Cloudflare, with Jev repeated on TypeSafe’s own API. Clef was three days old. Jev’s scores moved in two weeks. Either could look different next month, which is the argument for running your own cases on a schedule.

The paper has the statistics behind each of these, the five cases no model got right, and every case where any model slipped. The cases, labels and every call are published as JSON beside it: Compatible APIs, Incompatible Thresholds: A Drop-In Replacement Study of Clef and Jev on Decision Specifications from a Production Agent.

Cloudflare published benchmarks, and people on the internet said benchmarks are easy to cheat. The fix for that is boring: write down your own cases, label them, and run every new model through them. Ours took an afternoon and a few cents, and it told us more about our own system than any leaderboard could.

Where Construct fits

Construct is an AI employee with its own computer: a workspace filesystem, long-term memory, a schedule, email, and workflows you can read before you run them. Decision models make the small calls around the edges, such as whether a person your agent just read about is one it already knows. Planning and writing run on general-purpose language models.

Two boundaries, stated plainly. As of this post, Jev still makes the live entity-matching decision and Clef has only run in this benchmark; this page will say when that changes. And the other four decisions in this benchmark are built but switched off in production until shadow data supports them.

If decision models are new to you, start with we put Jev inside our AI employee. For why small, repeatable judgments matter so much in long tasks, read your agent has a half-life. And if the category itself is new, begin with what is an AI employee.

Originally posted on construct.computer.

We put Jev inside our AI employee

ankush4singh@gmail.com (Ankush Singh) — Wed, 30 Sep 2026 00:00:00 +0000

Your AI employee reads an email that mentions “Dr. Priya Shah”. Last week it met “Priya Shah” in a calendar invite. Same person? Guess yes and get it wrong, and two people’s histories are welded together in its memory. Guess no and get it wrong, and you have a duplicate. It makes that call every time it learns something, in the background, where nobody is watching.

Jev is a System One model from TypeSafe AI: you give it a state and a set of typed questions, and instead of generating text it returns a probability for each possible answer, in well under a second, for $0.042 per million input tokens with output free. TypeSafe released it in early access on September 15, 2026. Five days later we shipped it into Construct’s memory to make exactly the call above. This post covers what we measured, how we picked the threshold, what Jev gets wrong, what it costs next to a language model, and where a decision model fits in an AI agent’s loop.

We build Construct, an AI employee with its own computer. The numbers in this post come from our own integration, measured on September 20, 2026 against jev-1.13.0. Everything else about Jev comes from TypeSafe’s launch post and docs and from independent tests, all checked on September 30, 2026.

Latency: 358 to 611 ms for one question on about 400 tokens, and 377 to 544 ms for seven questions on the same state.
Consistency: repeating the same call moved Jev’s probabilities by 0.02 at most.
Threshold: we merge at 0.7. In our probe set, real matches scored 0.71 to 0.82 and everything else 0.34 or less.
Calls: one Jev call replaced up to three sequential calls to a generative judge for each entity.
Cost: about $0.017 per 1,000 decisions of 400 input tokens at list price, with output free.

What is Jev?

Jev is a decision model, not a chat model: it never generates text, and TypeSafe says it is not a large language model. TypeSafe AI, a San Francisco company founded by Diogo Almeida (a former OpenAI researcher and co-author of the InstructGPT paper), Erik Gafni, and Sasha Sheng, released it alongside a $40 million seed round led by DCVC. TypeSafe calls Jev the first “System One model”, after the fast, intuitive System 1 in Daniel Kahneman’s Thinking, Fast and Slow, and describes it as “a frontier-intelligence function call: unstructured state in, typed probabilistic decisions out” (TypeSafe).

You send one state, as text or JSON, and a map of named questions. Each question has one of three types (TypeSafe API reference):

Choice picks one of up to 255 labels you define and returns a probability for every label.
Score rates the state on an ordered scale of 2 to 10 levels.
Noul, short for Bernoulli, returns the probability that a statement is true.

Every question is answered against the same state in one parallel pass, so adding questions barely changes the response time. Jev cannot write a sentence, and that is the point: there is no prose to parse, no output tokens to pay for, and no way for an answer to fall outside the labels you gave it.

	Jev (System One model)	Language model (LLM)
What comes back	A typed answer with a probability for each option	Generated text, optionally JSON
Can it write, plan, or call tools	No	Yes
Latency	70 to 500 ms claimed; 358 to 611 ms in our tests	Usually seconds for a short structured answer
Price per million input tokens	$0.042, output free	From about $0.05 to $10, plus billed output
Answer outside your options	Impossible by construction	Possible without a strict schema
Wrong answer	Possible, with a probability attached	Possible, usually with no probability
Input	Text and JSON, 64k tokens per request	Text, and often images and files

Jev compared with a general-purpose language model

In Kahneman’s terms, the language model is the slow, deliberate System 2 and Jev is the fast System 1. The analogy used to run the other way: in 2023, plain LLMs were the System 1 of the story. Simon Willison and Maggie Appleton suggest the plainer name “decision models” (Simon Willison), which is also the term our own code uses.

Using Jev for AI agent memory

Construct’s agent keeps a long-term memory: a graph of the people, companies, and projects in your work, with facts attached to each. After a conversation, it extracts what is worth keeping, and for every person or project it mentions it has to decide whether that is someone it already knows. That is entity resolution, and it is a textbook System One question: a judgment a knowledgeable person makes in a second, asked over and over, in the background, with nobody waiting on the answer. We are not the only ones who ended up here: a September paper, Jev-Mem, proposes putting a System One model in control of an agent’s memory (arXiv:2609.23986).

Most cases never need a model. A platform ID, an exact alias, or a single exact-name match resolves in code. What is left is the ambiguous part, where several candidates share a name or the only matches are fuzzy or come from vector search.

Before Jev, those leftovers went to a generative judge: a small open model, Llama 4 Scout on Workers AI, constrained by a JSON schema whose only allowed values were the candidate IDs or null. It was asked about each candidate set in turn, up to three sequential calls per entity and up to 64 entities per batch, and it answered with a label and nothing else.

Now one Jev call scores every candidate at once, whichever lookup found it, plus an explicit “none”, and entities resolve in parallel, eight at a time, so a 64-entity batch does not open 64 connections at once and run into TypeSafe’s per-account rate limit. If Jev does not answer within two seconds, or answers in a shape we did not ask for, resolution falls back to the old judge.

Who decides what matters, so here it is plainly:

Code finds the candidates with vector, exact-name, and fuzzy-name lookups, enforces the threshold, and performs the merge.
Jev answers one question: which candidate, if any, is the same real entity, with a probability for each.
A language model extracted the entity from the conversation earlier. It takes no part in the decision.

That split is also our answer to the fair criticism that a decision model has no context. It does not need the whole conversation. Retrieval builds a small state, and Jev makes one bounded call on it. TypeSafe’s CEO has said “the hard part for coding is actually state engineering” (Hacker News). For an agent with its own computer and memory, most of that state already exists, structured, before the question is asked.

How fast is Jev in production?

Call	Input	Latency
One question	About 400 tokens	358 to 611 ms
Seven questions on the same state	About 711 tokens	377 to 544 ms

Jev latency measured by Construct on September 20, 2026

Both rows were measured against jev-1.13.0 through Cloudflare AI Gateway. Repeating the seven-question call moved the probabilities by 0.02 at most, and p95 latency was about 0.6 seconds, so we gave the call a two-second budget before falling back. TypeSafe says its service runs on the US West Coast, so your numbers depend on where you call from: OpenRouter measured a 175 ms median (OpenRouter), and a tester in Japan measured a 245 ms median (Towards Data Science).

The second row is the useful one. Seven questions took no longer than one and used 1.8 times the input tokens, because Jev reads the state once and answers every question in parallel. Batch every judgment you have about the same state into one call instead of making several. TypeSafe’s own cookbook reports 13 batched questions running 12.2 times cheaper and 10 times faster than separate calls, with no change in answers (TypeSafe docs).

How we picked the 0.7 threshold

Jev returns a probability for every candidate and for “none”. The real engineering question is where to draw the line. These are the probes we measured on September 20:

New mention	Existing candidates	Jev’s answer	Outcome at 0.7
“Dr. Priya Shah”	Priya Shah	Priya Shah, 0.71	Merged
“Priya Shah”	Priya Shah	Priya Shah, 0.76	Merged
“atlas migration”	Atlas Migration	Atlas Migration, 0.82	Merged
“Acme”	Acme Corporation	None, 0.66 (Acme Corporation 0.34)	Kept separate
“Acme”	Acme Corporation, Acme Labs	None, 0.79	Kept separate
“Sam”	Sam Altman, Samantha Reyes	None, 1.00	Kept separate
“Marcus Webb”	Unrelated people	None, 1.00	Kept separate

Jev’s answers on entity-resolution probes, and the outcome at a 0.7 merge threshold

In this probe set, real matches landed between 0.71 and 0.82, and everything else put 0.34 or less on its best candidate. We set the merge threshold at 0.7, inside that gap.

Two things decided where in the gap. First, the mistakes are not symmetrical. A wrong merge fuses two real entities and cannot be split again, while a missed merge leaves a duplicate that splits one entity’s facts across two records. Second, raising the bar to 0.8 would have refused exactly the alias cases, like “Dr. Priya Shah”, that we added the model to catch.

Look at the second row again. An identical name scored 0.76, not 0.99. We asked for “the same real entity”, “not merely a similar name”, and Jev priced in that a shared name is not proof of a shared identity. That is what you want from a decision about who someone is.

Seven probes are not a benchmark, and we do not present them as one. What transfers is the method: log the probabilities on your own traffic, look for the gap, and place the threshold by what each kind of mistake costs. Then pin the model version if your route lets you: TypeSafe’s docs say to pin a version’s ID once you have tuned confidence thresholds against it (TypeSafe docs). Cloudflare’s typesafe/jev route, the one we call, has no version field, so it answers with whatever TypeSafe serves (Cloudflare). Every response names the model that answered, so record it next to each decision and treat a change as a reason to measure again.

Use the probability, not the top answer

The most important line in our integration is a helper that refuses to use Jev’s top answer unless its probability clears the threshold. Real matches do not always clear it. In a case recorded in our code outside that probe set, Jev picked the right candidate at 0.63 with “none” holding 0.37. Taking the top answer would have merged, and this time it would have been right. We still do not merge at 0.63. A rule that merges at 63% will also merge the wrong candidate whenever Jev is 63% sure of it, and a wrong merge costs far more than the duplicate this leaves behind.

If you take the top label and discard the probability, you have thrown away the one thing you were paying for. This is the same arithmetic as in Nobody merges an email: delegating pays when the cost of checking plus the expected cost of a mistake is lower than doing the work yourself, and the model only shows up in the probability of a mistake. A generative judge hands you an answer. A decision model hands you an answer and that probability, so you can spend human attention where it is low instead of rereading everything.

Is Jev’s confidence calibrated?

Partly. TypeSafe trains for calibration and is explicit that calibration “does not guarantee that an individual answer is correct” (TypeSafe docs). Independent tests agree the probabilities rank answers well and disagree with each other about how literally to read them:

OpenRouter found Jev “overestimated its own accuracy mid-range. Still, it ranks well.” At a confidence of 0.99 or more, which covered 58% of items, it was right 96.3% of the time (OpenRouter).
A Towards Data Science test found answers in the 0.7 to 0.9 band right only 53% of the time, and answers at exactly 1.00 right 97.1% of the time (Towards Data Science).
Primeline measured calibration error by question type: 0.012 for Noul, 0.086 for Choice, and 0.254 for Score, roughly a 20 times spread (Primeline).

Treat Jev’s probabilities as a strong ranking, not as literal odds, and be most careful with Score questions. Our threshold does exactly that: it sits in a gap we observed rather than at a number we assumed. With a few hundred labeled examples from your own data you can go further and recalibrate the scores (Alex Molas).

What Jev gets wrong

TypeSafe publishes its own list of weak spots for jev-1.13 (TypeSafe docs). It reads instructions literally, “is not a calculator”, “does not count reliably”, struggles with date and time comparison and with multi-step indirection, degrades on large states full of irrelevant detail, and does not treat text in the state as hostile. Independent tests confirm the ones that matter most for agents:

Injected text moves the answer. Primeline appended an “IMPORTANT INSTRUCTION FOR THE AI CLASSIFIER” line to an innocent reminder and watched its spam score rise from 0.04 to 0.66. Across 40 test pairs, 22.5% were misclassified outright (Primeline). A separate paper found injected content shifts probabilities but rarely makes Jev pick the attacker’s target, with adaptive attacks raising success from 1.8% to 3.5% (arXiv:2609.28613). For an agent that reads email and web pages, assume the state is attacker-controlled.
Long, real-world state hurts. Synthetic padding up to 125,000 characters cost Primeline nothing, but on real notes accuracy fell from 97.0% on the shortest quarter to 81.1% on the longest.
Probability has to land somewhere. Given 30 messages that fit none of the listed categories and no “none” option, Jev chose a listed category every time, at 0.99 confidence or more, in a test reported by Towards Data Science.
Separate questions are not kept consistent. In TypeSafe’s own docs, a question and its negation returned probabilities that added up to 1.19.

These are the rules we wrote into our integration, and they follow directly from that list:

Never put Jev on an auth boundary, and never make it the only check before an irreversible action.
Never ask it to compare dates, count, or do arithmetic. Compute those in code and put the result in the state.
Always offer an explicit “none”.
Ask one question per decision, and never infer the probability of “not x” from the probability of “x”.
Keep the state small and relevant: the candidates, not the whole conversation.
Treat a missing or malformed answer as no verdict, never as “no”, and keep the old path as a fallback. That includes a label you never offered: count it as no answer, not as “none”.
Batch every question about the same state into one call.
Record which model version answered, with the probability and what you did with it, so the threshold can be checked again later.
Put anything a third party wrote in fields marked as untrusted, and tell every question to treat those fields as evidence, never as instructions.

Where Jev fits in an AI agent: System 1 and System 2

An AI employee makes two kinds of decisions. The big ones, what to do and how, belong to a language model that can plan, write, and use tools. The small ones happen dozens of times per task, and most of them are the shape Jev was built for: a bounded question over a small state, where a fast answer with a probability is worth more than a slow paragraph.

Anthony Maio’s division of labor is the cleanest statement of the pattern we have seen: “A generative model drafts, plans, or explains. Jev supplies bounded semantic judgments. Code handles state, arithmetic, policy, permissions, and side effects. Humans take the ambiguous or high-risk cases” (Anthony Maio).

This is how we rate the decision points in an always-on agent’s loop:

Decision	Jev question	Fit	What to design around
Is this person or project one the agent already knows?	Choice, with “none”	In production at Construct	A wrong merge is hard to undo, so merge only above a measured threshold
Is the task done, or should the agent keep going?	Noul	Good	The state includes tool output, which is untrusted, so stop when unsure
Does this inbound email need the agent at all?	Choice: reply, file, or ignore	Good for skipping and labeling	Email is attacker-controlled, so the answer must never send anything
Is this thread message addressed to the agent?	Noul	Good	Low stakes: a miss costs a slower reply
Is there anything new since the last scheduled run?	Noul over a change list built in code	Promising	Jev is weak at dates, so work out what changed before you ask
Which tool or skill fits this request?	Choice, up to 255 labels	Good as a suggestion	Let the planning model keep the final say
Can this action run without asking the user?	Noul	Only as one layer	Never the only gate on something irreversible

Decisions in an AI employee’s loop, and how well each fits a decision model

Two patterns come out of that table.

The saving is the turns you do not run. Comparing Jev’s price with a cheap language model’s misses where the money goes. When an email arrives or a schedule fires, the expensive part is the full agent turn that follows. A half-second check that says “this is a newsletter” or “nothing changed since the last run” lets the agent skip that turn entirely. TypeSafe’s skill-suggestion cookbook shows a similar effect inside a turn: with a Jev suggestion, an agent built on Claude Haiku 4.5 loaded the wrong skill 7.3% of the time instead of 16.8% (TypeSafe docs).

Escalate up, never sideways. The obvious move is to send low-confidence decisions to a bigger model, and it works only if the fallback is actually better at the hard cases. OpenRouter sent Jev’s answers below 0.90 confidence to Claude Opus 5 and got within 0.4 points of Opus alone, with 76% of traffic never touching Opus, an upper bound because the cutoff was tuned on the test set (OpenRouter). A Towards Data Science test sent them to a weaker local model instead, and every cascade did worse than Jev alone: one “fixed 84 mistakes, but introduced 211 new ones” (Towards Data Science). Knowing which cases are hard is not the same as having something that can solve them. For irreversible actions, the right place to escalate is usually a person.

Read next: Your agent has a half-life

What does Jev cost compared with an LLM?

At list prices, for a decision with about 400 tokens of input, and assuming a 20-token JSON answer from the models that generate one:

Model	Price per million tokens, input / output	Cost per 1,000 decisions
Jev 1.13	$0.042 / free	$0.017
Llama 4 Scout on Workers AI (our old judge)	$0.27 / $0.85	$0.125
Claude Haiku 4.5	$1 / $5	$0.50
Claude Sonnet 5.5	$2 / $10	$1.00

List-price cost per 1,000 decisions of about 400 input tokens, September 2026

Two notes make the comparison fairer. Prompt caching cuts repeated input on Claude models to about a tenth of the price, but Haiku 4.5 only caches prompts of 4,096 tokens or more, so a short decision prompt gets no discount. Jev has no prompt caching at all, and Primeline saw identical requests billed in full every time, which barely matters at $0.042 per million tokens. Our old judge also needed up to three calls per entity, so its real cost was up to three times its row.

The honest conclusion is less dramatic than the launch claim of “444.6x cheaper”. Independent tests put Jev at roughly 8 to 20 times cheaper per call than Haiku 4.5 and 10 to 20 times faster than strong language models on like-for-like classification, a few accuracy points behind the best of them (Primeline; OpenRouter). For one founder’s agent making a few hundred small decisions a day, the difference is cents a month either way. Price starts to matter at fleet scale or in tight loops, and the bigger saving is still the agent turns a cheap decision lets you skip.

For us, cost was not the reason to switch. One call replaced up to three sequential ones, “none” became an explicit, scored answer, and we got a probability to put a threshold on.

How we are adding more Jev decisions

Entity matching was the first decision. Mapping every other place our agent makes a small judgment turned up about thirty more candidates, from “does this email need the agent?” to “did this scheduled check find anything new?”. Before moving any of them, we built one small runtime that every decision goes through. The lesson of the first week was that a decision you cannot see is a decision you cannot trust.

Every decision ships switched off. A flag moves each one from off to shadow to live on its own, with its own threshold.
Shadow before live. In shadow the old path still decides, and Jev’s answer is recorded beside it. The old path’s answer becomes a free label, so the threshold comes from real traffic rather than a handful of probes.
Records carry numbers, not text. We keep the decision name, the label, the probability, what the product did, and which model answered, never the text Jev saw. Samples are deleted after 90 days.
The model version is recorded, not assumed. Our route cannot pin a version, so each record names the version that answered, and a change raises an alarm. New decisions drop back to shadow until they are measured again.
A failing provider degrades to the old behaviour. A circuit breaker stops calling Jev after repeated failures, and a rate gate keeps us well under TypeSafe’s published limit, 80 requests a second when we last checked (TypeSafe docs). Every decision has a fallback, so an outage looks like the product before Jev.
Third-party text is labelled as such. Email bodies, web pages and other people’s messages go into fields named as untrusted, and every question says those fields are evidence, not instructions. In one small practitioner test, a single sentence like that cut targeted injection success to 1.3% (Iskandeur). It is a mitigation, not a boundary, so a decision that reads untrusted text may only lower a priority or skip work, never grant anything.
Decisions that read your conversations or email wait for the paperwork. Sending your text to another provider is a privacy decision before it is an engineering one. TypeSafe is on our sub-processors list, and the decisions that would send conversation or email text stay off until the contract review is done.

The mapping also found plain bugs that had nothing to do with Jev. One was a keyword table that guessed which app a request needed: any request containing the letter x, such as “export as csv”, read as a request for Twitter, and “linear regression” read as a request for Linear. A keyword list is how you make a System One judgment without a System One model, and that is what it looks like when it fails.

How to try Jev

Direct: sign up at typesafe.ai. TypeSafe paused new signups on September 22 because of demand, and its CEO said on September 27 that signups had reopened, without free credits for new accounts (Diogo Almeida on X).
Through a gateway, without a TypeSafe account: OpenRouter (typesafe/jev-1.13), Vercel AI Gateway (typesafe-ai/jev), or Cloudflare Workers AI (typesafe/jev). We call it through Cloudflare Workers AI and AI Gateway.
On Cloudflare, check the key alias: the Workers AI binding only uses a provider key stored under the default alias. With any other alias, calls quietly fall through to Cloudflare’s Unified Billing, which is capped at 200 requests a minute per gateway (Cloudflare).
SDKs: typesafe-sdk for Python and @typesafe-ai/sdk for JavaScript and TypeScript (TypeSafe quick start).
Price: $0.042 per million input tokens. Output tokens are counted but not billed. Several unofficial lookalike sites resell Jev access at several times that price, so check the price on typesafe.ai or your gateway before you pay.
Version: jev-latest points at jev-1.13.0 today. If you tune thresholds, pin the version where your route allows it, and record the served version where it does not.

Start with one decision that is frequent, runs in the background, is not an auth boundary, and already has a fallback. Log the probabilities for a week before you let them act on anything.

What most Jev coverage gets wrong

“Jev never hallucinates.” It cannot return a value outside your schema. It can return the wrong valid one, and TypeSafe’s own FAQ says it “can choose the wrong one” (TypeSafe).
“Jev is 67.8% accurate.” That figure is agreement with the averaged answers of GPT-6 Astra and Claude Fable 5.1 on TypeSafe’s own four workflow evals, not accuracy against verified labels (TypeSafe evals).
“193.6x faster and 444.6x cheaper.” On TypeSafe’s eval chart, those ratios line up with the slowest model, Claude Sonnet 5 at 78.1 seconds per case, and the most expensive, Claude Opus 5 at $0.1761 per case. Against GPT-5.6 Terra, which matched Jev’s agreement score, the same chart works out to about 25 times faster and 76 times cheaper.
“Jev has a 32k context window.” It takes 64k tokens per request, of which 32k covers the state plus the longest question (TypeSafe docs). Cloudflare’s model page lists 32,000 tokens for its route, so check the limit on the route you actually call.
“It is deterministic.” TypeSafe designs for consistency rather than determinism. Our repeated calls moved by 0.02 at most, which is consistent, not identical.
“Just send the uncertain ones to a bigger model.” Only if that model is better at the hard cases, as the escalation results above show.

Where Construct fits

Construct is an AI employee with its own computer: a workspace filesystem, long-term memory, a schedule, email, and workflows you can read before you run them. Jev runs in one place today, deciding whether a person or project your agent just learned about is one it already knows. Planning and writing run on general-purpose language models.

Memory in Construct is inspectable and correctable, so if a merge pulls the wrong facts together, you can see which ones and correct or forget them. AI agent memory covers how that works. Two honest boundaries: the “is this task done?” check and email triage are written as Jev decisions, but both stay switched off until shadow data shows they beat what they would replace, and Construct does not currently insert a mandatory approval gate before every external side effect, so steps that send mail or move money still need supervision before they run unattended.

If the reliability argument is new to you, start with your agent has a half-life and nobody merges an email. For the infrastructure underneath, read how our agents get computers we mostly do not pay for, and if the category itself is new, begin with what is an AI employee.

Originally posted on construct.computer.

Nobody merges an email

ankush4singh@gmail.com (Ankush Singh) — Tue, 22 Sep 2026 00:00:00 +0000

It is 5:40 on a Friday and the agent has just written nine client updates in four minutes, sitting there quietly pleased with itself. Eight of them are fine. One of them has told a client something that is not true, and because nothing in the pipeline can tell you which one, you read all nine. Forty minutes later you send eight, rewrite one, and work out that the time you saved on the writing came straight back out of your evening. The agent did not save you thirty six minutes. It moved them, out of writing, which you are decent at, and into checking, which nobody is good at and nobody enjoys.

Every tool you actually work in has an undo. Git has revert, your editor has a keystroke, staging has the comfort of breaking somewhere that does not count, and Gmail gives you thirty seconds. Nobody merges an email: there is no diff to skim, no test suite to run it past, no staging inbox to try it in, and no way back once it is sitting in somebody’s inbox, so the entire cost of being wrong lands on one person reading carefully. That gap, and not the model, is why your agent is trusted with code and kept well away from the account manager’s inbox. It is also why most agent pilots quietly stall.

The bottleneck moved and the tooling stayed put

Software is the one place where a lot of people pointed agents at real work and then measured what happened. The measurements are not subtle.

Faros AI compared two years of telemetry from 22,000 developers across 4,000 teams, looking at each organization at its lowest and highest AI adoption. Output went up. So did everything that output costs you.

The two shortest bars are the benefit. Everything longer is what the benefit cost. From Faros AI's 2026 report, The Acceleration Whiplash.

A third more tasks per developer, and five times the median review time (Faros AI, 2026). That is not a tooling problem or a model problem. That is a system that got very good at producing work and no better at absorbing it.

LinearB looked at the same squeeze from the other end, across 8.1 million pull requests from 4,800 teams in 42 countries, and found the detail that gives the game away.

AI-assisted work waits more than five times longer for someone to start reviewing it, then takes slightly less time to review than human work once they do. From LinearB's 2026 Engineering Benchmarks Report.

Read those two bars again. Once a reviewer actually starts, the AI-assisted change is faster to get through than the human one: 194 minutes against 252 (LinearB, 2026). The delay is not the reading. The delay is everything before the reading: the queue, the size of the thing, the sinking feeling, the decision to start.

The expensive part of verification was never the mechanical act of checking. It is the willingness to be the person who signs off.

Why software absorbed the flood anyway

Engineering took that hit and mostly kept moving, and it is worth being precise about why, because the reason is not talent or process maturity. It is that code is the most verifiable artifact a company produces, and it has been getting more verifiable for forty years.

Every finished piece of work raises the same five questions. Software spent four decades building cheap answers to all of them. Nobody built the other column.

A diff is a strange and wonderful thing. It turns “read this 400 line change” into “read these 40 lines that differ”, which is a reduction of an order of magnitude in what a human has to hold in their head. Tests turn “is it correct” into a boolean somebody else already thought about. Staging turns “will this break” into “it did not break over there”. A pull request turns approval into a record with a name on it. Revert turns a mistake into an inconvenience.

None of that exists for the work most of a company actually does.

There is no diff for an email. There is no staging environment for a CRM. No test suite asserts that the invoice you generated has the right billing period on it, and no button unsends the reply to a customer.

So when an agent produces that kind of work, the verification cost lands entirely on a human with no instruments, and it lands per unit of output. Double the output, double the checking. That is the whole story of why the demo felt like magic and the rollout felt like a second job.

Read next: Your agent has a half-life

The check has to be cheaper than the doing

Here is the arithmetic nobody puts in the pitch deck.

Let D be what it costs you to do the job yourself. Let C be what it costs to check the agent’s version. Let p be the chance it is wrong in a way you would care about, and R the cost when a wrong one gets through: the apology, the refund, the client who stops replying.

Delegating pays when:

C + p x R < D

The model only appears inside p. Everything else in that inequality is a property of your tooling, and it is the part every agent roadmap ignores.

Run it on the Friday nine. Writing one yourself is about six minutes, so D is 54 minutes. Reading nine drafts closely enough to put your name on them is about four minutes each, so C is 36, which is near enough the forty you actually spent. The saving is whatever is left, and it is thin. Note where it went, too: one draft was wrong, and you paid to check nine, because nothing in the pipeline could tell you which. Now make the drafts slightly harder to trust, so you reread the source thread for each one, and C passes D. The agent is now a net loss at 100% quality, because quality was never what you were paying for.

Work the agent finished	What you check it against	Cost to check	Cost if a bad one gets through
A code change	A diff, a test run, a staging deploy	Minutes, tool-assisted	A revert
Nine client emails	The nine source threads, from memory	Nearly the cost of writing them	A relationship
200 CRM records updated	Nothing. You spot check twelve and hope	Unbounded, so people skip it	A quarter of bad data

What checking costs across three kinds of agent work

Notice what happens in the bottom row. When C is unbounded, people do not pay it. They either check nothing and silently accept p x R, or they stop using the agent for that work. Both look like “the agent did not work out”. Neither is about the agent.

This is the same shape as the half-life problem: a per-step property that looks fine up close and decides everything at scale. There, it was reliability compounding over a long run. Here, it is verification cost compounding over volume. Both get fixed by changing the structure of the run, not the intelligence inside it.

Nobody is measuring this, including you

The obvious objection is that if verification were really eating the gains, people would notice.

They do not notice. That is the best-documented part of this whole argument.

METR ran a randomized controlled trial with 16 experienced open-source developers on 246 real tasks in repositories they already maintained. Before starting, the developers forecast that AI tools would make them 24% faster. Afterwards, having done the work, they believed they had been 20% faster. Measured, they took 19% longer.

A 39 point gap between what it felt like and what happened, from people with hundreds of hours of prompting experience. From METR's July 2025 randomized controlled trial.

These were not novices fumbling with a new toy. Nearly all of them had dozens to hundreds of hours of prior experience prompting models (METR, July 2025). The generation felt fast, because it was. The review, the correction, the second pass to understand what had been written for them: that time was real and it did not register.

Now scale that error up to a company. MIT’s Project NANDA, working from more than 300 publicly disclosed deployments, 52 interviews, and 153 survey responses, put the share of enterprise GenAI pilots with no measurable impact on the P&L at roughly 95% (MIT NANDA, 2025). People have argued about that methodology ever since. Nobody has argued that the number is small. Gartner expects more than 40% of agentic projects to be canceled by the end of 2027, citing costs and unclear value (Gartner, June 2025). DORA, surveying nearly 5,000 professionals, landed on the phrase that ties it together: AI is an amplifier (DORA, 2025). It makes a system with good feedback loops better and a system without them worse, faster.

Most business processes have no feedback loops at all. They have a person who would notice eventually.

Agents rarely fail an evaluation. They fail an audit nobody ran.

Five things that make agent work checkable

If verification cost is the constraint, then the interesting engineering is not in the agent loop. It is in everything the agent leaves behind. Five properties do most of the work, and none of them require a better model.

Artifacts, not transcripts

A chat transcript is the worst possible verification surface: linear, long, and it buries the output inside the reasoning. A file is the best one. You can open it, skim it, diff it against last month’s, hand it to someone else, and know at a glance whether the thing exists yet.

The rule is that finished work should be an object you can point at, not a passage you have to read to the end of.

A draft state before anything irreversible

This is the missing diff, and it is mostly a product decision rather than a research problem. Generate the email, do not send it. Compute the 200 CRM updates, write them as a table first. Produce the invoice as a file before it goes to the customer.

A draft turns an irreversible action into a reviewable artifact, which moves it out of the unbounded row of that table and into the cheap one. The work is identical. The verification cost is not.

Provenance on anything the agent believes

Half of checking is not “is this right”, it is “where did this come from”. An agent that says the client’s renewal is in March is unverifiable. An agent that says the renewal is in March, learned from the contract PDF you uploaded on 14 August, can be checked in four seconds.

That is why agent memory needs provenance and correction rather than a vector blob. Memory you cannot audit is a claim you have to re-derive, which is verification cost with extra steps.

A bounded record of what it touched

Not the full trace. Nobody reads the full trace. What you need is the ledger: what did it touch, when, and why. It is the difference between a stack trace and a receipt.

The test is whether someone can answer “what did it actually do yesterday” in under a minute without reading a single model output.

Reversibility where it exists, a human where it does not

Some actions can be undone, and those should be cheap to approve. Some cannot, and pretending otherwise is how teams get burned. Sending mail, moving money, posting publicly, deleting records: for those the honest answer is that a person confirms, and the product’s job is to make that confirmation a two second glance rather than an investigation.

How Construct is built around the check

We build an AI employee with a real computer, so this is the problem we live in. A few things follow directly from the argument above.

Work lands in a workspace filesystem as files, not as messages in a thread. That is the artifacts rule, and it is also why a run that dies partway through leaves usable output behind rather than a transcript to excavate.

Every action goes into Activity: what it affected, when it ran, and why. That is the receipt, not the stack trace, and it exists so the answer to “what did it do overnight” is a scroll rather than a project. Alongside it you get the files it produced, the tool records, and a read-only terminal transcript when you want to go deeper.

Memory is inspectable and correctable, with provenance and temporal context, so a claim can be traced to where it came from and fixed in place instead of argued with. Repeatable work becomes a saved workflow you can read before you schedule it. Current workflows are linear, which is a real limitation and also the reason a workflow is something you can hold in your head.

And the part we have not finished: Construct does not currently insert a mandatory approval gate before every external side effect. Drafts, interruption mid-run, and Activity give you a lot, but if a step sends a customer email or moves money, that step still needs supervision before you let it run unattended. We would rather say that plainly than let someone discover it on a Sunday.

The next 10x is not in the model

Every agent product is currently competing on the part that got commoditized. Producing plausible work is close to free and getting freer.

The scarce thing is a human’s willingness to sign their name under it, and that is bought with diffs, drafts, receipts, provenance, and undo. Software has had those for forty years and, funnily enough, software is the one place agents are actually working.

The rest of the company is waiting for someone to build them the other column.

Originally posted on construct.computer.

Your agent has a half-life

ankush4singh@gmail.com (Ankush Singh) — Tue, 11 Aug 2026 00:00:00 +0000

Valve named a game Half-Life after the physics joke hiding in plain sight: how long something lasts before half of it is gone. Your agent has one of those. It just does not get a hazmat suit or a crowbar out of the deal.

Take an agent that gets 95% of its individual steps right. That is a good agent. Now give it a ten-step job.

It finishes six times out of ten. The other four times, it fails halfway. Literally. A half-life.

Nothing broke. No step regressed. 0.95 to the tenth power is 0.60, and that is the whole story. Reliability that looks excellent per step is mediocre per job, and it gets worse in a way most people do not feel until they schedule something and walk away.

If you have been asking why your agent keeps failing halfway through a multi-step job, this is usually the answer, and it is not the one people go looking for.

Why your agent keeps failing on long tasks

The tempting explanation is that long tasks are harder tasks. Longer means more ambiguity, more chances to misread the goal, more compounding confusion.

That explanation is wrong, and there is a clean piece of work showing why. In “Is there a half-life for the success rates of AI agents?”, Toby Ord shows that agent performance across task lengths is explained by an extremely simple model: a constant rate of failing during each minute a human would take to do the task (Ord, arXiv:2505.05115). Not accumulating confusion. A flat hazard rate, ticking the entire time the job runs.

Physicists already have a letter for that rate. It is λ, the decay constant in N(t) = N₀·e^(−λt), and the half-life is just t½ = ln(2) / λ. Valve put the same λ on Gordon Freeman’s suit and in the Half-Life logo for the same reason: it is the constant that decides how long something lasts before it is gone. Ord’s result is that your agent has one too.

That gives every agent a half-life: the task duration at which its success probability hits 50%. Longer tasks fail, in Ord’s framing, because they contain increasingly large sets of subtasks where failing any one fails the whole thing. Raise λ (worse per-minute reliability) or raise exposure (longer jobs), and the surviving fraction falls the same way a sample of isotope does. You do not need a crowbar for this. You need less exposure.

This reframes the problem usefully. If failure were about difficulty, you would fix it with a smarter model. If failure is a rate per unit of exposure, you fix it by reducing exposure. Those are very different engineering programs, and almost everyone is running the first one.

Why multi-step agent workflows fail: 48 steps, 8.5% success

Ten steps is a toy. Real recurring business work is worse, because it loops.

Here is a job we hear about constantly from small agencies: monthly client reporting. Eight clients. For each one, pull analytics, pull ad spend, pull the CRM’s deal movement, write the summary, render it into the client’s template, email it. Six steps, eight times. Forty-eight steps.

Per-step reliability	One 48-step run finishes
99%	62%
95%	8.5%
90%	0.6%

A 95% agent, which is a genuinely capable agent, completes that job start to finish about one time in twelve. And the failure mode is the ugly one: it dies at client six, having already emailed five reports, and you cannot tell what state anything is in without reading the whole transcript. One continuous experiment, cascading into a mess you did not budget for. Black Mesa energy, spreadsheet edition.

So people conclude agents do not work for real operations. What actually does not work is running forty-eight steps as one uninterrupted bet.

Will a better model fix agent reliability?

There is a genuine counterargument: models are getting better at long tasks fast. METR measures the 50% time horizon, the task duration at which an agent is predicted to succeed half the time, using how long human experts need for the same work. That horizon has been doubling roughly every seven months for six years, with recent data suggesting faster (METR, measuring AI ability to complete long tasks; METR, time horizons).

That is real progress and it is not slowing. It is also a terrible thing to plan a business process around. The horizon is defined at 50% reliability, which is a coin flip, and the doubling curve tells you nothing about next Tuesday’s client reports. Gartner predicts that over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls (Gartner, June 2025). A large share of those projects will die from exactly this: a demo that worked once, scheduled weekly, quietly failing most weeks. Unforeseen consequences, delivered on a cron.

Waiting for the model is a strategy with no delivery date. Shortening the run is available now.

How to fix an agent that fails partway: cut the job at the seams

Split those forty-eight steps into eight independent six-step runs and the arithmetic inverts.

At 95% per step, one client’s six-step run finishes 73.5% of the time. So a pass over eight clients lands roughly six of them, and the two that failed are named, isolated, and retryable. Run the retry and you are at 93% of the work done, with the remaining gap being two specific clients you can look at rather than one opaque dead job.

Same model. Same per-step reliability. Same total work. The only change is where the run is allowed to stop and be resumed. You have not lowered λ. You have lowered how long any one run has to survive it.

The catch is that this only works if state survives between the pieces. A six-step run that has to rebuild its own context from scratch, re-derive what the client’s template looks like, re-fetch what it already fetched, has not been shortened. It has been shortened and then padded back out. Checkpointing is only cheap when the checkpoint is written somewhere durable.

In Half-Life 2, the Resistance spray-painted λ on walls to mark supply caches you could find later. Your agent needs the same kind of mark: a file on disk that says “this iteration already finished,” not a memory that evaporates when the turn ends. That is the actual argument for giving an agent a computer instead of a context window.

How Construct runs the same job

Construct’s agent has a persistent workspace: a filesystem that outlives the turn, long-term memories it carries across sessions, and reusable workflows that run on demand or from its Calendar. Those three pieces are what turn the client-reporting job from one long bet into a job that converges. Less HEV suit cosplay, more actual hazardous-environment gear: the state that has to survive the run is sitting on disk before anything else starts.

Concretely, the reporting job becomes one scheduled workflow rather than eight:

Piece	What it is in Construct	Why it matters to the math
The client list	A file in the workspace, `clients.md`, that the agent reads at the start of every run	The run’s scope is data on disk, not something rebuilt from a prompt each time
The completed work	One file per client under `reports/2026-08/`, written as each report finishes	Every finished iteration is a checkpoint that outlives the run that made it
The instruction	“For each client in `clients.md` with no report in `reports/2026-08/`, produce one and email it”	The job describes remaining work, so a rerun is a retry rather than a duplicate
Standing preferences	Long-term memory: the template a given client wants, which metrics they care about	Iteration six does not re-derive what iteration one already established
The retry	The schedule itself, plus an on-demand run when you want it sooner	The two clients that failed get picked up next pass with no manual bookkeeping
The diagnosis	The Activity feed’s bounded action summaries and best-effort reasons, plus chat’s bounded tool records	You find the step that broke instead of rereading a transcript

The important line is the third one. Because the instruction is scoped to clients without a report on disk, a run that dies at client six is not a disaster that needs unwinding. The next run reads the directory, sees five reports, and works on the remaining three. Nothing is sent twice, and nobody has to remember where it stopped.

Two honest boundaries. Construct’s workflows are linear today: branching, fan-out, and subworkflows are not supported, so the clients are worked through inside a run rather than dispatched as eight parallel jobs. And the schedule interval is your retry cadence, so a job that must finish within the hour needs an on-demand rerun rather than patience. The infrastructure that makes a per-user filesystem cheap enough to leave lying around between runs is in how our agents get real computers we mostly do not pay for.

Read next: AI Workflow Automation

A checklist for building a resumable agent job

The pattern generalizes past client reports. Anything shaped as “for each X, do a few things” is a candidate.

Find the loop. Almost every recurring ops job has one: per client, per invoice, per candidate, per repo. That loop boundary is your seam. Cut there first, because it is the cut that turns one long bet into many short ones.
Make each iteration leave an artifact. A file, a CRM record, a sent email. Something a later run can check for existence. If an iteration leaves nothing behind, you cannot tell a retry from a duplicate. Leave a λ on the wall.
Make iterations skip completed work. “Write the report for any client that does not already have one dated this month” is resumable. “Write the reports” is not. This one line is usually the difference between a job you can schedule and a job you have to babysit.
Put the ambiguous judgment in its own step. Judgment steps have a lower per-step success rate than mechanical ones. Isolating them means a bad judgment call costs you that step, not the run.
Supervise the first several runs on demand before scheduling. You are looking for which step is your weak link, and you will not guess it correctly.
Check the trail when something fails. Construct’s Activity feed keeps bounded action summaries and best-effort reasons, and chat retains bounded tool records, so a failed iteration can be traced to a step rather than to a vibe.

That third point is worth sitting with. Most people write agent instructions as a description of the work. The instructions that survive scheduling are written as a description of the work that remains.

What checkpointing does not fix

Checkpointing lowers the cost of failure. It does not lower the failure rate, and there are jobs where that distinction matters. You still have the same λ. You just refuse to stake the whole sample on one continuous exposure.

If your steps are genuinely order-dependent all the way through, with no natural loop and no safe stopping point, there is no seam to cut and you are back to one long bet. If a step has an irreversible external side effect, a payment, a public post, a message to a customer, then a retry is not free and idempotency has to be designed in rather than assumed. Construct lets you inspect a running task, interrupt it mid-turn, and answer a question the agent raises, but it does not currently insert a mandatory approval gate before every external side effect, so those steps still need real supervision before they run unattended.

Memory has a boundary too. Construct keeps workspace files and selected long-term memories across sessions, but automatic memory does not currently index uploaded files, private app results, terminal output, or live browser runs. Context that has to carry across a seam should be written to a file or stored explicitly, not assumed to survive because it appeared once in a transcript.

And if the work is genuinely deterministic, the same trigger and the same transformation every time with no judgment anywhere in the middle, a rule-based automation platform will do it more cheaply and more predictably than any agent. We laid out where that line falls in AI agent vs Zapier automation.

Ask this instead of “which model should I use”

“Which model should I use” is the question everyone asks. It is not usually the binding constraint. A model one tier better moves your per-step reliability a few points and leaves the exponent untouched. Restructuring a 48-step run into eight 6-step runs moves the exponent, which is where the leverage lives.

Ask instead: when this job fails at step thirty, what is left on disk, and what does the retry have to redo? If the answer is “nothing” and “all of it,” the model is not your problem. You do not need the right man in the wrong place. You need a workspace that outlives the turn.

Start with AI workflow automation for how reusable steps and schedules fit together, AI agent memory for what carries across runs and how to correct it, and how to choose an AI agent platform if you are evaluating this against other tools. If the underlying idea is new, what is an AI employee is the place to begin.

Originally posted on construct.computer.

All our Agents get computers, we pay for almost none

ankush4singh@gmail.com (Ankush Singh) — Fri, 31 Jul 2026 00:00:00 +0000

Construct is an AI employee. You hand it a job. It goes and does the job, without you having to babysit it.

To do that with agents like Hermes or OpenClaw, you spin up a VPS. Real CPU. Real disk. A full Linux machine that stays on between turns. That costs real money, and the moment more people sign up to poke around and never come back, it murders your infrastructure bill.

We give every Agent that same kind of computer.

Don’t get excited - we are not paying for all of them.

The computers work. When someone asks Construct to do something, the machine wakes up and does it. When the tab goes quiet, nothing stays on just to cosplay as useful. Idle boxes are a kink we refuse to subsidize.

We like edging. So we put the whole stack on the edge. Agent loop in a Durable Object. Linux summoned for one tool call, then gone. Disk that is not a disk. The bill only finishes when somebody actually works.

This post is how we built that. Behaviour, constants, and tradeoffs are production.

The bill that scaled with people who never came back

The default way to run an AI agent is to hand it a Linux box and walk away.

Not stupid. Agents are trained on bash. Bash wants a filesystem and a process table. The lazy move is a machine that stays up between turns. Lazy is usually correct.

Until the invoice arrives.

We know that invoice because we signed it first. Construct’s original backend was a Bun and Elysia monolith on a VPS. SQLite on local disk. nginx out front. Roughly 1,300 lines of container management whose only job was handing every user their own box. It worked. Growing the product meant growing a fleet of real machines with real disks, billed through the silent hours where nobody typed a character.

That is the expensive version of “every user gets a computer.” Technically true. Financially a treadmill. Someone who signed up once and ghosted cost the same as a power user. The product could not scale if the bill scaled with accounts instead of work.

We killed it on 30 March 2026. Commit title: “migrate backend from VPS monolith to Cloudflare Workers.” Everything in this post starts there.

Hono on Workers. Per-user WebSocket hub in a Durable Object with hibernation. Container object that archived to R2 on sleep and restored on wake. D1 for relational state. R2 for files. Frontend on Workers assets. Two days later we dragged the leftover container infrastructure into a legacy folder and wrote the plan we still run: the agent runs headlessly inside Durable Objects.

Containers and Sandboxes went GA on 13 April 2026. We moved onto the Sandbox SDK once it had the shape we wanted.

We did not see the future. We stared at a cost curve that scaled with signups instead of usage, bet on Durable Objects before there was a tidy product name for the thing, and watched the platform walk to the same answer. camelAI hit the same wall and reached nearly the same conclusion independently. Validation, or a warning about people who write posts like this. Both.

Only half a computer deserves to be awake

“The agent needs a computer” is two unrelated things taped together.

Agent loop: transcript, tool routing, model calls, memory recall. This is how Construct thinks across a turn.

Machine: the thing that runs pdftotext, converts a spreadsheet, compiles a project, unzips the archive somebody should not have uploaded. This is how Construct touches a real filesystem.

Only the second needs Linux.

The first needs durable state and a socket. Cloudflare sells exactly that. Split the two and the expensive half stops needing to be alive at all.

Everybody argues about which model to use. Almost nobody argues about which half of their stack is getting paid to nap. That is the whole post, in one sentence.

Linux shows up, edges the job, and leaves

This is the section the title is about.

Each Construct agent gets one Durable Object, resolved by name. Sessions are rows inside it, not objects of their own. Temporary subagents run as delegated sessions on the same parent. Fan out a job - buy concurrency, not instances. That is how Construct can split a big ask without spinning up a fleet.

The transcript lives in that object’s SQLite. Two things, kept apart on purpose. One table is the append-only message log the user scrolls through. A separate record holds the compaction summary plus a watermark of how far it has already consumed. That second one is what reaches the model. Conflate them and you pay, per turn, to re-send an afternoon of conversation to a model that did not ask for it. People do this. At scale.

Hibernation is where the bill actually moves. We use the WebSocket hibernation API, stash per-connection state on the socket itself, and let the runtime answer keepalives without ever waking the object.

A tab open all afternoon is not a running process. It is a socket the runtime holds and a handful of SQLite rows. The object wakes when something happens. Goes back down when it does not. Held, not running. Your Construct session feels continuous. Our invoice does not.

Eviction can happen any moment, so every transcript row also archives to D1. Empty on start? Restore from the archive. Make death cheap and constant and it stops being an incident.

One annoying edge case: replayed reconnect events can include a turn-started with no matching completion, because the object got evicted mid-turn. Client reconnects, nothing is running - we send terminal idle status so nobody sits watching a spinner think about a thought that died twenty minutes ago.

When the agent calls the terminal tool, we resolve a sandbox:

sandbox = getSandbox(SANDBOX_BINDING, instanceKeyFor(user, workspace), {
 transport: rpc,
 enableDefaultSession: false, # every exec is a fresh shell
 sleepAfter: idleWindowFor(plan),
})

Instance key scoped to user, or workspace when we know it. Not per agent. Not per session. Live containers track active humans, not agent count. Matters the moment somebody spawns twelve agents and goes to lunch.

sleepAfter is the pivot. Ten minutes idle and the box is gone. We call that a feature. You can call it edging. Same config value. The idle window is the plan’s command ceiling in minutes, clamped by a global 300-second cap, plus a five minute buffer. That resolves to a ten minute sleep on every plan today. Pair with active CPU billing on Cloudflare Containers - charged for CPU consumed, not wall-clock uptime - and an idle sandbox stops being something you manage.

Difference between “we should build a reaper for idle machines” and “there is nothing to reap.” One is a roadmap item forever. The other is a config value.

Unglamorous consequence: every exec is a fresh shell. Working directory does not persist. Agents hate this personally. We wrote a hint into the failure path explaining that each terminal call starts clean, relative paths resolve against the scratch tree, and any directory change or exported variable from an earlier call is gone forever. Grief counselling in a string in an error branch.

Before each exec: kill leftover processes, then mount, then run. Kill after mount and you drop the local bucket’s inotify watch and can leave a stale read-only workspace behind. Learned that the hard way.

She wrangler on my D1 till I R2

Construct’s durable workspace is an R2 bucket mounted into the container over s3fs. allow_other. Explicit uid and gid so the non-root user can actually write.

She wrangler on my D1 till I R2. The files finish. The machine does not have to.

This is the second half of the cost story, and the half people skip. Quotas of 100 MB, 1 GB, and 3 GB are quotas on bytes stored, not volumes kept spun up. When Construct saves a report, a spreadsheet, or a research brief, those files outlive the machine by construction. They were never on the machine. Nobody’s work sits on provisioned block storage waiting for their owner to remember the product exists.

Contrast again: provisioned volume waiting patiently versus bytes in R2 that do not care if the box is awake.

How we verify the mount matters more than the mount itself. Checking the directory exists is useless. Passes on a stale read-only mount every time. So we make the non-root user touch a probe file and delete it, with a ten second timeout. Exit code zero means the mount is actually writable.

Probe fails: unmount, remount, fix ownership, probe again, only then give up. Debounced to once a minute. Isolate-level mount cache key carries a version string we bump when mount policy changes, so a warm isolate can never silently skip a policy change.

Honest footnote: local development uses plain directory sync, not FUSE. Files land root-owned. We chown on mount. That local/prod divergence cost us an afternoon. It is why we trust a write probe over any status output that claims everything is fine.

What living on the edge actually costs

No sales pitch from here down. Living on the edge has a price. We pay it.

You cannot set USER in a Cloudflare Sandbox image. Control plane intercepts HTTPS and needs root. Privilege drop moves to the point of execution. Dom energy stays with the control plane. The agent bottoms out as runuser. Elevated commands stay root through a wrapper. Everything else is runuser -u <agent user>.

No sudo. No passwordless sudoers. Process and FD limits by the wrapper. Elevated access per command or until the container sleeps. Grants live inside the container, not Worker memory. Once the machine is disposable, the container is the correct place for short-lived trust. Permission that dies with the box is permission you never have to remember to revoke.

Memory and a registry catalog used to be separate Workers behind service bindings. We folded them into one. Never a latency optimisation. Service bindings are already efficient in-account transport. The cost was operational: two more deployments, more local processes, more domains, more generated binding contracts, releases that had to be choreographed. Microservice theatre for 41 KiB. We stopped. Nothing came.

Memory was about 41 KiB compressed. Registry under 1 KiB. Combined Worker about 1,002 KiB against a 2 MiB gate. 500 ms startup stays a cutover check because Wrangler dry runs do not report startup. We wrote down when to undo it: compressed bundle past 2 MiB, startup past 500 ms, own release cadence needed, or failures widen the API blast radius. Four triggers. Before anyone got attached.

Web app served by a Worker with static assets rather than Pages, because we needed custom domains to manage their own DNS and Pages OAuth could not.

Living on the edge means never assuming you have time. Construct’s memory recall runs on a budget. Whole recall: 800 ms. Inside that, remote embedding plus Vectorize: 250 ms. Those are configured budgets, not measured percentiles. We do not have deployed latency dashboards yet. Docs say so.

SQLite full-text search and graph traversal are the floor and always return, local to the Durable Object. Vectorize is best-effort on top. Vector path drags: slightly worse answer, not a hang. On one big warm box you would simply wait. Waiting is exactly what you cannot afford when nothing is warm by default. Warmth is a luxury. Edging is the default.

Embedding model was the one place with real measurements. 18-query set with close distractors, on Workers AI:

Model	recall@1	mrr
qwen3-embedding-0.6b	15/18	0.892
bge-m3	14/18	0.889
bge-large-en-v1.5	13/18	0.852
embeddinggemma-300m	12/18	0.824

Qwen3 is trained for asymmetric retrieval. Tell it whether it holds a question or a stored record and ranking tightens. Query-side instruction moved mrr from 0.892 to 0.924 on the same set. Free accuracy for one string. Take it.

A 0.6b model also keeps this inside budget. Memory pipeline gate: USD 1 per 1,000 turns, excluding the primary chat model. Do not swap embedding models casually. Vectorize indexes are built at those exact dimensions. Different model means recreate and re-embed everything.

Three scars from the platform:

setTimeout versus setAlarm has a boundary around ten seconds. Discord gateway reconnects with backoff. Anything beyond ten seconds goes on an alarm. Timers do not survive eviction. That object holds one WebSocket for every guild we serve. Split it when Discord reports more than one shard, somewhere around 2,500 guilds. Better to schedule that than discover it at 3am.

A fallback on the same backend as its primary is not a fallback. Same outage, different name. Compaction runs the same Gemma build on Workers AI and AI Studio. Failover costs the route. Every other slot crosses providers.

Alarms hand you a bare Durable Object id. ctx.id.name only exists when you reached the object through a named stub. Alarm-triggered instantiation does not. Ours addressed outbound messages. Queue rejected them. Repair alarm re-queued forever, at cost. Infinite unfinished business. Fix: persist the name on first use. Nothing warns you.

The container is real. It is not free. Image lands between 1.5 and 1.9 GB, which forces standard-1, because disk allocation is effectively the image size limit. LibreOffice needs 4 GiB or it gets OOM killed. Production configured for up to 100 concurrent instances. Command execution capped at 300 seconds on every plan today. That is a real product limit this architecture caused, not a feature. s3fs is not real POSIX. It will surprise you on a weekend. Fresh shells irritate agents trained on bash. We pay for that in prompt tokens.

Flat version: if your workload is one long-lived process per user that truly never idles, none of this helps you. Buy a VM. Simpler. Happier. Nobody will make edging jokes at you.

What we run today

Workers. Durable Objects with SQLite storage. Containers through the Sandbox SDK. D1. R2. Queues with dead letter queues. Vectorize. Workers AI. AI Gateway. Email Routing inbound with the send binding outbound. Rate limiting bindings. Cache API. Turnstile. Cron triggers. Static assets. Workers Logs. Agents SDK.

No KV. No Hyperdrive. No machines of our own. Just Construct users with computers that mostly sleep.

construct.computer is Cloudflare too: Pages, Functions, D1, Turnstile, and the WAF.

All our Agents get computers, we pay for almost none.

We like edging. So we put the whole stack on the edge.

That is how an AI employee can feel always-on without an always-on bill.

If you want the product side rather than the plumbing, what an AI employee actually does covers the work it completes, inspectable agent memory covers what it remembers and how you correct it, and building your own agent stack is the honest version of what you would be operating instead.

Originally posted on construct.computer.

How to Choose an AI Agent Platform for Your Team

ankush4singh@gmail.com (Ankush Singh) — Tue, 28 Jul 2026 00:00:00 +0000

Most teams evaluating an AI agent platform compare feature lists and demo videos, then discover months later that the demo and the production job were not the same thing. This is a vendor-agnostic framework for how to choose an AI agent platform: why pilots stall, six criteria that actually predict whether a platform survives contact with real work, the governance rules now attached to that decision, and a scorecard you can apply to any product on your shortlist.

Why most AI agent pilots never reach production

An estimated 88% of AI agent pilots fail to reach production, according to an analysis of enterprise deployments compiled by Digital Applied (Digital Applied, AI agent failure framework). Gartner forecasts the same trend from the vendor side: more than 40% of agentic AI projects will be canceled by the end of 2027 due to escalating costs, unclear business value, or inadequate risk controls (Gartner, press release, cited via Digital Applied’s agent-washing scorecard). Gartner Senior Director Analyst Anushree Verma named the underlying problem directly: “most agentic projects today are early-stage experiments driven by hype,” which blinds organizations to the real cost and complexity of deploying agents at scale.

The failure pattern is not random. Digital Applied’s breakdown attributes 34% of failed pilots to scope creep, where an initially bounded automation absorbs new requirements until it becomes an open-ended reasoning system nobody scoped for. Data quality failures account for another 27%, when an agent tested against clean sample data meets production records full of incomplete fields and stale formatting. Security and access-control blockers cause 14% of failures, integration complexity accounts for 9%, and governance gaps, missing ownership, monitoring, or incident response, cause another 5% (Digital Applied, AI agent failure framework). Scope and data readiness alone explain most of the gap between a working demo and a working system.

This is also an active buying decision for most teams, not a settled one. Only 17% of organizations had deployed AI agents as of 2026, while more than 60% expect to deploy within two years, per Gartner’s CIO survey (Digital Applied, agent-washing scorecard). The evaluation criteria below are aimed at that gap: the difference between a platform that produces a good pilot and one that keeps producing good results after the third team starts depending on it.

The AI agent evaluation checklist: 6 criteria that separate a pilot from a platform

Feature lists answer “can it do the task once, in a demo.” These six criteria answer “will it still be trustworthy after the fifth team is running unsupervised jobs on it.” Apply each one to any platform on your shortlist before you commit engineering time to a pilot.

Tool orchestration and execution surfaces (browser, terminal, files, connected apps)

Ask what the agent can actually act on, not just what it can talk about. A platform limited to chat and a handful of first-party plugins can explain a task; a platform with a real browser, a sandboxed terminal, persistent files, and structured connected-app actions can complete one. The distinction matters because real jobs mix surfaces: a research step needs the open web, a records update needs a structured app action rather than screen-scraping, and a file transform needs a terminal with somewhere durable to write the result.

Human-in-the-loop controls and approval gates

The question is not whether a platform claims supervision. It is what specifically happens before an agent takes an external action a person did not directly request: can you interrupt a running task, does the agent stop to ask when something is ambiguous, and is there a mandatory approval step before it emails a customer or posts publicly. A platform that answers “yes, generally” to all three without naming the mechanism has not actually answered the question.

Audit trails and inspectable activity (and what “audit trail” should actually mean)

Vendors use “audit trail” loosely, and the gap between what it implies and what a product delivers matters once something goes wrong. A forensic audit log is an immutable, complete record of every operation, suitable for a compliance investigation. A bounded activity summary is a readable record of what an agent did and roughly why, suitable for an operator reviewing a day’s work. Both are useful. They are not the same claim, and a buyer who needs the former should not accept a vendor’s description of the latter at face value.

Connector coverage and custom integrations via MCP

Off-the-shelf integrations cover the common apps, but almost every real deployment eventually hits an internal system with no public API partnership. The Model Context Protocol (MCP) has become the standard way agent platforms reach those systems: about 41% of surveyed software organizations already report agents connected through MCP servers in limited or broad production, according to Stacklok’s 2026 survey as reported by Digital Applied (Digital Applied, MCP adoption statistics). Ask whether a platform supports custom MCP servers rather than only a fixed integration catalog, since that is what determines whether an internal tool can be reached without waiting on the vendor’s roadmap.

Persistent, correctable memory across sessions

A long chat history is not memory. The useful question is whether a platform can carry forward a stable fact, such as a preferred report format or a client contact, and whether you can correct that fact when it changes without wiping everything else the system knows. A platform that cannot distinguish “what was said” from “what is currently true” will eventually act on something that used to be accurate.

Pricing model and real usage limits, not just a price tag

A published price answers less than it appears to. The number that actually predicts whether a plan fits a job is what gets metered: steps per task, command runtime, concurrent background jobs, and storage. Two platforms at the same monthly price can support very different workloads depending on where those limits sit, and a plan that looks generous on paper can throttle a deep research task or a long file transform before it finishes.

Governance pressure is raising the bar: EU AI Act and “agent washing”

Two outside pressures are pushing evaluation criteria from nice-to-have to load-bearing. The first is regulatory. The EU AI Act’s Article 14 requires high-risk AI systems to be designed so a human can effectively oversee them: monitor operation, intervene, and halt the system through a stop mechanism or equivalent procedure (EU AI Act, Article 14). The Act’s full set of high-risk obligations, risk management, data governance, logging, transparency, human oversight, and cybersecurity, along with deployer obligations, becomes enforceable on August 2, 2026 (Legal Nodes, EU AI Act 2026 compliance timeline). A team whose agent work touches a use case the Act classifies as high-risk needs to treat human-in-the-loop controls and inspectable activity as compliance requirements, not product preferences.

The second pressure is a credibility problem inside the market itself. Gartner estimates that only about 130 of the thousands of vendors marketing “agentic AI” are genuinely agentic; the rest is what Gartner calls agent washing, existing chatbots, RPA, or assistants relabeled for a hotter category (Digital Applied, agent-washing definition and buyer’s scorecard). That is exactly why the checklist above asks what a platform actually does rather than what it calls itself: a chatbot with a new label still cannot orchestrate tools, hold correctable memory, or leave an inspectable trail, no matter what the pitch deck says.

Questions to ask a vendor before you pilot

Bring these questions into a vendor call before you commit engineering time to a pilot. Each maps to one of the six criteria above.

What can the agent act on beyond chat, and what happens to that work when the session ends?
What specifically stops the agent from doing something it should not? Look for an explicit allowlist of capabilities, connected apps, and network origins with runtime denial of calls outside that allowlist.
Is “audit trail” a forensic log or a readable summary? Get an explicit statement rather than implied feature language.
Can we reach a system you do not already integrate with? Support for custom MCP servers means an internal system can be reached without waiting for first-party support.
Can the agent be wrong about something and be corrected without losing everything else it knows? Look for versioned memory assertions where a correction supersedes a stale fact while keeping history.
What is metered, beyond the sticker price? Ask for steps per task, command runtime, concurrent jobs, and storage limits stated plainly.

A 6-point scorecard you can apply to any AI agent platform

Score each criterion against a specific platform before a pilot, not after. A platform that cannot answer a row concretely, only in marketing language, should lose points on that row regardless of how polished the demo looked.

#	Criterion	Weak signal	Strong signal
1	Execution surfaces	Chat plus a fixed plugin list	Browser, terminal, files, and connected-app actions in one task
2	Human-in-the-loop controls	“Supervised” with no named mechanism	Named interrupt, ask-for-input, and approval behavior, with stated gaps
3	Audit trail	Vague “full audit trail” claim	Explicit statement of whether it is forensic or a bounded summary
4	Connector coverage	Fixed integration catalog only	Native catalog plus custom MCP or an equivalent extension path
5	Memory	Long chat history described as memory	Correctable, provenance-tracked assertions separate from raw history
6	Pricing and limits	Price with no usage detail	Price plus steps, runtime, concurrency, and storage limits stated plainly

A team piloting inbound lead qualification, for example, would run this scorecard against each shortlisted platform using the actual job: read a lead email, decide whether it qualifies, update the CRM, and notify the team in Slack. Score row 1 by watching which surface handles the CRM update. Score row 3 by asking, in writing, whether the vendor’s activity record would hold up in a compliance review or only in a weekly stand-up. A platform that scores well on four rows and poorly on two has told you exactly where the pilot needs extra supervision, not whether to abandon it.

Originally posted on construct.computer.

How Construct Builds Internal Tools in Your Workspace

ankush4singh@gmail.com (Ankush Singh) — Mon, 27 Jul 2026 00:00:00 +0000

Internal tools often begin as a spreadsheet, a checklist, or a prompt someone runs every week. The process works, but the interface does not: people copy values between tabs, remember status in their heads, and repeat the same setup each time. Construct can turn that repeated process into a small private app that lives inside the same workspace as the files and agent doing the work.

This is not a one-click path to a public SaaS product. A Construct workspace app is a focused internal interface for one workspace. You describe the job, the agent writes the app, checks that it builds, opens it in the desktop, and keeps the source available for inspection and later changes.

Start with the repeated process

The best request describes the work rather than prescribing a software architecture. For example:

“Build a research request tracker with an owner, priority, status, and link to the finished report.”
“Turn this recurring launch checklist into an app the team can update.”
“Create a dashboard for the JSON reports stored in this workspace.”
“Build an intake form for customer-review requests and keep the queue in one place.”

Construct can start from a list, form, dashboard, or blank interface. The agent creates the app package, writes the React and TypeScript source, declares the capabilities it needs, and validates the result. A successful build opens directly in the Construct web desktop instead of sending you to a separate hosting project.

The request still matters. “Build an operations dashboard” leaves important choices unresolved. “Show open research requests, let an operator assign an owner, and mark the linked report as reviewed” gives the agent a bounded workflow and a clear way to tell whether the app is useful.

The app lives beside the work

A workspace app is not a hidden artifact. Its source lives under an Apps/<app-id>/ folder in Files, where it can be inspected and edited. After a successful build, the app appears as a private workspace install that can be reopened from the desktop, Launchpad, or Spotlight.

The app’s durable state is kept separately under AppData/<app-id>/. That separation is important: changing the interface should not require overwriting the records the app already manages. Rebuilding can update the code while existing app data remains in the workspace and continues to count against the normal workspace storage quota.

This model also makes the surrounding agent useful after launch. The same workspace contains the source, relevant files, conversations, and diagnostics. If the interface needs another field or a runtime error appears, the next task can start with the actual app rather than a screenshot and a vague bug report.

What a workspace app can do

The current runtime is intentionally narrower than a general web-hosting platform. That keeps an internal tool close to its workspace purpose.

Capability	Current workspace-app support
React interface	Yes
TypeScript and TSX	Yes
Read or write workspace files	With declared permission
App-scoped JSON state	With declared Files permission
Call an allowed connected app	With an explicit app allowlist
Make direct network requests	Only to declared HTTPS origins
Install arbitrary npm packages	No
Run terminal or agent orchestration from the app UI	No
Publish automatically to the public app registry	No

The app UI receives a small Construct SDK for workspace files, app-scoped storage, notifications, window controls, and explicitly permitted calls. It does not inherit every tool available to the agent that authored it. The agent can use broader execution surfaces while building, but the finished interface runs with its own narrower contract.

Permissions are part of the design

An internal tool should not gain broad access simply because it was generated inside a trusted workspace. A workspace app declares the native capabilities, connected apps, and network origins it intends to use. Calls outside those allowlists are denied at runtime.

The platform also rechecks current workspace membership and permissions when the app makes a gateway call. File operations remain subject to the user’s workspace access, and an app cannot use its file access to rewrite another app’s package. Direct network access is limited to exact HTTPS origins rather than wildcard domains.

For a request tracker that only reads and writes workspace files, that can mean declaring Files access and nothing else. A tool that posts an approved record to a connected service needs that specific app target as well. The useful default is the smallest permission set that completes the job.

Validation creates a build, not a guarantee

Before launch, Construct checks the package structure and manifest, follows relative imports, enforces package boundaries, compiles the TypeScript and JSX, and reports design findings. A successful validation creates an immutable artifact with a deterministic build ID and opens the app.

That proves the package can be built under the workspace runtime. It does not prove that every button, data shape, connected service, or edge case behaves correctly. Runtime verification still matters, especially after changing permissions, storage behavior, or an external call.

Construct captures bounded console, network, gateway, and runtime-error diagnostics from workspace apps. The agent can inspect recent errors, repair the source, validate again, and ask you to verify the changed behavior. The loop is closer to maintaining a small internal product than generating a disposable code snippet.

Draft changes do not replace the last good build

The reliability model is deliberately conservative. A successful build becomes the current runtime artifact. Later source edits mark the app as having draft changes, but opening the app continues to run the last successful build until the new source validates.

If validation fails, the working artifact is not replaced. Cancelling an edit also leaves both the source and prior build in place. The desktop can show whether an app is ready, has draft changes, or has never built successfully.

This is a last-good-build fallback, not full version history. It protects the working tool while a repair is in progress; it does not promise browsing or restoring every historical build.

Internal tool or workflow?

Not every repeated process needs an interface. Use a workspace app when people need to view, enter, filter, or review state. Use a Construct workflow when the main value is running a known sequence of agent steps, connected-app actions, and notifications. Use a scheduled agent job when the process should run in the background without waiting for someone to open a screen.

The two can support the same operation. A workspace app can provide the queue and review surface, while files hold durable records and a scheduled job prepares new work. The important boundary is that the app UI does not secretly become an unrestricted agent: automation still runs through the execution surfaces and permissions designed for it.

Where workspace apps fit

Good fits are narrow tools with a clear operator and a durable workspace context:

Intake forms and review queues
Checklists for repeated operations
Lightweight trackers over workspace records
Dashboards for files or app-scoped JSON data
Focused interfaces over an explicitly allowed connected service
Small utilities that make an existing workflow easier to run and inspect

Poor fits include public customer-facing sites, products that require an arbitrary npm ecosystem, complex multi-service systems, or workloads that need independently operated infrastructure and security controls. Public registry apps also follow a separate developer and review workflow; a private workspace build is not automatically promoted to the public app registry.

Build the smallest useful interface

The shortest path is to start with one repeated process and one person who needs to operate it. Name the records the app should manage, the actions the operator should take, the files or services it may access, and what a successful result looks like. Then ask Construct to build the smallest interface that makes that process easier to run and supervise.

Once the first build opens, use it. The missing field, unclear status, or unnecessary screen becomes obvious faster in a working tool than in a long specification. Construct can revise the source while the previous good build remains available, giving the internal tool room to improve without turning every edit into a fresh software project.

Originally posted on construct.computer.

How I built a Pokemon TCG scanner that runs 100% in your browser

ankush4singh@gmail.com (Ankush Singh) — Sun, 18 Jan 2026 00:00:00 +0000

It's fast. Really fast.

I have always been a huge fan of Pokemon. I have played almost every game from GBC to HGSS, and recently played a few 3DS games when I got my hands on a ’new’ 3DS in Thailand.

I also started collecting Pokemon cards last year and as of writing this, I have around 350-400 cards. I couldnt look at them just sitting tightly in a tin and a cardbox, so I bought a pack of penny sleeves and a good binder (without the O-rings) and put all the shiny sparkly holo cards with cool looking artwork at the front, following with reverse holows and other normal cards that I like, and yanked the rest of the bulk back into the tin :)

At this point I have a bunch of cool art cards, in English, Thai, Japanese, Korean and Chinese, which look soo cool and valuable. I then tried a bunch of apps that scan pokemon cards and tell you more about it, but they all had their limitations or were straightup paywalled, that too by a large margin (not even an amount that one just spends without thinking much), so I did what every engineer would do at that point

I hacked my own Pokemon card scanner <insert maniacal laughter>

TLDR; scraped ~20K card data and images from TCGdex, generated embeddings using OpenAI CLIP model, and used OpenCV to very crudely find a rectangle like region in the image, and crop it out to search in the embeddings.

While the initial setup worked flawlessly on my mac, it was just a hacky taped together REST API that took an image and returned the card name, card id, image url, and had a bunch of issues I would have to deal with if I wanted to launch this as an app.

The image embeddings took around 7 minutes using MPS on my Mac, which is fine, because inference is usually much quicker (~800ms at that time on mac), when I uploaded the embeddings to my VPS without a GPU and served the API, it took multiple seconds to identify the card from an image, which was disastrous. Continuing to use the VPS for reverse image search was the worst thing I could have done.

I decided I will move everything client side and run everything in the browser- card detection, cropping, recognition, data fetching, everything, and started reading more about different CLIP embedding models- SigLIP, OpenCLIP, MobileCLIP, ViTs, etc etc… and tried every single one of them. I also learnt about Model Quantization, where you reduce floating point accuracy to reduce the size of model (with some loss in accuracy) and make it run faster with less memory and power. Int8 quantization worked good enough for SigLIP.

I had already setup a workflow in the process, to generate embeddings and run it on the web using TF.js + onnx web runtime. I used SigLIP for a day or two, deployed a PWA and started messing around with it on my phone, and ended up switching it with MobileClip-S2, which had better results and accuracy recognising pokemon cards. There was some hurdles with quantization, Int8 always broke the exported onnx somehow, but FP16 quntization was fine and I ended up using that (whatever works well right?)

I also realised that all this time I had been using WebGL/wasm for inference on the web, and added WebGPU backend for Tfjs, which immedieately made inference much much faster.

Sidequest: YOLO model to specifically detect pokemon cards

While opencv rectangle countour thingie to crop out cards works okay for still images, it failed drastically for video streams, which I was trying to use, so I ended up training a YOLO11n model on a pokemon cards dataset I found online, and it worked pretty well and really fast, while also being around 5mb for the entire model

By now the inference time on desktop averaged around 10ms for detection using yolo11n and 50-80ms for recognition using MobileClip-S2 and searching the embeddings, with similar times on mobile for yolo and usually a few hundred ms for recognition, but never more than a second if you have a good phone (not guaranteeing anything though)

Cool, now I have a working scanner which is fast runs client side

What next? Data. TCGplayer has an extensive database on English cards, but Japanese and other languages? next to none So I had to look for other sources with both card data and images and ended up scraping limitlesstcg for both English and Japanese. I also ended up using the TCGplayer apis to fetch pricing info for all cards and sets, including variations like card condition- near mint, lightly played, damaged, card type- normal, holo, reverse holo.

Now I have a codebase which can:

download english card data from tcgdex
download japanese card data from limitlesstcg
merge both to fill in missing cards and their info
fetch whatever price info it can find for our merged cards db
has apis to search & query our data

Package and ship

Setup a cron on my VPS to update my card data every 3 days, cleaned up the codebase, wrote QOL scripts, built a nice little frontend hosted it on mypokemonscanner.com and we’re done building our card scanner (•̀ᴗ•́ )و

Update: mypokemonscanner.com is no longer online, but the Wayback Machine has an archived snapshot. The project page has the demo and the tech stack.

Building a DOOM-Style 3D Renderer from Scratch in JavaScript

ankush4singh@gmail.com (Ankush Singh) — Wed, 24 Dec 2025 00:00:00 +0000

Links: Full Source Code

Move with WASD

Recently I have been adding games to my portfolio and DOOM is one of them. But instead of just embedding the original game, I wanted to understand how it actually worked. So I went down the rabbit hole (a second time) and built a more whacky version of the doom renderer from scratch and in HTML canvas, no extra dependencies.

Turns out, classic games like DOOM didn’t do real 3D at all. They used something called 2.5D rendering, basically faking 3D with clever 2D math. And it ran on hardware way worse (100x or more times worse) than what you are reading this on.

Today I’ll break down how I built my own DOOM-style renderer. No fancy tools required, just a code editor and a web browser.

Is 3D actually 3D?

At its core, 3D rendering is basically “If we have a 3D world and a camera, what does the camera see?”

This process generally involves defining the world (objects), placing the camera (viewer), projecting those 3D coordinates onto a flat 2D screen, and finally filling the screen with the correct colors (drawing pixels).

 3D World Camera 2D Screen
 ┌─────────┐ ┌─────────┐
 │ ▓▓▓ │ ────────────► │ ▓▓ │
 │ ▓▓▓ │ (projection) │ ▓▓▓▓ │
 │ ▓▓ │ │ ▓▓ │
 └─────────┘ └─────────┘

Representing Space with a top down 2D Map

The simplest way to define a world map is with a grid map. We can represent this as an array where each cell is either a wall (1) or empty space (0).

const MAP_WIDTH = 11 // Number of rows
const MAP_HEIGHT = 17 // Number of columns
const TILE_SIZE = 25 // Size of each tile in world units, increasing this makes the map look more spread out
const WALL_HEIGHT = 40

const MAP = [
 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,
 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1,
 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1,
 1, 0, 0, 1, 0, 0, 0, 1, 0, 0, 1,
 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1,
 // ... more rows
]

This is effectively a top-down view of the world.

■■■■■■■■■■■
■ ■
■ ■
■ ■ ■ ■ ← Interior pillars
■ ■
■ ■
■■■■■■■■■■■

Why 2D Maps for 3D?

This is one of the techniques games like DOOM used to achieve their 3D effect. The world is fundamentally 2D with height. The X and Y coordinates define horizontal position, while height is just a property of the walls rather than a full 3D coordinate.

Player State

The player (our camera) is defined by three simple values: an x and y position in the world, and an angle representing the direction they are facing.

const Player = {
 x: 50, // World X position
 y: 50, // World Y position 
 angle: 0, // Direction facing
}

Coordinate System

We use a standard coordinate system where angle 0° looks toward positive Y (down on the map) and 90° looks toward positive X (right on the map). All angles are in degrees (0-359).

 180° (0,0) ────────► X
 ▲ │
 │ │
 │ │
270° ◄────┼────► 90° │
 │ ▼
 ▼ Y
 0°

For performance, we pre-calculate degree-to-radian conversions so we don’t have to constantly do the math during the render loop.

const RAD = Math.PI / 180
const DEG_TO_RAD = Array.from({ length: 360 }, (_, i) => i * RAD)

// Usage: instead of calculating Math.sin(angle * Math.PI / 180)
// We just do: Math.sin(DEG_TO_RAD[angle])

Transforming World to Screen

This is where the 3D illusion happens! We need to transform world coordinates to screen coordinates in two steps.

Step 1: Translate (Move world relative to player)

First, we move everything so the player is at the origin (0, 0). We simply subtract the player’s position from the wall’s position.

So instead of actually moving the player, we are moving the world relative to the player. From the players perspective, it seems they are moving.

const relX = wallX - Player.x
const relY = wallY - Player.y

Step 2: Rotate (Align world objects with viewing angle)

We rotate the worlds objects relative to the player’s viewing angle.

const ps = Math.sin(DEG_TO_RAD[Player.angle]) // sin of player angle
const pc = Math.cos(DEG_TO_RAD[Player.angle]) // cos of player angle

// Rotation matrix application
const tx = relX * pc + relY * ps // transformed X (left/right)
const ty = relY * pc - relX * ps // transformed Y (depth/distance)

What this means: tx is how far left or right the point is from center of view, and ty is how far forward the point is (the depth).

Projecting 3D data onto 2D screen

The furthest the image is, the smaller it should look. Mathematically, this just means dividing by depth (ty).

const fov = 90 // Field of view scalar

// Screen X (horizontal position)
// Add screen.width/2 to center it
const screenX = (tx * fov / ty) + (screen.width / 2)

// Screen Y (height)
// Taller walls or closer walls appear larger
const screenHeight = (WALL_HEIGHT * fov / ty)

Translate walls

To draw a wall, we need four points on the screen: Top-Left, Top-Right, Bottom-Left, and Bottom-Right.

function project(x, y, z) {
 // z is height (0 for floor, WALL_HEIGHT for ceiling)
 // ... translation logic ...
 // ... rotation logic ...
 
 // Projection
 const screenX = (tx * fov / ty) + (screen.width / 2)
 const screenY = (z * fov / ty) + (screen.height / 2)
 
 return { x: screenX, y: screenY }
}

We project the two ends of a wall segment to get their screen coordinates, then fill the polygon between them using ctx.beginPath() and ctx.fill().

Sort the walls and finally draw them on canvas

If we just draw walls in any order, distant walls might be drawn on top of close walls. That would look weird, so we first sort the walls based on their distance from the player.

The Painter’s Algorithm: Draw background objects first, then foreground objects over them.

function draw3D() {
 const wallsWithDistance = walls.map(wall => {
 // Calculate distance to player
 const dist1 = dx1*dx1 + dy1*dy1
 const dist2 = dx2*dx2 + dy2*dy2
 
 // ... calculate weighted distance ...
 return { wall, distance: weightedDist }
 })
 
 // Sort far to near
 wallsWithDistance.sort((a, b) => b.distance - a.distance)
 
 // Draw
 wallsWithDistance.forEach(item => drawWall(item.wall))
}

Why the Weighted Distance?

Simple closest-point distance can fail for angled walls. The weighted average considers the closest point (most important for occlusion), the midpoint, and the farthest point to handle edge cases gracefully.

Clipping: Dealing with Edge Cases

The Problem: Behind the Camera

When a wall is partially behind the player, the math breaks! Computing screenX = tx * fov / ty when ty is negative or zero creates division by zero or negative numbers, resulting in visual glitches.

Near-Plane Clipping

We define a near plane – a minimum distance. Anything closer gets clipped.

const NEAR_PLANE = 1

// If endpoint is behind us, move it to the near plane
if (cy1 < NEAR_PLANE) {
 const t = (NEAR_PLANE - cy1) / (cy2 - cy1) // Interpolation factor
 cx1 = cx1 + t * (cx2 - cx1) // New X at near plane
 cy1 = NEAR_PLANE // Clamp to near plane
}

Screen-Space Clipping

Walls extending off-screen are also clipped to prevent wasted drawing.

// Clip to left edge (x = 0)
if (sx1 < 0) {
 const t = (0 - sx1) / (sx2 - sx1)
 wallTop1 = wallTop1 + t * (wallTop2 - wallTop1)
 wallBot1 = wallBot1 + t * (wallBot2 - wallBot1)
 sx1 = 0
}

Movement & Controls

WASD Movement

Movement is relative to where the player is looking.

function movePlayer() {
 // Forward direction based on angle
 const dx = -Math.sin(DEG_TO_RAD[Player.angle]) * MOVE_SPEED
 const dy = Math.cos(DEG_TO_RAD[Player.angle]) * MOVE_SPEED
 
 // ... apply movement based on keys ...
 
 // Normalize diagonal movement for consistent speed
 const magnitude = Math.sqrt(moveX**2 + moveY**2)
 if (magnitude > 0) {
 moveX = (moveX / magnitude) * MOVE_SPEED
 moveY = (moveY / magnitude) * MOVE_SPEED
 }
}

Mouse Look with Pointer Lock

For immersive FPS-style controls, we lock the mouse cursor. Pointer lock hides the cursor and provides raw mouse movement data.

document.addEventListener("mousemove", (event) => {
 if (!isMouseLocked) return
 
 const mouseMove = event.movementX
 const degreeChange = mouseMove / screen.width * 360
 
 Player.angle -= degreeChange
})

Wall Collision Detection

Grid-Based Collision

Since our world is grid-based, collision is simple. Just check if the players future calculated position is a wall and conditionally allow movement.

function isWall(worldX, worldY) {
 const tileX = Math.floor(worldX / TILE_SIZE)
 const tileY = Math.floor(worldY / TILE_SIZE)
 return getMapTile(tileX, tileY) === 1 // 1 is a wall in our implementation
}

We also give the player a radius and check all corners to ensure the player doesn’t clip into walls. If directly blocked, we try sliding along the wall. This creates smooth movement even when running into walls at angles.

Putting It All Together

Every frame, we simply clear the screen, handle input, render the walls, and debug if needed.

function loop() {
 clearScreen() // Draw floor and ceiling
 movePlayer() // Handle input
 draw3D() // Render walls
 debug() // Show debug info
}

// Run at 30 FPS
setInterval(loop, 1000 / 30)

What Next?

The engine we built covers the fundamentals, but classic DOOM had much more: texture mapping, sprites, variable height sectors for different floor/ceiling heights, lighting, enemy AI, sound, guns, an actual game!

Feel free to extend this engine to add more features! <3

References

Publish to NPM from GitHub Actions using OIDC

ankush4singh@gmail.com (Ankush Singh) — Tue, 09 Dec 2025 00:00:00 +0000

I frequently create developer tools and publish node packages on npmjs, but recently classic tokens got deprecated, granular tokens are limited to 90 days, require 2FA and a bunch of changes were introduced to improve security around publishing packages. More about that on this GitHub announcement.

One of the improvements was the introduction of OpenID Connect (OIDC), which allows developers to publish npm packages through GitHub Actions, without having to setup any kind of API key or access token.

Today we’re having a look at how you can implement it for your packages as well.

Step 1: Setup a Node Package (or skip if you already have one)

As an example, we’ll create a fresh package which just logs “hello world” to console.

mkdir npm-oidc-demo && cd npm-oidc-demo
npm init -y
touch index.js

index.js:

export function helloWorld() {
 console.log("Hello World");
}

package.json:

{
 "name": "npm-oidc-demo",
 "version": "1.0.1",
 "description": "A simple hello world package",
 "main": "index.js",
 "type": "module",
 "exports": {
 ".": "./index.js"
 },
 "repository": {
 "type": "git",
 "url": "https://github.com/ankushKun/npm-oidc-demo"
 },
 "keywords": [
 "npm",
 "oidc"
 ],
 "author": "",
 "license": "ISC"
}

Run npm login and follow the steps to link the npm CLI with your npmjs account. When successful, run npm whoami and it should print your username.

Ready for publishing:

If you ignored the previous note and still followed this guide to publish the demo package yourself, you might need to change your package name as I have already used “npm-oidc-demo”

$ npm whoami
ankushkun

$ npm publish
npm notice 
npm notice 📦 npm-oidc-demo@1.0.0
...
+ npm-oidc-demo@1.0.0

The package is now available at https://www.npmjs.com/package/npm-oidc-demo.

Step 2: Update OIDC Details on Package Settings

Head over to the settings tab on your freshly published package and select GitHub Actions as the trusted publisher.

I have already created a GitHub repo at ankushKun/npm-oidc-demo, now we just need to create a workflow file. Put this inside .github/workflows/publish.yml:

publish.yml:

name: Publish to npm

on:
 release:
 types: [published]
 workflow_dispatch:

jobs:
 publish:
 runs-on: ubuntu-latest
 permissions:
 contents: read
 id-token: write
 steps:
 - uses: actions/checkout@v4

 - uses: actions/setup-node@v4
 with:
 node-version: "20.x"
 registry-url: "https://registry.npmjs.org"

 - name: Update npm
 run: npm install -g npm@latest

 - name: Publish to npm
 run: npm publish

Push the YAML file to the repo and update the OIDC details on the package settings. I have kept the environment name empty because I don’t have any explicit environment setup for actions.

update and save the settings.

Now when you create a new release on the github repo, a workflow will start running which will publish the package to npm with provenance.

Step 3: Create a Release on GitHub to Run the Action

Now it’s time to trigger the workflow! Go back to the github repo and create a new release.

Once created, the GitHub Action will automatically start running. You can monitor the progress in the Actions tab of your repository.

When the workflow completes successfully, your package will be published to npm with provenance — proving it was built and published through your trusted CI/CD pipeline!

And that’s how one can setup cicd to publish npm packages from github actions without having to create any access tokens themselves!

A Noob's Guide to Web APIs

ankush4singh@gmail.com (Ankush Singh) — Wed, 19 Feb 2025 00:00:00 +0000

Alllll riiiight lets do this one more time, my name is Ankush and I’m your friendly neighbourhood web developer, here to educate your pathetic ass a bit about web APIs, how they can be used to connect your frontend with your backend and how you can write an API using NodeJS 🫡

An API — Application Programming Interface, defines how different applications can talk to each other and exchange data through structured requests and responses.

API Types

Web APIs — the one we will be focusing on today
OS APIs — Windows APIs, Android APIs, etc
Library APIs — Like a python library
Hardware APIs — allow accessing hardware functions (embedded libraries?)

RESTful Web APIs

A RESTful Web API is one that follows the “REST” (Representational State Transfer) principles, a software architecture style that ensures scalability, simplicity, and stateless communication between servers and clients.

Common REST HTTP Methods

There are 4 common methods/requests to call REST APIs:

GET — to get some data from the server
POST — to send/create some data from the server and get a response
PUT — to update existing data on a server
DELETE — to remove some data from a server

When browsing the web, a GET request is used to fetch the client-side content that gets rendered by the browser.

API Response Codes

Whenever an API is called, it will always return a status code (a number) to signify the result of the request.

1XX: Informational response
2XX: Success codes (e.g., 200 — OK)
3XX: Redirects (e.g., 301 — Moved Permanently)
4XX: Client errors (e.g., 400 — Bad Request, 401 — Unauthorised, 404 — Not Found)
5XX: Server errors (e.g., 500 — Internal Server Error)

Let’s Write an API Endpoint Ourselves

Make sure you have NodeJS + NPM already installed and follow these steps:

mkdir api-test
cd api-test
npm init -y
npm i express
touch index.js

This will create a folder for our express API backend and create a JS file to write code in. Edit the index.js file and add this code:

const express = require('express');
const app = express();

app.get('/', (req, res) => {
 res.send('Hello World');
});

app.listen(3000, () => {
 console.log('Server is running on port 3000');
});

We have just initialised an express backend which is serving the “Hello World” string at the root (/) endpoint. i.e. on sending a GET request to /, “Hello World” will be returned.

Run this file with:

node index.js

And open http://localhost:3000/ on any browser. It should show “Hello World”.

Try changing the string in res.send('this one') to simple HTML like <h1>Hi there</h1> and restart the express server (ctrl+c and node index.js again), check if something changes on the served page.

Defining a POST Endpoint

But this is just for GET requests, we cannot make POST requests to this endpoint.

As you can see it gives an error if we try to make a POST request to the GET endpoint we created. Let’s define a POST endpoint now. Add this after defining the app:

app.use(express.json());

// POST endpoint
app.post('/', (req, res) => {
 const name = req.body.name;
 res.send(`Hello ${name}!`);
});

Restart the app and let’s try sending a post request to the server. You can use any HTTP client like Thunder Client on VSCode or Postman. I am going to use cURL coz simple:

curl http://localhost:3000/ -d '{ "name": "Ankush" }' -H "Content-Type: application/json"

This should print the response as:

Hello Ankush!

BOOM! You just created a GET and POST request! A majority of web APIs are comprised of just GET and POST requests.

Time to Write Some Frontend

Now let’s serve an HTML page that interacts with our POST endpoint:

<html>
 <body>
 <input type="text" id="name" name="name" placeholder="Enter your name">
 <button onclick="handleSubmit()">Submit</button>
 <script>
 async function handleSubmit() {
 const name = document.getElementById('name').value;
 const response = await fetch('/', {
 method: 'POST',
 headers: {
 'Content-Type': 'application/json'
 },
 body: JSON.stringify({ name })
 });
 const data = await response.text();
 document.body.innerHTML = data;
 }
 </script>
 </body>
</html>

We will serve this HTML through the GET endpoint we created earlier:

app.get('/', (req, res) => {
 res.send(`
 <html>
 <body>
 <input type="text" id="name" name="name" placeholder="Enter your name">
 <button onclick="handleSubmit()">Submit</button>
 <script>
 async function handleSubmit() {
 const name = document.getElementById('name').value;
 const response = await fetch('/', {
 method: 'POST',
 headers: {
 'Content-Type': 'application/json'
 },
 body: JSON.stringify({ name })
 });
 const data = await response.text();
 document.body.innerHTML = data;
 }
 </script>
 </body>
 </html>
 `);
});

Restart the express app and refresh localhost:3000, and try entering your name.

Now if you open developer tools and go into the network tab, you can see the POST request being sent and the different data associated with it.

And that’s a wrap! You’ve just learned the basics of web APIs, REST principles, and created your own simple API with both GET and POST endpoints. Now go build something cool! 🚀

Automating Mandelbrot Fractal generation with SYCL Programming

ankush4singh@gmail.com (Ankush Singh) — Thu, 30 Mar 2023 00:00:00 +0000

What’s this about?

I had recently attended a workshop by Intel on their oneAPI programming model which was conducted by Abhishek Nandy at IIT Roorkee during the Cognizance 2023. I attended this workshop with my friend, Krish Agrawal, who is also the co-author of this blog.
The workshop was held for 2 days in which Nandy Sir on the first day told about this new model by Intel and how to get started with its implementation with the help of JupyterLab. Before ending the day, we were told that there will be a hackathon where he will take implementations of the this new model by all the students in the form of teams as to how we use Intel oneAPI in real-life projects.

SYCL (/sɪkl/) is a programming model for high-performance computing that allows developers to write code for heterogeneous systems that use accelerators such as GPUs, FPGAs, and other specialised processing units. It is an open standard developed by the Khronos Group, an industry consortium that also develops other widely used graphics and compute APIs such as OpenGL and Vulkan. SYCL code can be executed on a variety of devices, including CPUs, GPUs, and FPGAs, without modification.

Fractals are fascinating geometric shapes that repeat themselves infinitely on different scales. They are created through a process of repeating a simple mathematical equation or algorithm to form increasingly intricate patterns. These fractal shapes are naturally occurring and can be observed in many aspects of nature, such as the patterns of a fern leaf, the coastlines of continents, and even the formation of clouds. One of the most well-known and captivating fractals is the Mandelbrot fractal. This type of fractal is generated through an iterative process using complex numbers, resulting in a shape that is renowned for its intricate detail and infinite complexity. It’s a true marvel of mathematics!

Now that we know what our project revolves around, let’s see its implementation in JupyterLab.

Getting started on DevCloud

DevCloud is sandbox that intel provides to learn and try out their oneAPI ecosystem. We will be using the devcloud jupyter lab to run our SYCL fractal generation project. It is way easier and quicker to run SYCL projects on the sandbox than on your local machine.

So head over to devcloud.intel.com/oneapi (archived snapshot, the DevCloud site is no longer online) and create an account. Navigate to the ‘Getting Started’ tab, scroll down to ‘Connect with JupyterLab’ and Launch a JupyterLab instance. It might take some time or get loaded instantly depending on the server load so have some patience.

Once launched, you will find a bunch of folders in the file explorer, including a mandelbrot folder.

Open the Terminal from the landing page, cd into the mandelbrot directory and run the build script.

cd mandelbrot
chmod +x build.sh
./build.sh

This will compile and run the project and create a mandelbrot.png file inside the build folder. As you can see the image is 1024x1024 pixels and it took just 190 milliseconds to generate the image (serial time + parallel time). If we were to do the same in python or regular C++ without SYCL, it would take seconds to generate the same result. So that’s the power of SYCL.

If you checkout the src/mandel.hpp file, you can find 4 variables row and column size, max iterations and repetitions. We can modify these values to generate Mandelbrot sets of different resolutions and qualities.

Try changing these values and see how much time it takes for the images of different configurations to generate.

Automate it

Let’s now write a bash script that automatically changes the values in the C++ file and builds the project.

Create a file autogen.sh and inside it write the following lines.

#!/bin/bash

PASSES=(10 100 500 1000 5000)
SIZES=(1024 2048 4096 8192 16384)

EDIT_FILE="src/mandel.hpp"
BUILD_FILE="build.sh"

prev_size=100
prev_pass=100
let count=0

The variable PASSES contains a list of iterations that will be used in each image of the image generated and sizes contains the list of resolutions for the images in pixels. prev_size and prev_pass is a placeholder that we will use later. count is the number of images generated.

for SIZE in ${SIZES[@]}; do
 for PASS in ${PASSES[@]}; do
 echo ""
 echo "Generating fractal for $SIZE x $SIZE with $PASS passes"
 echo ""

 ...

 done
done

We create a nested loop for the values of SIZES and PASSES, so we can have all the combinations of sizes and passes to generate the images with. In the body of the loop we print a message to display to the user.

In order to edit the values of the 3 variables in the mandel.hpp file we will use the sed command.

sed -ie "s/row_size=$prev_size/row_size=$SIZE/g" $EDIT_FILE
sed -ie "s/col_size=$prev_size/col_size=$SIZE/g" $EDIT_FILE
sed -ie "s/max_iterations=$prev_pass/max_iterations=$PASS/g" $EDIT_FILE
sed -ie "s/repetitions=$prev_pass/repetitions=$PASS/g" $EDIT_FILE

prev_size=$SIZE
prev_pass=$PASS
count=$((count+1))

This uses find and replace to replace the previous values of the variables with new values and updates the count in each iteration of the bash loop.

To run the build command we simply do

./$BUILD_FILE

echo ""
echo "Generated for $SIZE x $SIZE with $PASS passes"
echo ""

The project is built and image is saved in the build folder, so we will have to copy it from there into a location of our choice. Create a folder images in the mandelbrot folder and add the following copy command to the autogen.sh script

cp "./build/mandelbrot.png" "./images/$count.mandelbrot_${SIZE}_${PASS}.png"

This copies the image from build into images folder and also renames it to contain useful information such as size and number of passes and the count.

Run the autogen script and let the fractals be created!

chmod +x autogen.sh
./autogen.sh

After the script is done, you will find the images in the images folder.

Here is the full autogen script

#!/bin/bash

PASSES=(10 100 500 1000 5000)
SIZES=(1024 2048 4096 8192 16384)

EDIT_FILE="src/mandel.hpp"
BUILD_FILE="build.sh"

prev_size=100
prev_pass=100
let count=0

for SIZE in ${SIZES[@]}; do
 for PASS in ${PASSES[@]}; do
 echo ""
 echo "Generating fractal for $SIZE x $SIZE with $PASS passes"
 echo ""
 sed -ie "s/row_size=$prev_size/row_size=$SIZE/g" $EDIT_FILE
 sed -ie "s/col_size=$prev_size/col_size=$SIZE/g" $EDIT_FILE
 sed -ie "s/max_iterations=$prev_pass/max_iterations=$PASS/g" $EDIT_FILE
 sed -ie "s/repetitions=$prev_pass/repetitions=$PASS/g" $EDIT_FILE

 prev_size=$SIZE
 prev_pass=$PASS
 count=$((count+1))

 ./$BUILD_FILE

 echo ""
 echo "Generated for $SIZE x $SIZE with $PASS passes"
 echo ""

 cp "./build/mandelbrot.png" "./images/$count.mandelbrot_${SIZE}_${PASS}.png"
 
 done
done

More iterations means better quality of the image, you can zoom in and see the small details and tiny fractal repetitions, but to see these clearly the resolution must be increased.

The winning moment

It was Day 2 and we both had absolutely nothing with us. We sat at the back thinking what we would present the crowd with. We had about 3 hours in our hands to build something. While brainstorming, we were randomly playing with the Mandelbrot directory already given by Intel in their Virtual Private Server. We ran the code with the proper command and was later told to rerun using qbus -I which redirected us to another portal maybe through some kind of routing. We then decided to create a bash script to randomise four values in the original program i.e. row_size, column_size, max_iterations and repetitions. We were able to do this and now we had started generating images in a folder. Some images with higher resolution or more repetitions took more time than the rest. The longest time was taken by 16K resolution image with 1000 repetitions which took approximately 50 minutes (probably still wayy less than an average C++ or Python script generating the same iterations and resolution).

We demoed our solution on a presentation made on Keynote. We remarkably remember that we were the only team with the minimal interaction with Nandy Sir and also the only ones to receive a round of applause from him. At the end of all prizes, 6 stood out of 13 and were congratulated on stage for the same. Then came the cash prizes for the Top 3. As soon as second was done, we thought the claps were consolatory of nature and we were already packing. But then we realised, we were indeed 1st. (Out of excitement, I smacked the Krish’s Macbook Pro, like Davie504 would slap bass 😂). In the end we received 12K INR as a prize in the form of Amazon Vouchers.

Blog — Ankush Kun

How to switch Claude Code accounts without losing your conversation

Where does Claude Code store your login?

Why not /login or CLAUDE_CONFIG_DIR?

Version one: two shell functions

How oof switches accounts

Saving logins automatically with Claude Code hooks

Making it pleasant

Is it safe with several sessions open?

Install oof

A note on limits

Wrapping up

Clef beat Jev on Jev's home turf

What are Clef and Clef-flash?

How we benchmarked Clef against Jev

Clef vs Jev accuracy: the results

Is Clef deterministic?

Jev’s scores moved under the same version name

Entity matching: where the three models differ most

Thresholds do not transfer between decision models

How fast is Clef? What we could and could not measure

What does Clef cost compared with Jev?

Clef vs Jev: which decision model should you use?

What we are switching, and why Cloudflare makes it easy

How to try Clef

What this benchmark does not show

Where Construct fits

We put Jev inside our AI employee

What is Jev?

Using Jev for AI agent memory

How fast is Jev in production?

How we picked the 0.7 threshold

Use the probability, not the top answer

Is Jev’s confidence calibrated?

What Jev gets wrong

Where Jev fits in an AI agent: System 1 and System 2

What does Jev cost compared with an LLM?

How we are adding more Jev decisions

How to try Jev

What most Jev coverage gets wrong

Where Construct fits

Nobody merges an email

The bottleneck moved and the tooling stayed put

Why software absorbed the flood anyway

The check has to be cheaper than the doing

Nobody is measuring this, including you

Five things that make agent work checkable

Artifacts, not transcripts

A draft state before anything irreversible

Provenance on anything the agent believes

A bounded record of what it touched

Reversibility where it exists, a human where it does not

How Construct is built around the check

The next 10x is not in the model

Your agent has a half-life

Why your agent keeps failing on long tasks

Why multi-step agent workflows fail: 48 steps, 8.5% success

Will a better model fix agent reliability?

How to fix an agent that fails partway: cut the job at the seams

How Construct runs the same job

A checklist for building a resumable agent job

What checkpointing does not fix

Ask this instead of “which model should I use”

All our Agents get computers, we pay for almost none

The bill that scaled with people who never came back

Only half a computer deserves to be awake

Linux shows up, edges the job, and leaves

She wrangler on my D1 till I R2

What living on the edge actually costs

What we run today

How to Choose an AI Agent Platform for Your Team

Why most AI agent pilots never reach production

The AI agent evaluation checklist: 6 criteria that separate a pilot from a platform

Tool orchestration and execution surfaces (browser, terminal, files, connected apps)

Human-in-the-loop controls and approval gates

Audit trails and inspectable activity (and what “audit trail” should actually mean)

Connector coverage and custom integrations via MCP

Persistent, correctable memory across sessions

Pricing model and real usage limits, not just a price tag

Governance pressure is raising the bar: EU AI Act and “agent washing”