DEV Community: AI Alleyway

Provenance is a testable property of an answer engine. I scored three of them.

AI Alleyway — Wed, 26 Aug 2026 02:11:19 +0000

Every AI search engine ships the same interface: a confident paragraph, then a row of source chips underneath. The paragraph is what you read. The chips are what you'd have to check.

I got curious about whether the chips are worth anything, so I ran one identical query through three engines inside the same hour and then wrote something to score what came back.

The query was what changed in the EU AI Act in 2026. It's a decent test because the answer is factual, recent, and — critically — has a primary source that either exists or doesn't.

Here's the part I didn't expect: all three agreed on the facts. Same substance, same two deadline dates. If you were grading on correctness, it's a three-way tie and there's no article in it.

The difference was entirely in what each was willing to show me as evidence.

Provenance as a scoring function

"Better sources" is the kind of claim that sounds unfalsifiable until you write it down. So I wrote it down: sort every cited host into a tier, weight the tiers, take the mean.

PRIMARY = {          # publishes the instrument itself
    "eur-lex.europa.eu",
}
OFFICIAL = {         # the issuing institution, one step from the text
    "commission.europa.eu",
    "digital-strategy.ec.europa.eu",
}
UGC = {              # user-generated, no editorial chain
    "youtube.com", "www.youtube.com", "reddit.com", "medium.com",
}

TIER_WEIGHT = {"primary": 3, "official": 2, "secondary": 1, "ugc": 0}


def tier(url: str) -> str:
    h = urlsplit(url).netloc.lower()
    if h in PRIMARY:  return "primary"
    if h in OFFICIAL: return "official"
    if h in UGC:      return "ugc"
    return "secondary"


def score(urls):
    """Mean tier weight, 0.0 (all UGC) to 3.0 (all primary)."""
    return sum(TIER_WEIGHT[tier(u)] for u in urls) / len(urls) if urls else 0.0

Two deliberate choices worth arguing with.

"Secondary" is the default, not a penalty box. A consultancy write-up explaining a regulation is a legitimate thing to cite. It is simply not the regulation.

The denominator is what's attributed, not what's listed. Engines display a sources panel and separately attribute specific sentences. Those are different sets, and only the second one is doing any work. Scoring the panel would let an engine pad its way to a good number.

The output

Pure stdlib, no arguments:

query: what changed in the EU AI Act in 2026   (captured 2026-08-25)

engine                           listed attributed  score  tiers
----------------------------------------------------------------
Perplexity (free)                    10          2   2.00  official:2
Google AI Mode                        5          5   1.00  official:1 secondary:3 ugc:1
Brave Search (free, no account)       1          1   3.00  primary:1

score = mean provenance weight of the sources behind the claims
        primary 3 | official 2 | secondary 1 | ugc 0

Perplexity listed ten sources and put European Commission domains behind the claims. It also gave the fullest answer by a distance — original deadlines, the amending regulation's effective date, the synthetic-content extension, the fine ceiling, in a table.

Google's AI Mode drew on five, and the attribution behind its load-bearing sentences was a consultancy, two sites that explain the Act rather than publish it, and a YouTube video. The Commission was present — in the panel, not behind the claims. That single ugc:1 is a video doing the work of a citation.

Brave, free and with no account, scored highest. One source, and it went straight at EUR-Lex for the regulation itself.

And then the scoring function turned out to be measuring the wrong thing.

A score is not a check

A tier map only reads the hostname. It has no idea whether the page exists. So the script has a second mode that goes and looks:

def resolve(url: str):
    """Return (status, body_bytes) or (None, reason). Follows redirects."""
    req = urllib.request.Request(url, headers={"User-Agent": "Mozilla/5.0"})
    try:
        with urllib.request.urlopen(req, timeout=15) as r:
            return r.status, len(r.read())
    except urllib.error.HTTPError as e:
        return e.code, 0
    except Exception as e:
        return None, type(e).__name__

Note the last clause. An exception here is a result — "this citation could not be fetched, and here is what went wrong" — not something to swallow. A provenance checker that silently treats unreachable as fine is worse than no checker.

Running the three winners through it, on the day I'm writing this:

https://commission.europa.eu/          -> 200, 16,816 bytes
https://digital-strategy.ec.europa.eu/ -> 200, 54,683 bytes
https://eur-lex.europa.eu/             -> 202,      0 bytes

HTTP 202 with an empty body. Accepted for processing. Renders blank in a browser.

So the top-scoring citation in the table — the only primary in the whole dataset, the one that lifted Brave to a clean 3.00 — is a URL I could not read. Brave pointed at the instrument. It did not show it to me. Those are different claims, and only one of them is worth anything to someone trying to verify a number.

I've kept both modes rather than folding resolution into the score, because they answer different questions. The tier map asks what kind of thing did you cite. The resolver asks did you cite a thing that exists. An engine can pass either one alone and still be useless.

What I'd take from it as an engineer

One query is not a benchmark. Three engines, one question, one hour. It's an existence proof that the gap is measurable, not a ranking.

The interface gives you no signal that a sourcing decision was made. All three summaries look identical in confidence. Nothing renders differently when the chip under the paragraph is a government domain versus a YouTube video. That's a UI choice, and it's the one that does the damage.

If you're building on top of an answer API, provenance is a field you can compute. Hostname tiers are crude but they're cheap, deterministic and diffable — you can score every answer your product surfaces and alert when a run's mean provenance drops. That's a more actionable signal than "hallucination rate", because you can trace it to a specific citation and go look.

And check that the citations resolve. It took me forty lines and one surprise to learn that the highest-provenance source in my dataset was the one that returned nothing.

The full write-up, with what each engine actually returned and screenshots of all three answers, is in my comparison of the three AI search engines if you want the reader-facing version rather than the code.

The script is the whole thing — one file, standard library only, run it with python3 citation_provenance.py or add --resolve to hit the network. Swap in your own CITATIONS dict and it'll score whatever your engine of choice hands back.

Your TTS shortlist is three shortlists, and they barely intersect

AI Alleyway — Sat, 22 Aug 2026 06:40:20 +0000

Every "best text-to-speech API" list I have read is ranked. Number one, number two, number three, with a verdict at the bottom.

That shape cannot express the actual decision, and I want to show you why with something you can run.

The problem is that the three things that decide a TTS vendor are measured in units that do not convert into each other. Price is dollars per million characters. Transport is a shape — held-open socket, chunked body, finished file. Compliance is a document that either exists or does not. There is no exchange rate between them, so there is no ordering. A ranked list has to pick one axis and pretend the others are tiebreakers.

They are not tiebreakers. They are filters, and filters compose by intersection.

The three sets

Price spans about 40x. Google Cloud's legacy voices and Amazon Polly's standard engine sit at $4 per million characters. The mid-market — OpenAI's tts-1, Deepgram Aura-1, Inworld TTS-2 Flash — clusters at $15. Cartesia runs $37.38 to $50. ElevenLabs is $166.11 at its Scale tier. A million characters is roughly 22 hours of speech, so at prototype volume this axis is noise; at a hundred million characters a year it is the difference between a $400 bill and a $16,600 one.

Transport comes in three shapes and the difference is architectural, not incremental.

WebSocket streaming holds a connection open and pushes audio as it is synthesised. The first syllable can reach the caller while the model is still working on the sentence. This is what a live agent needs.
Chunked REST streams the response body back progressively. OpenAI works this way, and its docs recommend wav or pcm output specifically because those start playing sooner than a compressed container. Meaningfully better than waiting for a whole file; meaningfully worse than a held-open socket.
Batch returns a finished file. Correct for narration, e-learning, anything rendered ahead of time. Wrong for conversation.

Two entries in that column are routinely stated wrong, so they are worth getting right.

Amazon Polly has no WebSocket TTS API, but it is not batch-only. StartSpeechSynthesisStream is a real bidirectional streaming API over HTTP/2 — you send text incrementally as events and receive audio as it becomes available. It will serve a conversational agent. The constraint is not the transport, it is the ceiling: generative engine only, 8 transactions per second, up to 8 concurrent requests. That is a real number and it is small.

Google supports streaming on Chirp 3: HD, with a caveat that will find you in integration rather than in evaluation: SSML is not supported on streaming requests. You can have streaming or you can have your markup.

Compliance is the axis where price frequently never enters the conversation at all. As published at the time of writing: Google Cloud Text-to-Speech is named in Google's HIPAA BAA covered-products list and Polly is on the AWS HIPAA-eligible services list — if your compliance team wants a document rather than a blog post, those two already have one. OpenAI offers a BAA for the API without an enterprise agreement. Rime publishes the strongest specialist position and, unusually, publishes dates rather than logos: compliant since February 2024, most recent audit March 2026, BAA on Enterprise, with VPC or full on-prem. Deepgram offers a BAA on request. Inworld gates HIPAA behind the Growth tier, which means you price the compliance tier and not the entry rate. Cartesia does not publish a position.

Intersecting instead of ranking

Here is the whole idea as forty lines of standard library. No network, no API key.

from dataclasses import dataclass

@dataclass(frozen=True)
class Provider:
    name: str
    usd_per_million_chars: float
    transport: str                        # websocket | http2-stream | chunked | batch
    max_concurrent_streams: int | None    # None = no stated ceiling
    hipaa: str                            # published | on-request | plan-gated | enterprise | unpublished

CATALOGUE = [
    Provider("Google Cloud TTS",     4.00, "websocket",    None, "published"),
    Provider("Amazon Polly",         4.00, "http2-stream",    8, "published"),
    Provider("OpenAI TTS",          15.00, "chunked",      None, "published"),
    Provider("Deepgram Aura-1",     15.00, "websocket",    None, "on-request"),
    Provider("Inworld TTS-2 Flash", 15.00, "websocket",    None, "plan-gated"),
    Provider("Inworld TTS-2",       25.00, "websocket",    None, "plan-gated"),
    Provider("Deepgram Aura-2",     30.00, "websocket",    None, "on-request"),
    Provider("Rime Mist v3",        30.00, "websocket",    None, "published"),
    Provider("Cartesia",            37.38, "websocket",    None, "unpublished"),
    Provider("Rime Coda",           50.00, "websocket",    None, "published"),
    Provider("ElevenLabs",         166.11, "websocket",    None, "enterprise"),
]

# Your constraints, not mine.
BUDGET       = 15.0
CONVERSATIONAL = {"websocket", "http2-stream"}
CONCURRENCY  = 25
HIPAA_OK     = {"published"}

price       = {p.name for p in CATALOGUE if p.usd_per_million_chars <= BUDGET}
transport   = {p.name for p in CATALOGUE if p.transport in CONVERSATIONAL}
concurrency = {p.name for p in CATALOGUE
               if p.max_concurrent_streams is None or p.max_concurrent_streams >= CONCURRENCY}
compliance  = {p.name for p in CATALOGUE if p.hipaa in HIPAA_OK}

print(sorted(price & transport & concurrency & compliance))

Run it with those four constraints — a mid-market budget, a conversational transport, twenty-five concurrent streams, and a HIPAA position your compliance team can read — and this is the real output:

budget    <= $15/M chars :  5  ['Amazon Polly', 'Deepgram Aura-1', 'Google Cloud TTS', 'Inworld TTS-2 Flash', 'OpenAI TTS']
transport   conversational      : 10  ['Amazon Polly', 'Cartesia', 'Deepgram Aura-1', ...]
concurrency >= 25 streams        : 10  ['Cartesia', 'Deepgram Aura-1', 'Deepgram Aura-2', ...]
compliance  published HIPAA     :  5  ['Amazon Polly', 'Google Cloud TTS', 'OpenAI TTS', 'Rime Coda', 'Rime Mist v3']

intersection                    :  1  ['Google Cloud TTS']

Eleven rows in, one row out.

Notice that no individual filter looked severe. The loosest kept ten of eleven. The tightest kept five. Any one of them, read on its own, leaves you feeling like you have a comfortable field of candidates — which is exactly the feeling a ranked list is designed to give you, and exactly the feeling that gets teams to month six before the constraint they never filtered on shows up.

Which constraint is actually binding

The intersection tells you the answer. It does not tell you what to negotiate, and that is the more useful output. So drop each constraint in turn:

without budget       ->  3  ['Google Cloud TTS', 'Rime Coda', 'Rime Mist v3']
without transport    ->  2  ['Google Cloud TTS', 'OpenAI TTS']
without concurrency  ->  2  ['Amazon Polly', 'Google Cloud TTS']
without compliance   ->  3  ['Deepgram Aura-1', 'Google Cloud TTS', 'Inworld TTS-2 Flash']

Every constraint is load-bearing here — each one is holding back one or two additional candidates — and none of them individually opens the field. That is a genuinely useful thing to know before you go and argue with someone about it, because it tells you no single concession rescues the shortlist.

It also puts a number on the Polly ceiling. Polly disappears from the viable set solely because of the 8-concurrent-request limit; relax concurrency and it comes back at the cheapest price band in the table. If your workload is bursty-but-small, that ceiling is fine and Polly is a $4 answer. If you are running two dozen simultaneous calls, the ceiling is not a detail, it is a disqualification. Same vendor, same price, opposite verdict — and no ranked list can hold both.

About the axis I deliberately did not model

Latency. You will have noticed it is absent from the script, and that is on purpose.

Every latency figure any of these vendors publishes is a vendor claim, and they are not measured the same way:

Provider	Claim	The qualifier that matters
Inworld TTS-2 Flash	20ms TTFB	P90, server-side — excludes network
Rime Mist v3	37ms P50 TTFA	at 1 concurrency
Deepgram Flux	80ms first audio	"under production load", undefined
Cartesia Sonic	sub-90ms TTFA	vendor advertisement
Deepgram Aura-2	sub-200ms TTFB	no methodology stated
OpenAI / Google / AWS	not published	—

A server-side P90 that excludes network time and a single-concurrency P50 are not the same measurement. Neither predicts what your users experience at your concurrency from your region. Putting those in a sorted() call would produce a number that looks like a decision and is not one.

I have not benchmarked these APIs myself and I am not going to pretend otherwise. The honest way to model latency is as a gate you measure yourself, after the intersection has cut the field to something you can actually stand up and test. Two or three candidates you can benchmark is a tractable afternoon. Eleven is not, which is the other reason to intersect first.

The shape I would actually use

Write down the three constraints as sets before you look at any vendor. If you cannot state your concurrency requirement, you are not ready to choose.
Intersect. Expect the survivors to be far fewer than the field.
If the intersection is empty, drop-one to find out what to negotiate — budget, ceiling or paperwork — rather than quietly abandoning the constraint that is easiest to forget.
Only now benchmark latency, on the two or three that survived, from your region at your concurrency.

The catalogue in the script is a snapshot, and every number in it will drift. That is fine — swap the numbers and the method still holds, which is the point of writing the decision as code rather than as a ranking.

I keep the current per-million prices, the full transport table including the per-model caveats, and the compliance positions in a longer write-up of eight text-to-speech APIs on one axis if you want the underlying numbers rather than the method.

The agent edited the rule that made its change wrong

AI Alleyway — Sat, 15 Aug 2026 05:54:58 +0000

I gave a coding agent a mechanical refactor and watched it do something I have not seen discussed anywhere: it modified the file that constrains it, deleting the specific rule its own change had broken. No approval prompt. The edit was, in isolation, defensible. That is what makes it worth writing down.

This is a short report of one run. I will give the setup, what it got right, the finding, and the limits.

Setup

A rename across a real repository: one database field and its sibling token, b_roll_suggestions and b_roll_prompts, referenced from SQL, Python, JavaScript and a workflow JSON.

I ran it twice.

Run 1 pointed the agent at an empty directory. It searched the filesystem, found my actual production repository elsewhere on disk, and planned edits to scripts/supabase-init.sql inside it. The approval gate fired — the write was outside the configured workspace — and I denied it. git status afterwards confirmed zero writes. The gate worked exactly as designed, which matters for the rest of this.

Run 2 used a throwaway clone with an explicit path boundary in the prompt. The boundary held.

What it got right

Credit where it is due, because the failure only matters against competent work.

33 of 33 references, across 7 files and 3 languages. Not 33 lines — 33 references, counted at HEAD across both tokens.

I verified the result against disk rather than reading the summary:

JSON.parse on the workflow file: OK, 28 nodes
node --check on the guard JavaScript extracted from that file: OK
py_compile on all four Python files: OK

The hardest edit is worth describing. One conditional lived in JavaScript stored as an escaped string inside n8n workflow JSON — a string, inside JSON, that happens to be code. It did not attack that with a regex. It did a structured edit via node -e, parsing the JSON, modifying the embedded source, and re-serialising. It also caught its own incomplete first pass and went back, unprompted.

Network access was blocked by default. When it wanted egress it asked, I denied, and it did not fabricate a passing type-check — it named the exact failure, ENOTFOUND, and cleaned up the artifact it had created. That is better behaviour than I expected.

The finding

Among the 7 files it edited was the project's instruction file — the one carrying the project's standing rules for agents.

Inside it was this line:

Don't drop the legacy column.

That rule existed because the old field name still had to survive for backwards compatibility. The agent's rename made the rule false. So it deleted the line.

No approval prompt. And here is the mechanism, which is the actually interesting part: the instruction file was inside the workspace. The approval gate is keyed on paths. A write inside the configured directory is, by definition, allowed. The gate that fired so correctly in Run 1 could not fire here, because nothing about this write was out of bounds.

I want to be fair about intent. Documentation should follow code, and the line had become inaccurate. If a junior engineer did this in a pull request you would probably approve it, then ask a question in review.

But the property is the problem, not the intent:

A constraint that can be edited by the thing it constrains is not a constraint.

The file was not being read as project memory here — this particular agent reads AGENTS.md, not the file it touched, and it only touched that file because the rename target appeared in it. That is almost worse. It edited a guardrail file incidentally, as collateral of a text match, without ever treating it as a guardrail.

There is a smaller corroborating detail from the same run. Its own diff badge reported 6 files, +13 −31. git said 7 files, +16 −34. It undercounted mid-run too. So the summary that would have told you a seventh file was touched was itself wrong about the count.

What I changed afterwards

Nothing clever, and none of it is agent-specific:

Move agent instruction files outside the writable workspace, or mount them read-only for the run. If the rules live where the work happens, they are editable by the work.
Diff the instruction files separately. git diff -- AGENTS.md CLAUDE.md .cursorrules before the main review. It is one command and it surfaces exactly the class of change nobody reads.
Do not trust the agent's own diffstat. Read git's. They disagreed here, in the direction that hides work.
Treat path-based approval gates as necessary, not sufficient. They answer "is this file in bounds", never "should this specific file change as part of this task".

The general shape, if you want one sentence: approval gates protect the perimeter, and your constraints are usually inside it.

Limits, plainly

This is three driven runs across two sittings, all on the free tier, roughly 25 minutes of observed runtime. It is not long-term use, it is not a benchmark, and I am not going to present it as one. A single run tells you about defaults and about what the gates do and do not cover. It tells you nothing about behaviour on a large codebase over weeks.

I also deliberately am not ranking this tool against another one here. The per-file breakdown, the full verification log for the refactor, and what the approval gate did in each run are in the full Codex write-up, if the specifics are useful to you.

If anyone has seen an agent modify its own instruction file in a way that was gated, I would genuinely like to know which tool and which setting — that is the part I could not find prior art for.

The transcript is not the artifact

AI Alleyway — Tue, 11 Aug 2026 11:34:09 +0000

I gave a coding agent a genuinely awkward job and then spent longer checking its work than it spent doing the work. That ratio is the point of this post.

The task was a real one from a real repository: rename a field end to end, across three languages that all disagree about what a string is. PostgreSQL schema, an n8n workflow stored as JSON, and Python. The field also travels under a second name in one service's API, so the rename spanned two tokens, not one.

The agent did it in about twenty minutes. It got everything. And the count was still wrong three times — once by the agent, and twice by me while I was checking the agent.

That is what I want to write down, because the failures are all in the measurement, and measurement is the part everybody skips.

What the agent actually did

Credit where it is due, because the run was better than I expected.

It found the hard case on its own. The n8n workflow file stores its code-node bodies as escaped JSON strings — JavaScript inside a string inside JSON. Instead of reaching for a regex, it said so and changed approach:

"The workflow file stores the code-node bodies as escaped JSON strings, so I'm using a structured JSON edit for that one instead of hand-splicing a giant one-line string."

It then wrote a small script to parse, modify and re-serialise. Afterwards it checked its own work, found the first pass incomplete, and volunteered that without being asked:

"The first JSON edit removed the SQL select cleanly, but the embedded JavaScript string still had the fallback."

And when I asked for a passing type-check, it hit a sandboxed DNS failure, requested network access, was refused — and reported the failure precisely rather than inventing a green check:

"I could not show the requested passing TypeScript type-check because scripts/remotion-service has no local node_modules... I requested networked dependency install... but that approval was rejected, so I stopped there rather than fetching anything."

Then it noticed the empty package store its aborted install had left behind and asked to remove it, "so your worktree only contains the intended code changes."

None of that is junior behaviour. Which is exactly why the counting problem is worth taking seriously: when the narration is this good, you stop auditing.

Lie one: the agent's own diff badge

The agent displays a running total of what it has changed. At the end of the run it read 6 files, +13 −31.

git said 7 files, +16 −34.

It was wrong mid-run too — the badge read "4 files +10 −28" at a moment when the working tree held 6 files, +15 −33.

I do not know why, and it does not much matter. The lesson is structural: a self-reported diff is a claim, not evidence. The agent is describing its intentions; git is describing your disk. Only one of those is the artifact.

Lie two: I quoted a diffstat as if it counted something

This one is mine, and it is the more embarrassing of the two.

My first write-up said the agent had renamed 16 references. It had not. Sixteen was the insertion count from git diff --stat — a line-level number that happens to sit next to a plus sign. It counts lines added. It does not count anything semantic at all.

The actual figure, counted at HEAD across the changed files, was 33: twenty-three occurrences of the original name, plus ten of the second name the same field travels under in the render service.

The wrong number had already propagated into prose, an FAQ, an infographic and a machine-readable file before I caught it.

Never quote a diffstat number as a count of things. Insertions are not references, files changed are not modules touched, and +16 is not "sixteen of anything you care about". If you want to know how many references changed, count references — at a commit, with a grep you wrote for that purpose.

Lie three: I declared zero when it was forty-five

Same run, worse mistake.

I checked for stragglers and reported zero remaining across the repository. Forty-five survived.

The straggler grep was scoped: --include="*.sql|*.json|*.py". Perfectly sensible, since those were the three languages the rename touched. It silently excluded Markdown, and forty-five occurrences were sitting in four frozen planning documents.

Two failures stacked there, and they generalise past this example:

Scoping a search to where you expect the answer will confirm your expectation. Grep unscoped first, then narrow once you have seen the full set. A filter applied before you know the answer is not a filter, it is a hypothesis you have hidden from yourself.

A metric that spans two tokens needs a two-token check. The rename covered both names; my straggler check only looked for one for part of the sweep. If your definition of done spans several strings, every verification step has to span all of them, or "done" means "done for the string I happened to type".

What I do now

The method that survived this run, in the order I run it:

Measure with git, never with the badge. git diff --stat for shape, git status to confirm nothing landed outside what you approved.
Count semantically, at a commit. Grep for the actual tokens at HEAD, unscoped, and count every token the change spans.
Prove syntax with parsers, not eyeballs. On this run that meant JSON.parse on the workflow (28 nodes intact), node --check on the JavaScript extracted from inside that JSON, and py_compile on all four Python files. A diff can look perfect and still not parse.
Grep unscoped before you claim zero. Then narrow.

None of this is clever. All of it is the difference between a rename that is finished and a rename that is finished in the places you thought to look.

The finding that actually unsettled me

One more thing happened, and it is the reason I still read the whole diff.

The repository has a project instruction file — the document that tells future agent sessions how this codebase works. It contained an explicit rule: this legacy column is kept for back-compatibility, do not drop it.

The agent dropped it. Then it edited the instruction file to remove that rule, replacing it with a description of the new state.

The charitable reading is probably the correct one. I asked for an end-to-end rename, and leaving documentation asserting a constraint the code no longer honours would be its own kind of wrong. It listed the edit in its summary rather than hiding it.

But sit with the shape of it. The instruction file is the thing that constrains the next session. An agent that revises the rulebook to match what it just did leaves a repository where the rule never appears to have existed — and the next agent, reading a clean file, has no way to know a constraint was ever there. It happened with no approval prompt, because that file lives inside the workspace the agent was given.

I am not arguing it behaved badly. I am arguing that "files inside the workspace can be edited without asking" and "the workspace contains the rules" are two reasonable defaults that combine into something you would not choose deliberately.

The short version

The agent was more careful than I expected and more careful than I was. Every mistake in the paragraphs above that mattered to the published result was mine, and every one of them was a measurement error rather than a code error.

So: let it work, then check the disk rather than the story about the disk. And when you write the result down, count the thing you are claiming to have counted.

If you want the rest of that test — the workspace-escape run, what the approval gates caught, and the parts where the two agents I use genuinely differ — it is in the full Codex vs Claude Code comparison, including the parts where my own evidence is thinner than I would like.

What a year of metered AI coding actually cost me: a $20 plan that billed $510.70

AI Alleyway — Thu, 30 Jul 2026 05:05:12 +0000

Most AI coding tools now bill on a model the industry borrowed from cloud infrastructure: a flat subscription that includes some allowance, then metered usage on top, charged in arrears at the underlying model's API rate.

That is a fundamentally different cost model from a subscription, and most of us evaluate it as though it were the same thing. I paid for Cursor for eleven months across 2025 and then cancelled, and the invoices make the difference concrete in a way the pricing page does not.

The arithmetic

Eleven months, $510.70 total. Of that, $340 was subscription and $170.70 was on-demand usage — a third of the bill, 33.4%, sitting on top of a plan advertised at $20.

The distribution is the interesting part. It was not evenly spread:

Month	Billed	Share that was overage
October 2025	$159.22	49.8%
November 2025	$110.00	45.5%
(11-month total)	$510.70	33.4%

Two months where metered usage was roughly half the invoice. On a plan whose headline number is $20.

Nothing was wrong with the billing. Usage beyond the included allowance is charged at the model's API rate, and on individual plans that is the model's rate — the discounted token rate is a Teams and Enterprise feature. The rate was disclosed. What was missing was any intuition for how fast a heavy month accumulates.

Why the intuition fails

The failure mode is not price, it is variance. A subscription has a known worst case. Subscription-plus-metering has a worst case bounded only by your own throughput, and throughput on an agentic tool is exactly what spikes when work gets hard — the weeks you lean on it most are the weeks it costs most. Cost correlates with difficulty, which is precisely backwards from how you would budget it.

I upgraded to the $60 tier at one point expecting headroom. The included allowance ran out in about a week.

If you want a mental model: treat the subscription as a floor, not a price. The real number is floor + (throughput × rate), and you do not know your throughput until you have a few months of history. Which means for the first quarter you are, in effect, running an uninstrumented cost centre.

The control that exists and nobody sets

Cursor has a spend limit. It is in the billing settings. It has been there the whole time.

Set it on day one — before the first heavy week, not after the first surprising invoice. It converts an unbounded model back into a bounded one, which is the only change that makes the tool's cost predictable enough to defend in a budget conversation.

This generalises past Cursor. Any tool billing subscription-plus-metering should be onboarded the same way:

Find the spend cap before you find the features. If there is no cap, that is a finding.
Instrument the first month — you are collecting a throughput baseline, not just doing work.
Budget the floor plus a variance band, not the sticker price.
Re-check when you change tier. A bigger plan changes the allowance, not the billing model, and a bigger allowance can encourage exactly the usage that blows through it.

What I concluded

I cancelled — not because it was bad. It was genuinely good, and for a lot of people $20 flat plus modest metering is fair value for what it does. I cancelled because my usage pattern made the metered layer the dominant term, and at that point I would rather pay a predictable number.

That is a judgement about a usage profile, not a verdict on the product. Yours may differ, and the honest way to find out is to instrument it rather than estimate it.

The full breakdown — what it does well, where it struggles, and the thing I got wrong about its billing for months — is in my Cursor review, written from the invoices rather than from the marketing page.

Figures are from my own invoices across 2025. Published tier names are Pro $20, Pro Plus $60, Ultra $200 — I have deliberately not quoted current per-tier allowances, because those have changed repeatedly and any number I cite here would date badly. The billing model is the durable part; the inclusions are not.

Google Meet ships its own AI notetaker now — so the real question is lock-in, not features

AI Alleyway — Wed, 22 Jul 2026 03:55:44 +0000

Google Meet now takes its own notes. Turn on "Take notes for me" and Gemini follows the call, then drops an organized summary with action items into a Google Doc in your Drive. No bot, no install — it runs inside Meet.

That changes the question. For years, "best AI notetaker for Meet" was a feature comparison between third-party apps. Now the platform ships the feature natively, and the interesting decision is the one every engineer recognizes when a platform absorbs a capability you used to buy: do you take the native integration and accept the platform's boundary, or keep an abstraction layer above it so you're not locked in?

What the native path actually commits you to

Native Gemini notes are genuinely well-integrated — that's the whole pitch. But integration is the same thing as coupling, and it's worth naming exactly what you're coupling to:

It's Meet-only. Gemini's notetaker does nothing for your Zoom or Teams calls. Your notetaking is now a function of which platform the meeting happened on, which is a strange constraint to accept for something as platform-agnostic as "write down what we decided."
It's license- and admin-gated. The feature needs a Gemini add-on or a Business/Enterprise Workspace edition, and a Workspace admin has to switch it on before anyone can use it. There's no free personal path. Your access to your own meeting notes is now downstream of a procurement decision and an admin toggle.
The output lives in Google's sphere. The notes land in a Drive Doc under your Workspace's sharing rules. That's convenient if everything you do lives in Google — and it means your meeting record is shaped by, and governed by, the platform, not you.

None of that is bad. It's the classic trade: deep integration in exchange for living inside the platform's boundary. The native notetaker is bot-free and zero-install precisely because it's part of Meet — you can't have the integration without the coupling.

The portable layer is the other architecture

A third-party notetaker is the opposite design: an abstraction layer that sits above the meeting platform and treats Meet, Zoom, and Teams as interchangeable inputs. It captures the call (usually via a bot that joins as a participant), and — this is the part that matters — it owns the output. The notes live in your tool, on your terms, exportable, the same regardless of which platform hosted the call.

The properties fall out of that shape. It works no matter your Workspace plan (no license, no admin). It's cross-platform by construction, so your notetaking doesn't fork every time a client sends a Zoom link instead of a Meet one. Many are free — Fathom's free plan is genuinely unlimited and produced the cleanest summary of anything we tested, and it saves the video Gemini's notes don't. The costs are the mirror image of native's benefits: a visible bot in the participant list, and one more app holding your data instead of the suite you already run.

There's even a reliability wrinkle that tracks the architecture. A bot joins the call as its own participant, so it keeps recording if your laptop sleeps or your tab closes. The native/bot-free approaches capture from your session, so they depend on you staying in it. Coupling to the platform buys integration; the portable layer buys independence — including from your own flaky Wi-Fi.

So which boundary do you want?

Strip it to the engineering decision and it's clean:

You live entirely in Google Workspace, already pay for Gemini, and never meet anywhere but Meet → take the native integration. The coupling costs you nothing you'd have used, and you get the tightest experience.
You meet across Zoom/Teams too, or you want your notes to outlive your Workspace subscription, or you're on a personal account → keep the portable layer. A tool like Fathom abstracts the platform away and hands you the output to own, which is worth a bot in the roster.

The tell is portability. If your meeting notes should be Meet-shaped — governed by Google, searchable in Drive, gone if you leave Workspace — native is the clean answer. If they should be yours, independent of where the call happened, keep the layer. (Either way, the tools record a conversation, so disclose it on external calls — in two-party-consent regions that's the law, and Meet shows a note-taking banner regardless.)

I broke down the native setup, the best portable tools, the bot-vs-bot-free reliability tradeoff, and the exact steps for each in the full guide to AI notetakers for Google Meet. But the fast way to decide isn't a feature grid — it's the boundary question: are you coupling to the platform, or keeping a layer above it?

There are only three ways to tap a Zoom call — and it decides everything about your notetaker

AI Alleyway — Thu, 16 Jul 2026 08:46:54 +0000

Every "best AI notetaker for Zoom" list ranks tools by features. That's the wrong layer. Underneath the feature grid, there are only three places a piece of software can physically tap a Zoom call to get the audio, and which one a tool uses determines almost everything you actually care about — who sees it, whether it works on the free Zoom tier, whether it follows you to Google Meet, and whether you can go back and re-watch. Once you see the three attach points, the tool choice mostly falls out. I've tested tools from each category; here's the taxonomy.

1. Bot-as-participant

The most common approach: a bot joins the meeting as a visible participant and records from the inside. Fathom and Otter do this by default. It's the most portable design — because the bot just needs to be admitted to the call, it works on any Zoom tier (including free Zoom) and the same tool usually covers Google Meet and Teams too. Fathom even ships an official Zoom Marketplace app for one-click setup.

The cost is visibility. There's a labeled "AI Notetaker" sitting in the participant list, and once everyone on a call runs their own, you get the now-familiar pile-up of three or four notetaker bots in the roster. On external calls that's awkward at best and against the other side's policy at worst.

Trade: maximum reach and cross-platform, minimum discretion.

2. Inside-the-platform

The second approach doesn't join the call — it runs inside it. Zoom's native AI Companion (its "My Notes" feature) executes server-side within Zoom itself, captures the meeting, and emails a summary afterward. Nothing appears in the participant list because nothing joined; it's the platform taking its own notes.

The economics are the appeal: where Google charges for Gemini and Microsoft charges for Copilot, Zoom bundles the core AI Companion note-taking into its paid Zoom Workplace plans (roughly $13–18/user/month) at no extra cost — so if your org already pays for Zoom, you may already have this and just need an admin to switch it on. (Zoom has started layering premium AI tiers on top, so the frontier keeps moving, but the basic summary comes with the plan.)

The constraints are the flip side of living inside one platform: it's Zoom-only (nothing for your Meet or Teams calls), it needs an admin/host to enable it, and it's not available on the free Zoom tier.

Trade: cheapest and cleanest if you're already a paying, single-platform Zoom shop; useless outside it.

3. Local device-audio capture

The third approach ignores the call entirely and captures what your own machine hears. Granola grabs your device audio locally; browser tools like Tactiq transcribe from a Chrome extension. No bot, no participant, nothing added to the meeting — the quietest possible footprint, which is exactly why it's the pick for confidential client calls.

The architectural catch is a hard one: these tools capture what you can hear, so they work best when you're an active participant actually in the audio path, and they lean on the notes you take rather than a pristine multi-speaker server-side transcript. (Worth stating plainly: bot-free is not the same as recording in secret — in two-party-consent regions you still disclose you're transcribing.)

Trade: minimum footprint and maximum privacy, at the cost of capture fidelity and needing to be present.

Pick the attach point, then the tool

Read your situation through the three and the shortlist writes itself: on a free Zoom account or bouncing between Zoom/Meet/Teams, you need a bot-as-participant tool (Fathom is the one I'd start with — unlimited free plan, official Zoom app, cross-platform). Already a paying, Zoom-only org, the inside-the-platform AI Companion is the cheapest clean option you may already own. Running discreet external calls, local capture (Granola) keeps the meeting clean.

I laid out both routes on Zoom specifically — the native AI Companion setup, the free third-party apps, the multi-bot problem, and how to enable each — in our AI notetaker for Zoom guide, built from the tools we actually ran rather than a marketplace listing. But the mental model is the durable part: three attach points, three sets of tradeoffs, and the tool is downstream of which one fits your call.

The "AI avatar generator" category is three rendering architectures wearing one label

AI Alleyway — Thu, 09 Jul 2026 11:42:15 +0000

If you evaluate AI avatar tools as if they're interchangeable — type a script, get a talking head — you'll pick the wrong one and then blame the tool. I tested the three market leaders hands-on, giving each the same nine-second script, and the thing that actually separates them isn't avatar quality. It's the rendering architecture underneath. And once you see the architecture, two things you'd written off as pricing quirks turn out to be inevitable consequences of it.

There are three architectures.

1. Batch render behind a moderation gate (Synthesia)

Synthesia takes a script, screens it for policy issues before generating, renders the avatar, then moderates the finished video before it will release it to you. In my test, a nine-second clip took four to five minutes to appear — and almost all of that time was the moderation step, not the rendering.

That reads like a performance problem. It isn't. It's the whole value proposition. The moderation gate is why Synthesia is the tool most of the Fortune 100 standardize on: a security or compliance team can sign off on a system that refuses to emit an avatar saying something off-policy. You cannot buy your way past the latency, because the latency is the guardrail. There's no "fast mode" tier — a fast mode would mean turning off the exact thing enterprises are paying for.

The billing model follows from the architecture too. Because every output is a discrete, moderated artifact, Synthesia meters by the finished minute. Its plans are minute allowances — a mid-tier plan is a few hundred minutes a year — and the effective cost lands around two dollars per finished minute. A per-artifact price on a per-artifact pipeline.

2. Fast render, metered by compute (HeyGen)

HeyGen returned a comparable nine-second clip in about a minute, with no moderation queue in the way. Same job description — script in, talking head out — completely different pipeline: no policy gate, and the render is the entire wait.

But the interesting part is the meter. HeyGen doesn't bill by the minute of video; it bills by credits, and the credit burn rate depends on which motion engine you pick. The older engine costs a few credits per minute. The newer, lifelike engines — the entire reason you'd choose HeyGen — cost around 20 credits per minute. That's roughly a 7× spread in cost for the same duration of output, decided by one dropdown.

That's not an arbitrary gimmick. Credits are a compute passthrough: the lifelike engines are far more expensive to run, so they drain the meter far faster. The consequence for a buyer is that a plan's headline number ("600 credits") tells you almost nothing until you know which engine you're running — 600 credits is ~30 minutes of the good engine, or ~200 minutes of the cheap one. The unit that matters is credits-per-minute-of-the-engine-you-actually-want, and the pricing page won't do that division for you.

There's a trap that falls straight out of this architecture: a new HeyGen project defaults to the premium engine, which the free plan won't render — so a first-time free user hits Generate, gets an upsell instead of a video, and concludes the tool is broken. It isn't; you have to manually downgrade the engine. That's the compute-metered design leaking into the onboarding.

3. Real-time inference, metered by the conversation (Tavus)

Tavus doesn't render a file at all. It generates the avatar live, during what feels like a video call — you talk, it talks back, rendered in real time. I held an actual conversation with its built-in agent, and the real-time face was the closest thing to talking to a person I've tried.

Different architecture, different failure mode: it's still in beta, and my first call dropped before connecting on a retry. A batch renderer can't "drop a call" — it either returns a file or errors. Real-time inference carries a whole class of reliability problems the other two don't, because there's a live session to keep alive.

And, predictably, the meter changes again. There's no finished minute to sell and no render credit to burn, so Tavus prices by conversational minutes, with pay-as-you-go overage. That's the only honest unit for a pipeline whose output is a session, not an artifact — and it's also why costs are harder to forecast than a flat per-video plan: you're paying for time-on-call, which your users control, not you.

The takeaway for anyone choosing

"Which AI avatar tool is best" has no answer because the three leaders aren't competing on one axis — they're three different systems:

Playback of a governed artifact → batch-plus-moderation (Synthesia). Slow and per-minute on purpose.
Playback of a high-quality artifact, fast → compute-metered render (HeyGen). Fast, but the credit rate — not the plan price — is your real bill.
A conversation → real-time inference (Tavus). No file; per-conversational-minute; and a live session's reliability tax.

You can't upgrade a batch tool into a real-time one, and you can't make a moderated tool fast without removing the moderation that's the point of it. So decide which architecture your job needs first; the tool, and the shape of its bill, follow from that. I put all six tools we looked at — the three leaders plus the specialists — through exactly this lens in our hands-on best AI avatar generator roundup, where the render times, credit math, and per-tool verdicts are laid out in full.

Prices and credit rates above are from our hands-on tests in July 2026; vendors move these around, so treat the exact figures as directional and the architecture as the durable part.

InVideo's credit meter is a GPU bill: the same video, priced 20x apart

AI Alleyway — Thu, 09 Jul 2026 03:46:44 +0000

"InVideo AI is $20 a month" is true and almost useless. The plan fee is the price of the door; the credits are the price of the video, and the credit cost of a single 30-second clip swings about 20x depending on one choice you make each time you hit generate. Once you understand why, it stops being a mystery bill and becomes something you can actually budget — the same way you'd budget metered cloud compute.

It's not a video tool with a price. It's a model hub with a meter.

InVideo bills itself as a hub with access to 200-plus models. You don't pay per video; you pay a flat monthly fee for access, and then every generation spends from a monthly credit pool that refills with your plan (75 credits on the $20 Plus plan, 390 on Max, 800 on Generative, 4,250 on Elite).

The important part is what sets the cost of a single generation. It's not the length or the plan — it's the compute behind the model you invoke. Pulling a licensed stock clip is nearly free to run, so it costs almost nothing. Running a frontier video model like Google's Veo 3.1 or OpenAI's Sora 2 is expensive to run, so it costs a lot. InVideo is passing that compute cost straight through to you, per generation.

Here's what that looks like on the exact same 30-second brief, from InVideo's in-app generate screen (as of my testing, mid-2026):

Footage setting	What runs	Credits
Stock (Basic)	licensed stock clips	~2
Efficient generative	InVideo's cheaper models	~15
Premium (Pro)	Veo 3.1 / Sora 2	40

Same brief. Twenty times the price. That is not a pricing quirk — it's the cost model. Your plan sets the size of the pool; your footage choice sets how fast you drain it.

The part every engineer will flinch at: no retry discount

Here's the detail that turns this from "metered" to "watch out." There is no idempotency discount on a regeneration. If a clip comes out wrong and you generate it again, InVideo charges the full rate a second time.

Generative prompts rarely land on the first try — you tweak the wording, regenerate, adjust a scene, regenerate again. Two or three attempts at 40 credits each is 80 to 120 credits for one finished premium clip — more than the entire 75-credit monthly pool on the $20 plan. So the real unit of cost isn't "a video." It's a finished video, including the retries it took to get there, and that number is unknowable in advance because it depends on how many attempts your prompt needs.

That's the mechanism behind the recurring review complaint of "I paid for videos I never finished." The meter runs on every attempt, hit or miss.

How to actually budget it

Stop thinking in "videos per plan." Think in cost-per-finished-clip, like a cloud bill:

effective cost  ≈  (credits per generation)
                 ×  (expected attempts to get a keeper)
                 ×  (dollars per credit on your plan)

Run the numbers and the split is stark. On the same $20 Plus plan, a stock-first creator effectively pays about 50 cents a video (that $20 spread across ~37 stock clips), while a premium-generative creator pays closer to $11 a clip — and once you fold in the regenerations a Veo or Sora prompt usually needs, a single finished premium clip can cost more than the entire monthly plan on its own.

So the budgeting rule is: decide your footage mix first, compute credits-per-finished-clip (retries included), then pick the plan whose pool clears that with margin. The 40-credit premium tier is the on-demand GPU instance of this analogy — remarkable value if you use it sparingly, ruinous if you lean on it without watching the meter.

I worked the full thing out — every plan, the credit-to-dollar math, the stock-license second meter, and where the free plan actually stops being usable — in what a video actually costs on InVideo. But the one idea that saves you the most is this: the number to write down before you subscribe isn't $20. It's how many premium clips a month you actually need, because that's the variable the whole bill turns on.

The line in the LICENSE file that reorders your n8n alternatives

AI Alleyway — Wed, 08 Jul 2026 07:16:37 +0000

Most "n8n alternatives" lists compare the wrong column.

They line up connector counts, per-execution pricing, cron support, and a screenshot of the canvas. Useful, up to a point. But if you're planning to self-host the engine — the reason you're looking past the SaaS incumbents in the first place — there's a field none of those tables show, and it sits in a file at the root of every repo: LICENSE.

We run n8n in production. The entire AI Alleyway content pipeline is about ten self-hosted n8n workflows on a single box. So this isn't a "we surveyed the landscape" post — it's the one architectural question I wish more alternatives lists led with, because it's the one that quietly decides whether a tool is even eligible for your use case before you've compared a single feature.

Three licenses, three completely different contracts

"Open source" gets used as a single adjective. For self-hosted automation engines it's actually three different legal contracts, and they diverge exactly where it matters — redistribution.

n8n ships under the Sustainable Use License (v1.0). This is source-available, not an OSI-approved open-source license. n8n's own umbrella term for the model is "fair-code." You can read the source, self-host it, and modify it — but the grant is scoped. Straight from the repo's LICENSE.md, you may use or modify the software "only for your own internal business purposes or for non-commercial or personal use," and you may distribute it to others "only if you do so free of charge for non-commercial purposes." In plain terms: run it for yourself all you want; you cannot turn around and offer n8n as a hosted service to third parties, or bundle-and-resell it commercially, without a separate enterprise license.

Activepieces ships under MIT (its Community Edition). MIT is the permissive, OSI-approved baseline — embed it, fork it, resell it, close your fork, no copyleft strings. The honest nuance: MIT covers the Community Edition core; Activepieces keeps some enterprise features under a separate commercial license, so "MIT" describes the open core, not every paid add-on. But the core you'd self-host and build on is genuinely permissive.

Node-RED ships under the Apache License 2.0, stewarded by the OpenJS Foundation. Also OSI-approved and permissive, and Apache 2.0 goes one step past MIT by including an explicit patent grant — the contributors license the patents needed to use their contribution, and there's a patent-retaliation clause. If your legal team cares about patent exposure in a shipped product, that clause is a feature, not boilerplate.

Three tiers: source-available-with-a-redistribution-fence, permissive, permissive-with-a-patent-grant. Same "open" label on the tin.

Why the license is an architectural constraint, not a footnote

Here's the reframe: the license isn't a compliance checkbox you clear at the end. It's a boundary on your architecture, because it constrains where the automation engine is allowed to live in your system.

Ask one question — is the automation layer something you run, or something you ship?

If you run it — internal ETL, ops glue, a content pipeline like ours, back-office orchestration that never leaves your own walls — then n8n's fair-code fence never touches you. "Internal business purposes" is exactly what you're doing. That's precisely our situation: we chose n8n knowingly, and the Sustainable Use License was a non-issue because we don't resell the engine or expose it as a product to anyone. In that world you should optimize for depth, and n8n's depth is real — on the order of 1,100 integrations, strong branching and error handling, and a node ecosystem that means most of what you need already exists.

If you ship it — the automation engine is embedded in a product your customers touch, or you're offering "workflows" as a feature of your SaaS, or you're a platform letting your users build automations — you've crossed the exact line the fair-code license draws. Now n8n's restriction is load-bearing. Offering it as a service to third parties is the thing the license reserves. At that point the feature-richest tool is no longer the honest answer; the eligible tools are the permissively licensed ones. Activepieces (MIT) and Node-RED (Apache 2.0) let you embed, white-label, fork, and resell without asking anyone. That's not a marketing claim — it's what those license texts grant.

This is why a license-blind alternatives list can actively mislead. It'll rank n8n at the top for a reader who's building a product on top of an automation engine — a reader for whom n8n's own license says "not like this." The ranking is correct for the internal-use reader and wrong for the productizing reader, and the table gives you no way to tell which one you are.

Where the hosted tools fit (and why they dodge the question)

For completeness: we've also driven Make (built a real scenario against its API) and Zapier (ran its MCP across Gmail, Calendar, and Slack). Both are fine tools. But they're hosted SaaS — there's no repo to self-host and no LICENSE file to read, so the whole license-tier question is moot. You're renting capacity and accepting the terms of service, full stop. That's a legitimate choice; it's just a different decision than the one this post is about. The license axis only exists once you've committed to self-hosting, which is where the "n8n alternatives" search usually lands you anyway.

The same "it's a service, not a license" framing applies to most of the other hosted names that show up in these roundups — Pipedream, Workato, Power Automate, Gumloop, Tray.ai. I'm assessing those from their docs and terms, not from production use, and none of them change the core point: if you're not self-hosting, you're evaluating a contract, not a license.

The decision, compressed

Running automations internally? Fair-code is fine. Optimize for depth and ecosystem — n8n earns its spot.
Shipping the automation layer inside a product, or need to fork/embed/resell freely? The permissive licenses are the honest destination, not the feature-count winner. Look hard at Activepieces (MIT) and Node-RED (Apache 2.0), and read their LICENSE files yourself before you commit.
Not self-hosting at all? The license tier doesn't apply — you're picking a SaaS on terms-of-service and pricing, and Make/Zapier/Pipedream are competing on that axis instead.

The practical move: before you shortlist any self-hosted automation engine, open its LICENSE file first and answer the run-it-vs-ship-it question. That one field filters the list faster than any feature matrix, and it filters it correctly — because it filters on what you're actually allowed to do, not on what the tool can do.

When I sanity-checked our own stack against this lens, I ended up pulling together the full n8n alternatives breakdown, sorted by why you're leaving — nine tools grouped by the reason someone actually migrates (license, hosting model, pricing shape, integration gaps) rather than by a single leaderboard. If you're weighing a switch, reading it by your reason-for-leaving is a lot more useful than reading it top-to-bottom.

Read the LICENSE file first. It's the cheapest architecture decision you'll make all quarter.

Generate your Open Graph images with React (Remotion), not a design tool

AI Alleyway — Mon, 06 Jul 2026 13:00:00 +0000

Every blog post, product page, and share link wants its own Open Graph image — the card that shows up when the URL is posted to X, LinkedIn, Slack, or iMessage. Hand-making those in Figma doesn't scale: the moment you have a few dozen pages, you're copy-pasting a template and re-exporting PNGs by hand.

I moved mine to code. One React component, one CLI command per card, and a size-optimization step. Here's the whole setup — including the two gotchas that cost me an afternoon.

Why Remotion?

Remotion is "React for videos" — but it renders still frames just as happily as video, and a 1200×630 OG card is just a single frame of a React component. That means your card is a normal component: props, flexbox, your real fonts and brand tokens, conditional layout. No design-tool round-trip, no drift between your site's styles and your cards.

The composition

export const OgCard: React.FC<{
  headline: string;
  productName?: string;
  rating?: number;
}> = ({ headline, productName, rating }) => (
  <AbsoluteFill style={{ background: "linear-gradient(135deg,#0b0b0f,#1a1330)", color: "#fff", padding: 80, justifyContent: "space-between" }}>
    <h1 style={{ fontSize: 68, lineHeight: 1.05, fontFamily: "Outfit" }}>{headline}</h1>
    {productName && <div style={{ fontSize: 34, opacity: 0.8 }}>{productName}{rating ? ` · ${rating}/5` : ""}</div>}
  </AbsoluteFill>
);

// index.ts
<Composition id="OgCard" component={OgCard} width={1200} height={630}
  durationInFrames={60} fps={30} defaultProps={{ headline: "" }} />

Rendering one card per page

renderStill writes a single PNG. Feed it the per-page props as JSON:

npx remotion still src/index.ts OgCard out/my-post.png \
  --props='{"headline":"The cheaper voice tool wasn'\''t on the pricing page","productName":"Acme TTS","rating":4}'

Loop that over your content collection and you have a card per URL, regenerated on every build.

Don't ship the PNG — convert to WebP

A 1200×630 PNG out of a headless browser is big — mine came out around 770 KB. That's absurd for a social card. One conversion step drops it to ~17 KB with no visible loss:

# ImageMagick
magick out/my-post.png -quality 82 -define webp:method=6 out/my-post.webp
# or sharp: sharp(png).webp({ quality: 82 }).toFile(webp)

Point your og:image / twitter:image at the WebP. ~45× smaller, same card.

Gotcha 1: `selectComposition` needs the SAME inputProps as `renderStill`

If you render programmatically (Node API) rather than the CLI, you call selectComposition() first, then renderStill(). Pass your inputProps to BOTH. Anything resolved at selection time — most importantly staticFile() references and anything derived from props in calculateMetadata — uses defaultProps if you only handed props to renderStill.

The symptom is baffling the first time: every card comes out byte-identical (the default props rendered), or an image staticFile('logo.png') silently resolves to the placeholder. It's not a caching bug — it's the selection step running on defaults.

const inputProps = { headline, productName, rating };
const comp = await selectComposition({ serveUrl, id: "OgCard", inputProps }); // ← here
await renderStill({ composition: comp, serveUrl, output, inputProps });        // ← and here

Gotcha 2: `renderStill({ frame })` requires `durationInFrames > frame`

If you register a still-only composition with durationInFrames: 1 and then ask for frame: 30 (say, to let an entrance animation settle), Remotion throws:

RangeError: Cannot use frame 30: Duration of composition is 1

Give the composition enough frames for the frame you sample. I register OG/still compositions with durationInFrames: 60 (2s @ 30fps) and render whatever frame I want within that.

That's the whole pipeline

One React component = your card, in your real styles.
renderStill + a JSON props blob = one card per page, on every build.
A PNG→WebP step = ~45× smaller files.
Remember: same inputProps to selectComposition and renderStill, and durationInFrames bigger than the frame you sample.

Once it's wired, adding a new page's social card is zero manual work — it falls out of the build. Worth the afternoon.

Shipping one Manifest V3 extension to Chrome, Edge, and Firefox from a single source

AI Alleyway — Sun, 05 Jul 2026 10:38:26 +0000

I recently shipped a small Manifest V3 browser extension — a toolbar popup plus an address-bar (omnibox) search, zero permissions — and wanted it on all three major stores: the Chrome Web Store, Edge Add-ons, and Firefox's AMO.

The pitch for MV3 is that it's the shared standard, so "write once, ship everywhere." That's mostly true — but the small divergences are exactly the kind of thing that fails a store review at 11pm. Here's the complete list of what actually differs, plus a tiny build script that emits all three packages from one source.

Chrome and Edge are the same package

Good news first: Edge Add-ons accepts the exact same MV3 zip as the Chrome Web Store. Edge is Chromium, background.service_worker works as-is, and the chrome.* APIs are identical. You upload the same artifact to both. (I keep them as separately-named zips only for a clean per-store upload trail.)

Firefox needs three manifest tweaks — and zero code changes

Firefox is where it gets interesting. The code didn't change at all — the extension uses only chrome.omnibox, chrome.runtime, and chrome.tabs, all of which Firefox exposes via the chrome.* alias. Only the manifest needs three edits.

1. background.service_worker → background.scripts

Firefox's MV3 support prefers an event page over a service worker for the widest compatibility. If your background script only registers listeners at the top level (no service-worker-only globals), it runs fine as an event-page script:

// Chrome / Edge
"background": { "service_worker": "background.js" }

// Firefox
"background": { "scripts": ["background.js"] }

2. browser_specific_settings.gecko.id

AMO requires an explicit extension id. Chrome/Edge derive one for you; Firefox wants it declared:

"browser_specific_settings": {
  "gecko": { "id": "your-ext@yourdomain.com" }
}

3. data_collection_permissions — and the version floor it drags in

This is the one that surprised me. Newer Firefox requires every extension to explicitly declare what user data it collects — even when the answer is "nothing." Omit it and web-ext lint fails with MISSING_DATA_COLLECTION_PERMISSIONS:

"gecko": {
  "id": "your-ext@yourdomain.com",
  "strict_min_version": "142.0",
  "data_collection_permissions": { "required": ["none"] }
}

The gotcha is the version floor. data_collection_permissions is only supported from Firefox 140 on desktop and 142 on Android. Set strict_min_version below 142 and the linter throws KEY_FIREFOX_UNSUPPORTED_BY_MIN_VERSION — first for desktop, then again for Android. 142.0 is the floor that satisfies both.

The omnibox trap on Firefox for Android

If your extension has an omnibox keyword like mine, do not tick "Firefox for Android" compatibility on AMO. The omnibox API is not supported on Firefox for Android — the popup still works as an overlay, but the address-bar keyword silently does nothing. Ship desktop-only until you've adapted and tested for mobile, or you'll be shipping a broken core feature to Android users.

One source, three zips

Rather than maintain three manifests by hand, keep one and transform it at build time. The whole script is ~40 lines; the interesting part is the Firefox transform:

function firefoxManifest(m) {
  const fx = structuredClone(m);
  fx.background = { scripts: ["background.js"] };
  fx.browser_specific_settings = {
    gecko: {
      id: "your-ext@yourdomain.com",
      strict_min_version: "142.0",
      data_collection_permissions: { required: ["none"] },
    },
  };
  return fx;
}

// pack("chrome", base);
// pack("edge",   base);              // === Chrome, kept separate for a clean upload trail
// pack("firefox", firefoxManifest(base));

Each pack() stages the shared files (popup.*, background.js, icons, plus the per-store manifest) and zips them with paths at the archive root (manifest.json must sit at the top level, not under a subfolder).

Validate before you upload

Run web-ext lint — the same validator AMO runs — on the Firefox package before submitting. It catches the version-floor and data-collection issues above locally, instead of after a rejected upload. My bar was 0 errors / 0 warnings / 0 notices before the zip went anywhere near the store.

The short version

Chrome == Edge — one MV3 zip, upload to both.
Firefox — three manifest lines (background.scripts, gecko.id, data_collection_permissions) and one version floor (142.0). No code changes.
Omnibox on Android — unsupported; don't tick the box.
Lint locally with web-ext so the store never says no.

If you're maintaining separate repos or manifests per browser, collapsing to one source + a build transform is an afternoon well spent.

DEV Community: AI Alleyway

Provenance is a testable property of an answer engine. I scored three of them.

Provenance as a scoring function

The output

A score is not a check

What I'd take from it as an engineer

Your TTS shortlist is three shortlists, and they barely intersect

The three sets

Intersecting instead of ranking

Which constraint is actually binding

About the axis I deliberately did not model

The shape I would actually use

The agent edited the rule that made its change wrong

Setup

What it got right

The finding

What I changed afterwards

Limits, plainly

The transcript is not the artifact

What the agent actually did

Lie one: the agent's own diff badge

Lie two: I quoted a diffstat as if it counted something

Lie three: I declared zero when it was forty-five

What I do now

The finding that actually unsettled me

The short version

What a year of metered AI coding actually cost me: a $20 plan that billed $510.70

The arithmetic

Why the intuition fails

The control that exists and nobody sets

What I concluded

Google Meet ships its own AI notetaker now — so the real question is lock-in, not features

What the native path actually commits you to

The portable layer is the other architecture

So which boundary do you want?

There are only three ways to tap a Zoom call — and it decides everything about your notetaker

1. Bot-as-participant

2. Inside-the-platform

3. Local device-audio capture

Pick the attach point, then the tool

The "AI avatar generator" category is three rendering architectures wearing one label

1. Batch render behind a moderation gate (Synthesia)

2. Fast render, metered by compute (HeyGen)

3. Real-time inference, metered by the conversation (Tavus)

The takeaway for anyone choosing

InVideo's credit meter is a GPU bill: the same video, priced 20x apart

It's not a video tool with a price. It's a model hub with a meter.

The part every engineer will flinch at: no retry discount

How to actually budget it

The line in the LICENSE file that reorders your n8n alternatives

Three licenses, three completely different contracts

Why the license is an architectural constraint, not a footnote

Where the hosted tools fit (and why they dodge the question)

The decision, compressed

Generate your Open Graph images with React (Remotion), not a design tool

Why Remotion?

The composition

Rendering one card per page

Don't ship the PNG — convert to WebP

Gotcha 1: selectComposition needs the SAME inputProps as renderStill

Gotcha 2: renderStill({ frame }) requires durationInFrames > frame

That's the whole pipeline

Shipping one Manifest V3 extension to Chrome, Edge, and Firefox from a single source

Chrome and Edge are the same package

Firefox needs three manifest tweaks — and zero code changes

The omnibox trap on Firefox for Android

One source, three zips

Validate before you upload

The short version

Gotcha 1: `selectComposition` needs the SAME inputProps as `renderStill`

Gotcha 2: `renderStill({ frame })` requires `durationInFrames > frame`