DEV Community: Robert

Claude found four stale facts in a published n8n guide

Robert — Sun, 20 Sep 2026 10:00:00 +0000

Claude compared a published guide against current sources on 2026-09-16 and found four facts that have materially changed since the guide was written: Instagram's hashtag hard cap, Brave Search's free-tier model, Gmail API's quota structure, and the default max-iterations value of the n8n AI Agent node.

The guide covers n8n plus Claude MCP workflows for solopreneurs. The check flagged sections 6 and 9 as update_needed at warn severity, while the core architecture was marked still sound.

The alert treats this as a manual edit. A POST to the edition endpoint rewrites only the affected sections, re-renders the file, and pushes the updated version. The record does not say why those two sections hold all four changed facts rather than others.

When Claude checks a document for freshness, a few stale third-party defaults do not force a full rewrite if the core structure is still valid.

Originally published at neuragrowth.co. NeuraGrowth is a one-person digital-products studio; this is the log of what its pipeline does and where it breaks.

Sonnet vs Opus on PDF Critique: When To Reach For Which

Robert — Sat, 19 Sep 2026 10:00:00 +0000

If you are picking a model for a structured critique job, the obvious question is whether the more expensive option earns its price. We ran that comparison on our critique.pdf_guide job across 288 calls over 90 days, and the numbers tell a clear story.

Sonnet (anthropic/claude-sonnet-4-6) handled 241 of those calls. Opus (anthropic/claude-opus-4-8) handled 47. Both ran on the same job, against the same prompts. Neither produced a single failure on our side.

We stopped using Sonnet on 2026-07-25, the same date Opus first appeared in the record. The record does not say why we switched.

What the job asks each model to do

The critique.pdf_guide job sends a prompt to the model and gets back a short critique. Output was 27 tokens per call on Sonnet and 31 on Opus, so the two models were producing roughly the same volume of text.

Input is where the picture is more complicated. Sonnet received 2,849 total input tokens per call. Opus received 3,752. That is a different job size, not just a different model, and it matters when you read the cost figures.

The record does not say whether the prompts changed when we switched models. That uncertainty sits behind every cost comparison in this piece.

Cost per call: Opus is 2.26 times more expensive

Sonnet cost us $0.00473 per call. Opus cost us $0.01067 per call. Opus is 2.26 times the cost of Sonnet, or $0.00594 more per call on our volume.

Before reading those figures as a quality gap, look at what each model was actually billed for. Sonnet had 2,849 total input tokens per call but was billed on only 1,026, because 56.8 percent came from the prompt cache. Opus had 3,752 total input tokens per call and was billed on 1,319, with 55.2 percent cached.

The billed token counts are closer than the total counts suggest, and the cache hit rates are nearly identical at 56.8 percent and 55.2 percent. The cost difference is real, but it reflects a larger job going to Opus as much as it reflects Opus being a pricier model. We cannot separate those two factors from this data alone.

What we can say is that neither model was paying heavily for cache misses. Both were caching more than half their input on every call. The cost gap comes from the larger total input on Opus calls and from whatever rate difference applies at our volume, not from one model failing to cache.

Speed: practically the same

Sonnet had a median response time of 2.1 seconds. Opus came in at 2.2 seconds, which is 1.05 times slower and 0.1 seconds behind. For a critique job, that gap is not a practical concern.

Speed is not a reason to prefer one model over the other here. The two figures are close enough that other factors will drive any real decision.

Failures: none on either side

Both models returned zero failures across all calls in this window. Sonnet ran 241 calls with a 0.0 percent failure rate. Opus ran 47 calls with a 0.0 percent failure rate.

A failure rate is what came back as a failure on our side. It is not a statement about either vendor's reliability in general.

The fact that Sonnet is listed as the model with the most failures in the underlying data is technically accurate, and it is also zero. Both entries are zero.

The limits of this comparison

These numbers come from one job, our prompts, our input sizes, our call volumes, over 90 days ending 2026-09-08. Sonnet's calls ran between 2026-06-11 and 2026-07-25. Opus's calls ran from 2026-07-25 onward. The two windows do not overlap.

The input token counts differ between the two models. We do not know from this data whether that is because the prompts changed when we switched, or for some other reason. That means the per-call cost comparison carries a caveat: we are not confident both models were asked exactly the same question.

This is not a benchmark. A reader running a different job, with different prompt lengths or different cache conditions, should expect different figures. The cost per call figures here are what we paid on our volume, not a rate card.

Opus ran 47 calls against Sonnet's 241. The smaller sample on Opus means its figures carry more variance, and a single unusual call moves its averages more than the same call would move Sonnet's.

Which one we kept and why

Opus is the model still in use as of 2026-09-08. Sonnet's last call was 2026-07-25, which is the day Opus appeared. The record does not say why we switched.

The cost difference is 2.26 times per call. Whether that is worth it depends on what the job produces and what you need from it. The record does not give us output quality figures, so we cannot make that argument here.

What the record does show is that we moved to Opus and have stayed there across 47 calls. That is the plainest summary of what happened.

We would pick Opus today, because it is the tool still in use. If cost per call became a constraint, the gap is $0.00473 for Sonnet against $0.01067 for Opus, and the caveat is that the two models were not handling identical input sizes in this record. We would not switch back on speed alone: 0.1 seconds is not a reason to change anything.

Originally published at neuragrowth.co. NeuraGrowth is a one-person digital-products studio; this is the log of what its pipeline does and where it breaks.

YouTube Shorts cutoff: 60.1 seconds publishes as a regular video

Robert — Fri, 18 Sep 2026 10:00:00 +0000

YouTube publishes anything above 60 seconds as a regular video rather than a Short. On 2026-09-13 at 13:57, a render for liczenie-004 came in at 60.1 seconds against a limit of 59 seconds, and the orqestra.kids_episode task failed with a RuntimeError.

The topic was left in the plan rather than dropped. The next daily run will attempt it again. The alert text notes that if it fails a second time on the same topic, the problem is likely in the topic or the render gate, not in the model.

The record does not say why the render exceeded the limit. The facts record only the output duration and the failure.

The orqestra.kids_episode task fires one alert per task name per hour; the rest of the detail is in the worker log.

If you are generating video for YouTube Shorts, verify the output duration before the upload step, because anything above 60 seconds loses Shorts placement entirely.

Originally published at neuragrowth.co. NeuraGrowth is a one-person digital-products studio; this is the log of what its pipeline does and where it breaks.

MCP package versions in npm can 404 even when the package exists

Robert — Thu, 17 Sep 2026 10:00:00 +0000

Nine of the ten package versions printed in an MCP guide we were revising do not exist in the npm registry. A reader copying google-calendar-mcp@1.4.0 gets a 404 at install time. The package itself resolves, the specific version string does not.

The defect came out of the fourth review round of pull request #236. The previous text used floating tags. The revision replaced them with pinned versions, which is the right rule. The version strings supplied just do not exist in the registry.

A bad pin is strictly worse than a floating tag. The floating tag installs something. The non-existent pin installs nothing and gives the reader no clear signal as to why. When you are writing install instructions for MCP packages and you pin a version, check the pin resolves before you publish.

The commit that shipped on 2026-09-11 adds that verification step. Six files changed, 162 lines added, 4 removed.

A pinned npm version that does not exist in the registry fails harder than a floating tag, so verify every printed pin resolves before shipping install instructions.

Originally published at neuragrowth.co. NeuraGrowth is a one-person digital-products studio; this is the log of what its pipeline does and where it breaks.

Anthropic's grammar compiler counts properties, not characters

Robert — Wed, 16 Sep 2026 10:00:00 +0000

Anthropic's structured-output compiler refused our episode schema with a 400 error: 'The compiled grammar is too large.' We had a character budget that said we were safe at 4466 of 4820 characters, and it was wrong.

Fourteen probe calls, each swapping one line of the schema module, found the actual limit. The compiler accepts 42 properties distributed across all objects in the schema. The 43rd is refused wherever it sits, required or optional, enum or string. The character count is not the instrument: 4466 characters was refused, 5207 compiled fine on a different shape. Enum size is free, with 49 props, 26 actions and 11 places all passing as enums.

The schema had grown because two fields, light and sfx, joined the Beat object. That pushed the total property count over 42. The fix was to restructure: sounds now come from the picture object rather than sitting as separate top-level fields on Beat.

The change touched 6 files, added 642 lines and removed 62. The schema compiles again. The kids script jobs, kids_script.write and kids_script.repair, run against Opus (claude-opus-4-8), which was the model hitting the 400.

The record does not say why the compiler draws the line at 42, or whether that number is fixed or varies by model. What the probe calls show is that the count is per-property across all objects, and character count gives no signal about where the ceiling is.

When Anthropic's grammar compiler rejects a structured-output schema, count total properties across every object in the schema, not characters, because the ceiling the probe calls revealed is 42 properties regardless of their size or placement.

Originally published at neuragrowth.co. NeuraGrowth is a one-person digital-products studio; this is the log of what its pipeline does and where it breaks.

Pydantic rejected a one-beat episode draft for a Polish alphabet series

Robert — Tue, 15 Sep 2026 10:00:01 +0000

Pydantic's too_short validator rejected an episode draft at 07:52 on 2026-09-07. The schema for EpisodeDraft requires at least 4 items in the beats list. The model returned exactly 1.

The alert came from the NeuraGrowth Kids pipeline, series alfabet, topic litera O, episode alfabet-002. The single beat that did come back had a vo field and a tone field, so the structure was right - there just was not enough of it.

The record does not say why the model produced one beat instead of four.

The topic stays in the plan and Orqestra will retry it on the next run. The alert notes that if the same topic fails a second time, the problem is more likely in the topic or the prompt gate than in the model response.

A minimum-length list validation like this makes the failure loud and recoverable. The episode did not silently ship short: it was held and logged.

When you validate list length with Pydantic, a too_short error gives you a named, retryable failure rather than a silently truncated output.

Originally published at neuragrowth.co. NeuraGrowth is a one-person digital-products studio; this is the log of what its pipeline does and where it breaks.

What We Actually Make, and Who the Family Line Is For

Robert — Mon, 14 Sep 2026 10:00:00 +0000

If you found NeuraGrowth through one of our bilingual printable packs, this is worth knowing: most of what we ship is not that. The catalogue runs heavily toward practical guides for people who build software and AI-powered tools. That context matters, because it shapes how we think about the family line and what we put into it.

The family materials are a smaller, separate thread inside a much larger output. We are not a children's brand that also does tech. We are a technical publishing studio that also makes bilingual learning material for home use. Writing that plainly feels more respectful than letting the shop layout suggest something different.

This post is not about a new family product. It is about being honest with the parents who do find us, so you know what you are looking at when you browse the catalogue.

Most of what we ship is technical guides

Since July 2026 alone, we have shipped guides covering AI app security, ChatGPT workflows for solo service professionals, agent-to-canvas wiring in Framer, AI-first personal finance, and multi-agent infrastructure. The most recent addition, product 184, is a weekend walkthrough for shipping a developer plugin to npm.

Every one of those is a PDF guide priced at $6.99, aimed at people who build things alone. That is the core of what NeuraGrowth makes.

The family and bilingual line exists alongside that output. It is real and we put care into it. But it is a smaller part of the catalogue, and it would be dishonest to frame it otherwise.

The family line is for parents, not the studio's main audience

Our bilingual learning materials are written for parents who want printable, practical help at home. No subscription, no app, no account to manage. You download a PDF and use it.

The parents who find us through that line are a different reader from the developer buying a plugin guide. We try to keep those two things genuinely separate rather than blurring them together for the sake of a tidy brand story.

If you came here for bilingual learning material, the family section of the shop is the right place to look. The technical guides are there too, and you are welcome to browse them, but they are not written for you.

Why we are saying this now

The catalogue has grown quickly on the technical side. Without a clear statement, a parent browsing could reasonably wonder whether they had wandered into the wrong shop.

We would rather tell you plainly what the proportions are than let the catalogue speak for itself in a confusing way.

That is the whole reason for this post. No new family product to announce. Just an honest account of where the family line sits.

If you are a parent looking for our bilingual printable materials, go to the family section directly. If you are curious about what else we make, the technical guides are there, but they are aimed at developers and solo builders. Knowing which side of the catalogue you are on will save you time and help you decide whether what we make is actually useful to you.

Originally published at neuragrowth.co. NeuraGrowth is a one-person digital-products studio; this is the log of what its pipeline does and where it breaks.

Etsy OAuth invalid_grant can fire before the 90-day expiry

Robert — Sun, 13 Sep 2026 10:00:00 +0000

Etsy's OAuth refresh tokens carry a 90-day idle expiry, but ours returned invalid_grant (EtsyRefreshExpired) at 05:30 on 9 September before that window closed.

While disconnected, we had no visibility into new orders and no price or Ads spend sync.

The alert body lists three events that can invalidate a token before its natural deadline: reconnecting the integration, changing the account password, or rotating credentials without writing the new token back to storage. The record does not say which of those applied here.

The 90-day window is a ceiling, not a guaranteed lifespan. The error date is not necessarily the date the credential stopped being valid.

Treat Etsy invalid_grant as a possible early revocation rather than a predictable 90-day expiry, because reconnects, password changes, and missed rotation writes can all kill the token ahead of schedule.

Originally published at neuragrowth.co. NeuraGrowth is a one-person digital-products studio; this is the log of what its pipeline does and where it breaks.

LinkedIn is a separate lane: spent keys in content pipelines

Robert — Sat, 12 Sep 2026 10:00:00 +0000

The LinkedIn channel in Orqestra now tracks spent source keys independently from the blog and the dev.to daily log. Before this change, used_source_keys() filtered against a single global set, which meant a source event consumed by a short note was blocked from the blog and from LinkedIn as well.

The fix is in used_source_keys(), which now filters by lane. An outage described briefly in the daily log can still surface as full coverage on the blog, and again as a LinkedIn post, without the second or third pass being blocked by the first.

Four files changed, with 688 lines added and 87 removed. The three-channel schedule, dev.to every day, the blog for search and pillar coverage, LinkedIn three times a week, was set on 2026-09-06 and is now enforced in code rather than by hand.

The record does not say what the global set was originally designed to prevent.

If your pipeline shares one spent-key set across output channels, a key consumed by a short post will block the same event on LinkedIn or anywhere else: scope the record to the channel.

Originally published at neuragrowth.co. NeuraGrowth is a one-person digital-products studio; this is the log of what its pipeline does and where it breaks.

ElevenLabs vs Gemini Flash TTS: Which We Kept After 879 Calls

Robert — Fri, 11 Sep 2026 10:00:01 +0000

If you are building audio content and choosing between ElevenLabs and Gemini for text-to-speech, the numbers we collected will save you some time. We ran three tools on the same job, kids_episode.tts, across 879 calls over 90 days, and the gap between them is wider than we expected.

The three tools are eleven_v3 (elevenlabs/eleven_v3), Gemini Flash TTS (gemini/gemini-3.1-flash-tts-preview), and eleven_multilingual_v2 (elevenlabs/eleven_multilingual_v2). Only one of them is still running.

What follows covers what each call cost us, how long it took, and how often it failed. None of this is a benchmark. These are our prompts, our volumes, our 90-day window. A different job will produce different numbers.

eleven_multilingual_v2 is the cheapest and the fastest

eleven_multilingual_v2 handled 102 calls at $0.00139 per call, with a median response time of 0.9 seconds and zero failures. It is the cheapest tool in this comparison and the fastest.

Billed input was 21 tokens per call and output was 11 tokens per call. No caching was active on any of the three tools, so every token was billed at full rate.

Its last recorded use is 2026-08-22. The record does not say why it was not continued.

eleven_v3 costs 2.38 times more and runs 2.11 times slower

eleven_v3 handled 540 calls, the largest share of the three. Each call cost $0.00331, which is $0.00192 more per call than eleven_multilingual_v2 and 2.38 times its cost. Median response time was 1.9 seconds, 1.0 second slower than the fastest and 2.11 times its speed.

Billed input was 44 tokens per call and output was 26 tokens per call. No caching was used, so every billed token was a full-rate token.

eleven_v3 had zero failures across 540 calls. It is the only tool still active as of the last date in the record.

Gemini Flash TTS failed on nearly one in six calls

Gemini Flash TTS ran 237 calls. Each call cost $0.00198, which is 1.42 times the cost of eleven_multilingual_v2 and $0.00059 more per call. Median response time was 2.8 seconds, 1.9 seconds slower than the fastest and 3.11 times its speed.

The failure rate was 16.9 percent, meaning 40 of its 237 calls came back as failures on our side. The record does not say why those calls failed.

Gemini Flash TTS was first used on 2026-08-21 and last used on 2026-08-22. The record does not state a reason for stopping.

Token counts across the three tools

All three tools received the same job. eleven_multilingual_v2 billed 21 input tokens and produced 11 output tokens per call. eleven_v3 billed 44 input tokens and produced 26 output tokens. Gemini Flash TTS billed 44 input tokens and produced 105 output tokens.

None of the three tools used any caching. Every billed token was a full-rate token.

The output token count for Gemini Flash TTS, 105 per call, is the highest of the three. The record does not explain what those output tokens represent.

The limits of this comparison

These figures come from one job, kids_episode.tts, over 90 days and 879 calls. The prompts are ours, the volumes are ours, and the failure counts reflect what came back on our side, not any vendor's published uptime.

Cost per call is what we paid on our actual volume. It is not a rate card figure and should not be treated as one.

A reader running longer scripts, different languages, or higher volumes may see different costs, speeds and failure rates. This is a record of what happened here, not a general recommendation.

Which we kept

eleven_v3 is the tool still running as of 2026-08-25, the last date in the record. It costs 2.38 times more per call than eleven_multilingual_v2 and runs 2.11 times slower, but it returned zero failures across 540 calls.

eleven_multilingual_v2 was cheapest and fastest, and also had zero failures, but its last recorded use is 2026-08-22. The record does not say why it was not continued.

Gemini Flash TTS stopped after one day. Its failure rate of 16.9 percent is the clearest number in this comparison. The record does not say whether that rate was the reason it stopped.

eleven_v3 is the tool we are running. It costs more than eleven_multilingual_v2 and is slower, but across 540 calls it returned zero failures. Gemini Flash TTS failed on 16.9 percent of calls and was dropped after one day. If you are picking between these three for a similar job, the failure rate is the number to look at first.

Originally published at neuragrowth.co. NeuraGrowth is a one-person digital-products studio; this is the log of what its pipeline does and where it breaks.

Pydantic caught three distinct JSON failures from a model output

Robert — Thu, 10 Sep 2026 10:00:00 +0000

Pydantic raised a validation error on three separate content drafts across two days. Two were truncated: one stopped mid-value at column 20914, one mid-string at column 21862. The third carried a trailing comma at column 1308. Each surfaces in Pydantic as a single json_invalid error with a column number.

The three alerts fired at different times: the trailing comma on 2026-08-23, the two truncation errors on 2026-08-24. The record does not say why any of the three arrived in that state.

In each case the topic was left in the plan, and the alert noted that a second failure on the same topic would point to the topic or the gateway rather than the model.

EOF mid-value, EOF mid-string, and trailing comma are distinct failure shapes that all surface as a single Pydantic json_invalid error, so the column number and the error subtype together are what tell them apart.

Originally published at neuragrowth.co. NeuraGrowth is a one-person digital-products studio; this is the log of what its pipeline does and where it breaks.

One discover_trending_niches run took 140 times longer than normal

Robert — Wed, 09 Sep 2026 10:00:00 +0000

One discover_trending_niches run started at 09:00 on 2026-08-30 and ran for 783.7 minutes before it failed. The median across 11 runs is 5.6 minutes, so this one took roughly 140 times as long.

The run did not complete, so whatever work it was doing produced no output. The record does not say what caused the slowdown or how the deviation was detected.

A duration that far outside the normal range, with no output and no clear error signal, is the kind of failure that does not look different from a normal run without duration data to compare against.

Track operation duration as a distribution, not just a pass-or-fail status, or a silent 140x slowdown looks the same as a normal run.

Originally published at neuragrowth.co. NeuraGrowth is a one-person digital-products studio; this is the log of what its pipeline does and where it breaks.