Forem: Solvo Dev Notes

My AI agent can't click "Sign up for an API key" — so I built a business-day endpoint with no signup

Solvo Dev Notes — Sun, 17 May 2026 05:08:27 +0000

I've been running an autonomous coding agent for a while now. It writes code, opens PRs, and occasionally needs to compute things like "what's the SLA deadline if a ticket lands today and we promise resolution in 5 business days?"

Two problems showed up immediately, and they're the reason this post exists.

Problem 1: LLMs are genuinely bad at date arithmetic

This isn't a hot take, it's measurable. A 2025 arXiv study ("Lost in Time: Clock and Calendar Understanding Challenges in Multimodal LLMs") found that models do okay on popular holidays — likely because the answer is memorized — but accuracy "diminishes substantially for lesser-known or arithmetically demanding queries (e.g., 153rd day), indicating that performance does not transfer well to offset-based reasoning."

That matches what I see in practice. Ask a model "add 5 business days to 2026-05-15, skipping weekends" and you'll get a confident, plausible, and frequently off-by-one answer. Business-day math is exactly the kind of deterministic, rule-based calculation where "close enough" is just wrong: weekends, observed-holiday shifting, and counting conventions all compound. The well-known fix is to stop asking the model to be a calculator and hand the calculation to a deterministic tool.

Problem 2: every deterministic tool wants me to sign up first

So I went looking for a hosted business-day API. They exist and several are good. But here's the wall my agent hit:

API Ninjas Working Days — requires an account and an X-Api-Key header on every request.
workingdays.org — requires an account; runs on a monthly quota with profiles.
timeanddate.com Business Days Calculator — no permanent free tier; access starts at $299, or a 3-month trial.

To be fair: most of these do offer a usable free tier. The blocker isn't the price. The blocker is that every one of them requires creating an account and provisioning a key before the first request will succeed. A human does that in two minutes. An autonomous agent cannot — there's no inbox to confirm, no dashboard to click, no human in the loop. The signup step is where the automation dies.

So I shipped the boring version: OpenWorkdays

OpenWorkdays is a zero-signup, zero-key business-day date API. One anonymous GET, JSON back. MIT, zero-dependency, source on GitHub.

Add business days:

curl "https://openworkdays.vercel.app/api/businessdays?start=2026-05-15&days=5"

Count business days between two dates:

curl "https://openworkdays.vercel.app/api/businessdays?start=2026-05-15&end=2026-05-29"

Is this date a business day?

curl "https://openworkdays.vercel.app/api/businessdays?date=2026-05-16"

One endpoint, three modes (add, diff, is). You can configure the weekend (weekend=sat,sun) and pass your own holiday list (holidays=2026-05-25,2026-07-03).

The honest scope (read this before you adopt it)

I'd rather you not be surprised in production, so plainly:

Date-only, pure UTC arithmetic. No time-of-day, no DST, no timezones. If you need "5 business days from 3pm Berlin time," this is the wrong tool.
No built-in country holiday database. There is no magic country=US. You supply the holidays you care about via holidays=YYYY-MM-DD,.... This is a deliberate trade: it keeps the service stateless and free of a holiday-data dependency, but it means you own the holiday calendar.
Best-effort, per-instance rate limit. It's free and unauthenticated; don't build a billing system on it without a fallback.

For the common agent/backend case — "skip weekends and these N holidays I already know about" — that scope is exactly enough, and the determinism is the whole point.

For LLM clients: there's an MCP server too

If your agent speaks Model Context Protocol, you can skip HTTP plumbing entirely. There's a remote MCP server (Streamable HTTP, stateless JSON-RPC 2.0, one businessdays tool), also zero-signup:

{
  "mcpServers": {
    "openworkdays": {
      "url": "https://openworkdays.vercel.app/api/mcp"
    }
  }
}

Drop that into Claude Desktop or Cursor and the model can call business-day math instead of guessing at it.

Why this is the right shape

The general principle: if a task is deterministic and the model is unreliable at it, delegate to a deterministic tool. The under-discussed corollary is that the tool also has to be reachable by the agent. An API behind a signup wall is, from an autonomous agent's perspective, not a tool — it's a tool with a human dependency bolted on.

OpenWorkdays is intentionally small and intentionally honest about its limits. If it saves you one off-by-one SLA bug, it did its job. Feedback and issues welcome on the repo.

No-signup link unfurl for AI agents (an agent can't do a signup)

Solvo Dev Notes — Sun, 17 May 2026 01:54:38 +0000

If you write code that calls links — a bot, a crawler, a RAG ingest job, an autonomous agent — you eventually need the metadata behind a URL: title, description, preview image, site name. The annoying part isn't parsing Open Graph tags. It's that almost every managed API that does this for you wants you to sign up first.

That requirement is fine for a human. It is a wall for an agent. An autonomous script has no inbox to confirm, no dashboard to click, no card to enter. "Just grab an API key" is a step a human does once and an agent cannot do at all.

OpenUnfurl is a small answer to that specific problem: a public link-unfurl endpoint with no account, no API key, one GET.

The endpoint

curl "https://openunfurl.vercel.app/api/unfurl?url=https://github.com"

Returns clean JSON:

{
  "url": "https://github.com",
  "resolvedUrl": "https://github.com/",
  "title": "GitHub · Change is constant. GitHub keeps you ahead.",
  "description": "Join the world's most widely adopted, AI-powered developer platform...",
  "image": "https://images.ctfassets.net/.../GH-Homepage-Universe-img.png",
  "siteName": "GitHub",
  "type": "object",
  "favicon": "https://github.githubassets.com/favicons/favicon.png",
  "oembed": null,
  "fetchedAt": "2026-05-17T01:53:00.977Z"
}

From JS:

const r = await fetch(
  `https://openunfurl.vercel.app/api/unfurl?url=${encodeURIComponent(target)}`
);
const meta = await r.json();
// meta.title, meta.description, meta.image, meta.siteName, meta.favicon

That's the whole integration. No SDK, no env var, no onboarding.

Why a hosted unfurl instead of feeding raw HTML to the model

A reasonable objection: agents already have web access — why not let the LLM read the page itself?

Because raw HTML is an expensive way to find four fields. The pattern people keep landing on in 2026 is the "token tax": an average page is ~200KB of HTML wrapping ~10KB of actual text, so dumping the DOM into a context window means paying premium per-token rates to process navigation, inline styles, cookie banners, and tracking scripts. Reported numbers are not small — clean structured output instead of raw HTML cuts extraction token usage on the order of 60% and up, and removing the markup noise also reduces misreads and hallucinated fields. There is a real trade-off worth stating plainly: for simple static pages, a lightweight purpose-built parser is cheaper and more predictable than an LLM-based extraction step. OpenUnfurl is exactly that lightweight parser — it does the metadata extraction server-side and hands your agent four clean fields instead of a page of soup.

It's also a remote MCP server

If your agent speaks Model Context Protocol, you don't need the REST shape at all. There's a remote MCP endpoint at the same origin, Streamable HTTP, stateless JSON-RPC 2.0:

{
  "mcpServers": {
    "openunfurl": {
      "url": "https://openunfurl.vercel.app/api/mcp"
    }
  }
}

One tool, unfurl, input {"url":"..."}. Smoke test it with a single call:

curl -s -X POST https://openunfurl.vercel.app/api/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"unfurl","arguments":{"url":"https://example.com"}}}'

This shape is deliberate. Streamable HTTP is the current MCP transport standard (HTTP+SSE was deprecated in mid-2025), it's stateless so it runs fine on scale-to-zero serverless, and clients like Claude can connect to authless remote servers without an OAuth dance. No key here either — same reason as the REST endpoint.

Honest limitations

This is v0.1 and the scope is narrow on purpose:

Static HTML only. It fetches and parses the HTML the server returns. No headless browser, no JS execution. A client-rendered SPA that ships an empty <body> and paints metadata with JavaScript will come back thin or empty. That's a known gap, not a bug being hidden.
Best-effort rate limiting. Per-instance, per-IP, best-effort. Not a contractual quota. Don't point a firehose at it.
SSRF-guarded. It refuses internal/private address targets. Public URLs only.

If you need full headless render parity, the funded incumbents (Microlink, OpenGraph.io, and similar) do that well — and most of them gate the usable free tier behind a signup or an API key. OpenUnfurl is not trying to beat them on render fidelity. The seam it's filling is different: no signup, instant, agent-native, for the static-HTML majority of links.

Source

Zero-dependency Node serverless, MIT licensed: https://github.com/SolvoHQ/openunfurl

Both surfaces are live now — the curl above works as you read this. If your agent needs link metadata and you don't want to teach it to sign up for something, point it at the endpoint and move on.

AbortController: the cancellation bugs most JavaScript devs ship

Solvo Dev Notes — Sat, 16 May 2026 07:54:17 +0000

AbortController has been in every browser and Node release that matters for years now, and most code I review still gets it subtly wrong. Not "doesn't work" wrong — "works until it doesn't" wrong: ghost requests overwriting fresh state, timeouts that can't be told apart from user cancels, AbortError logged as if the sky fell, leaked listeners that never fire.

None of these throw in the demo. They surface in production under a flaky network and a fast-clicking user. Here are the patterns that actually hold up, with the 2026 API surface.

1. Cancelling fetch — and why `AbortError` is not an error

The mechanics are easy. The mistake is what you do in catch.

const controller = new AbortController();

try {
  const res = await fetch('/api/search?q=hello', { signal: controller.signal });
  const data = await res.json();
  render(data);
} catch (err) {
  if (err.name === 'AbortError') return; // not a failure — we caused it
  throw err;                              // a real failure — surface it
}

// elsewhere, e.g. the user typed another character:
controller.abort();

The single most common bug: a blanket catch that pipes every rejection into your error UI. When you abort an in-flight fetch, the promise rejects. If you don't special-case that rejection, cancelling a request renders an error toast for an action the user deliberately took. Abort is a normal control-flow outcome, not an exception condition.

Two precision points people get wrong:

controller.abort() with no argument rejects fetch with a DOMException whose name is "AbortError". That's the case the snippet above handles.
controller.abort(reason) rejects fetch with that reason instead. If you pass abort(new Error('user navigated')), your err.name === 'AbortError' check won't match and you'll re-throw it. If you use custom reasons, branch on controller.signal.aborted / inspect signal.reason, don't pattern-match the name.

A controller is single-use. Once abort() has been called, the signal is permanently aborted ("sticky") — handing that same signal to a new fetch aborts it immediately. One operation, one fresh AbortController.

2. `AbortSignal.timeout()` instead of the setTimeout dance

The hand-rolled version is everywhere and it leaks:

// Don't do this
const controller = new AbortController();
const t = setTimeout(() => controller.abort(), 5000);
try {
  const res = await fetch(url, { signal: controller.signal });
  // BUG: if the fetch resolves in 200ms, this timer still fires 4.8s later
} finally {
  clearTimeout(t); // easy to forget; without it the timer keeps a ref alive
}

Use the built-in:

const res = await fetch(url, { signal: AbortSignal.timeout(5000) });

AbortSignal.timeout(ms) returns a signal that aborts itself after ms. No timer handle to clean up, nothing to forget. Two properties worth knowing:

It aborts with a DOMException named "TimeoutError", not "AbortError". This is a feature: you can finally tell "the server was too slow" apart from "the user hit cancel" in one catch.
The clock is active time, not wall-clock. It pauses while the document is in the back/forward cache or a worker is suspended, so a backgrounded tab won't spuriously time out the moment it's restored.

try {
  const res = await fetch(url, { signal: AbortSignal.timeout(5000) });
  return await res.json();
} catch (err) {
  if (err.name === 'TimeoutError') return showRetry();   // slow server
  if (err.name === 'AbortError')   return;                // user cancelled
  throw err;
}

3. `AbortSignal.any()` — timeout and user-cancel, correctly

The real-world requirement is almost always "abort if the user cancels or if it takes too long." People reach for nested controllers and a setTimeout. Don't. Compose:

function load(url, { signal } = {}) {
  const signals = [AbortSignal.timeout(8000)];
  if (signal) signals.push(signal);          // caller's user-cancel signal
  return fetch(url, { signal: AbortSignal.any(signals) });
}

AbortSignal.any([...signals]) returns a signal that aborts as soon as any input aborts. signal.reason is set to the reason of whichever one fired first — so you can still distinguish a TimeoutError from a user AbortError after combining:

try {
  const res = await load(url, { signal: userCancel.signal });
} catch (err) {
  if (err.name === 'TimeoutError') { /* it was the 8s timeout */ }
  if (err.name === 'AbortError')   { /* it was the user */ }
}

Two sharp edges:

If any input signal is already aborted when you call AbortSignal.any(), the combined signal comes back already aborted. That's correct behavior, but it means you must build the combined signal per attempt, not once and reuse it — same single-use rule as a controller.
On Node, AbortSignal.any() had a history of memory leaks when a long-lived signal accumulated many short-lived dependents (nodejs/node #54614, #57584); fixes landed progressively through the v26.x line. The practical guidance hasn't changed: keep the composed signal scoped to one operation and let it get collected, rather than wiring thousands of per-request signals into one process-lifetime parent.

4. The React `useEffect` + StrictMode trap

This is where most people actually meet AbortController, and where the bug is the most expensive because it looks like it works.

useEffect(() => {
  const controller = new AbortController();

  fetch(`/api/users/${userId}`, { signal: controller.signal })
    .then(r => r.json())
    .then(setUser)
    .catch(err => {
      if (err.name !== 'AbortError') setError(err);
    });

  return () => controller.abort();   // cleanup: cancel the in-flight request
}, [userId]);

Why this exact shape:

Fresh controller inside the effect body. Not in a ref shared across runs, not module scope. Each effect run owns its own controller because an aborted one is dead forever (point 1).
abort() in the cleanup function. When userId changes, React runs cleanup then re-runs the effect. Without the abort, a slow response for the old userId can land after the new one and overwrite correct state with stale data. This is the classic search/autocomplete race, and AbortController is the fix — not a debounce (a debounce only narrows the window).
Filter AbortError before setState. The aborted request rejects; if you don't filter it you'll call setError for a cancellation, and possibly set state on an unmounted component.

On StrictMode in development (React 18 and 19): the effect runs, cleans up, and runs again — on purpose. You'll see the first request show as cancelled (red) in the network panel. That is not a bug to silence; it's StrictMode proving your cleanup works. The React team's position is explicit: this is expected, and the resolution is correct cleanup + a fresh controller per run — exactly the code above. It does not fire twice in production builds. Disabling StrictMode to "fix" it just hides the broken-cleanup class of bugs until production finds them for you.

5. Node: the same signal, far past fetch

AbortSignal is the cancellation currency across Node core, not just HTTP.

Auto-removing event listeners. The signal option on addEventListener (and Node's EventEmitter/EventTarget) removes the listener when the signal aborts. One abort() tears down a whole group of listeners — no bookkeeping, no matching removeEventListener:

const controller = new AbortController();

target.addEventListener('message', onMessage, { signal: controller.signal });
target.addEventListener('error',   onError,   { signal: controller.signal });

controller.abort(); // both listeners gone

Awaitable timers. timers/promises honors a signal, so a delay becomes cancellable:

import { setTimeout as delay } from 'node:timers/promises';

try {
  await delay(10_000, undefined, { signal });
} catch (err) {
  if (err.name === 'AbortError') return; // cancelled before the 10s elapsed
  throw err;
}

Streams. fs.createReadStream(path, { signal }) and the stream iterator helpers (.map, .filter, stream.compose, events.on) all accept a signal and destroy the stream on abort — clean cancellation of a large file transfer instead of letting it run to completion after the client already disconnected.

Cooperative cancellation between awaits. When you write your own async function, the signal can be passed through but nothing checks it for you between steps. signal.throwIfAborted() is the one-liner that does:

async function pipeline(items, { signal }) {
  for (const item of items) {
    signal?.throwIfAborted();      // bail at the boundary if already aborted
    await processOne(item, { signal });
  }
}

It throws signal.reason if aborted and does nothing otherwise — the idiomatic way to add abort checkpoints to a loop without hand-rolling if (signal.aborted) throw ....

Checklist

One AbortController per operation. Signals are sticky and single-use — never reuse one after abort().
In every catch touching cancellable work, ignore the cancellation: if (err.name === 'AbortError') return; — abort is control flow, not an error.
Reach for AbortSignal.timeout(ms) over setTimeout + abort(). It can't leak a timer, and TimeoutError is distinguishable from AbortError.
Combine concerns with AbortSignal.any([...]), built fresh per attempt; read signal.reason to learn which one fired.
In useEffect: fresh controller in the body, abort() in cleanup, filter AbortError before setState. StrictMode's double-run is the test, not the bug.
In Node, pass signal everywhere it's accepted (listeners, timers/promises, streams) and use signal.throwIfAborted() for checkpoints in your own async code.

Get these six right and the entire class of "stale response clobbered fresh state" / "cancel shows an error" / "timer leaked" bugs disappears.

I built an interactive version of every pattern here so you can run them in the browser, abort them mid-flight, and watch exactly what each catch sees: https://solvo-devnotes.vercel.app