DEV Community: Azamat Safarov

Chrono-Ledger Architecture: A Technical Deep-Dive into State Registries on Public Blockchains

Azamat Safarov — Sat, 19 Sep 2026 22:25:02 +0000

State registries — land cadastres, corporate databases, identity systems — are among the oldest information systems in existence. They also share a hidden architectural assumption that would be considered unacceptable in any other distributed system: that the custodian won't rewrite history.

Together with Maxim Osovsky, I published a paper that formalizes an alternative: Chrono-Ledger Architecture. This post is a technical deep-dive — what follows is the architecture as the paper develops it, from archival foundations through vulnerability pathways to the formal model, invariants, threat model, and sovereignty argument.

Full paper on SSRN.

1. Archival Resonances: Registries as Political Memory

The paper opens with a thesis that recordkeeping belongs within the machinery of public authority, not at its administrative margin. This has a deep institutional pedigree: Aristotle placed a magistracy for written returns of private contracts among the indispensable offices of the polis. Roman ius archivi joined preservation, evidentiary authority, and sovereign recognition. Hobbes located registry officials among the public ministers through whom the sovereign acts. Weber treated the files as a defining component of the modern bureau.

Three traditions in archival theory structure the problem:

Continuity (Leibniz). The archive as an instrument of government — a record binds the future only if it remains intact, retrievable, and usable as evidence.
Production (Foucault, Stoler). The archive determines what can appear as a statement at all. Archival practice determines what counts as ownership, which documents prove it, and which claims remain invisible.
Authority (Derrida, Mbembe). Archival control is archontic — those who guard it control access, classification, and interpretation. Mbembe: there is no state without its archives.

In an ordinary registry, these three dimensions — continuity, production, and authority — are collapsed into one institutional point. A single custodian decides what may be recorded, how it is interpreted, and whether it remains available. This concentration creates the condition the paper calls documentary death: loss or capture of a record resulting in loss or capture of legal status. Documentary death occurs when three criteria are met simultaneously: (i) the record cannot be restored through ordinary legal process, (ii) authorized parties cannot reconstruct the prior state, and (iii) no competent authority remains to adjudicate claims based on the record.

From these three dimensions, the paper derives three architectural requirements: continuity requires immutable and independently verifiable history; production requires the current legal status to remain reproducible from that history; authority requires every registration, amendment, rectification, or cancellation to identify the competent institution, while separating that power from control over the canonical history.

2. Four Vulnerability Pathways of State Memory

The paper organizes registry failures around four pathways, each analyzed as a pair of problem and architectural response:

1. Physical destruction. If the record is materially concentrated, destroying the medium destroys the proof. Maya codices at Maní, 1562. Armenian property archives in 1915. 44 tons of apartheid records destroyed before the TRC. Post-Soviet privatization in the 1990s: when documentary infrastructure is uncertain, records become weapons for control over assets. Chrono-Ledger responds by requiring the current registry state to be reproducible from a preserved history of legally authorized transitions — replication prevents one custodian's destruction from destroying the evidentiary basis of the state.

2. Custodial capture. Institutional centralization creates an archontic vulnerability: whoever captures the custodian captures the record system. Taliban seizing U.S.-built biometric databases in Afghanistan, 2021. The same vulnerability in fiscal registries — budgets, treasury payments, procurement contracts — historically concentrated in a single ministry. Chrono-Ledger addresses a narrower failure: preservation of prior records should not depend on the continued control or survival of a single institution. This is why the architecture separates history from authority rather than pretending technology can replace sovereignty.

3. Digital centralization. Digitization moves vulnerability from archive rooms to software supply chains, credentials, and outsourced infrastructure. Equifax: 147 million records exposed. SolarWinds: compromised software supply chains reaching government networks. Chrono-Ledger requires confirmed history to be independently verifiable so that unauthorized retroactive modification becomes visible even when an infrastructure component is compromised.

4. Distributed pilots: solve tampering, leave authority unresolved. Georgia's Bitfury/NAPR project added blockchain timestamping without transferring authority over registry content. Sweden's Lantmäteriet pilot tested blockchain for property transactions but remained a pilot. Kazakhstan's tokenization sandbox operates under regulatory supervision. Konashevych's critique sharpens the lesson: these projects anchored hashes but did not make the blockchain itself the authoritative register. A hash proves a document hasn't changed — it cannot decide which title is valid, which court may rectify an entry, or how a rectification enters the canonical sequence. The real problem is institutional: who controls the sequence and who has authority to register, amend, rectify, or cancel entries.

3. Chrono-Ledger Architecture: Core Concept

The four pathways require an architectural answer because each exploits the same coupling: the current legal status reflected in a register depends on record history, while preservation, verification, and correction remain institutionally concentrated.

Chrono-Ledger Architecture binds the current legal status reflected in the register to verifiable history recorded on a public blockchain. Its simplest formulation:

"The registry is the most recent state of its own archive."

Four defining conditions:

Every legally operative registry state derives from an ordered transaction history.
Any participant can independently verify the public records, transitions, and past states that the law requires the registry to disclose.
No single custodian can unilaterally rewrite the authoritative history.
The relation between transaction history and current state is computationally reproducible.

Let Hₙ = (T₁, T₂, …, Tₙ) denote the ordered transaction history after the n-th accepted transaction, where n is ledger-sequence position — not calendar time. In the simple case, the registered state is Sₙ = F(Hₙ).

For bitemporal accuracy, the model uses two time axes. Ledger-sequence position n and legal-effective time τ. The full formulation:

S₍τ,n₎ = F(Hₙ, τ) — the legal state at effective time τ, computed from the transaction history available after sequence position n.

F records and reproduces the outcomes of legally authorized institutional acts. It does not replace their legal interpretation. If the history contains conflicting judicial or administrative acts and no competent institution has resolved the conflict, F returns disputed legal status rather than selecting one act as controlling. The disputed status identifies the competing acts, their dates and jurisdictions, any appeal or suspension, and the competent institution empowered to resolve the conflict.

Correction Without Deletion

An erroneous entry is not removed from history. A subsequent authorized corrective transaction supersedes it, and the current state is recomputed over the full sequence including the correction:

T₁ → T₂ → T₃* → T₄ → C(T₃*) → … → Sₙ

The history remains immutable; the status reflected in the register changes through authorized acts. This distinguishes Chrono-Ledger from conventional databases, where correction often overwrites the record, and from naïve immutability, where errors become permanent law. The architecture makes the alterability of registered legal status compatible with the immutability of record history.

Integrity vs. Validity

The formula separates cryptographic integrity from legal truth. Chrono-Ledger guarantees the integrity of the record history — entries were included as recorded and were not subsequently altered unnoticed. Existing legal and administrative institutions remain responsible for accuracy, authenticity, and legal validity: they establish facts, identify authorized actors, and determine whether a transaction has legal effect.

Three-Layer Separation

The architecture rests on a three-layer separation:

Layer	Content	Property
Record History	Ordered, tamper-evident sequence of entries and changes	Append-only
Current Legal Status	Configuration of rights and obligations after giving effect to history	Deterministically computable
Competent Authority	Institution legally empowered to register, amend, rectify, cancel	Identified in every transaction

Conventional registries collapse these layers into one institutional structure. Chrono-Ledger separates them: record history is append-only, the status reflected in the register changes through legally authorized acts, and the competent institution is identified in every transaction.

Prior Art and Differentiation

The closest antecedent in the academic blockchain-registry literature is Konashevych's cross-blockchain protocol for public registries (2020), which combines a standard database with several blockchains serving as immutable logs, while smart laws and digital authorities handle enforceability and correction. It shares three features with the present model: a blockchain-agnostic substrate, separation of transactional integrity from legal validity, and correction of erroneous entries through subsequent authorized entries.

Chrono-Ledger differs in three respects:

Archival theory as a design frame. Konashevych treats the problem as data integrity and tokenization. Chrono-Ledger derives architectural requirements from the political theory of archives and frames the problem as one of state memory.
Vulnerability typology. The four pathways connect architectural choices to historically observed registry failures. Konashevych critiques existing pilots and proposes a cross-blockchain protocol, but does not organize registry failures into a vulnerability typology linking each architectural response to the failure mode it addresses.
Institutional distribution of authority. Konashevych develops smart laws and digital authorities. Chrono-Ledger isolates the institutional control over the canonical sequence as an independent architectural layer. The six invariants and the adversarial model have no counterpart in Konashevych's framework.

4. Implementation Models

The paper compares Chrono-Ledger against conventional architectures using three cumulative tests: open verification, consensus over one canonical sequence, and validator membership independent of the institutions empowered to alter the register.

Architecture	Open verification	Canonical consensus	Validator independence	Result
Centralized DB	No	Operator-selected	No validator set	Fails
WORM archive	Limited	No	No validator set	Fails
Event sourcing	Usually operator-defined	Operator-selected	No validator set	Fails
Audited append-only DB	Auditor-dependent	Operator-selected	No validator set	Fails
Transparency log with witnesses	Yes	No endogenous consensus	Witness set separately governed	Fails
Permissioned BFT database	Permission-dependent	Yes, within admitted set	No — membership predefined	Fails
State permissioned ledger	Permission-dependent	Yes, within admitted set	No — state appoints validators	Fails
Public permissionless blockchain	Yes	Yes	Yes	Passes

Only a public permissionless blockchain combines verification open to any participant, consensus over a single canonical sequence, and validation whose membership is not appointed by the institutions authorized to alter the register.

Event sourcing reproduces state from history but leaves one operator as arbiter of the authoritative sequence. Transparency logs provide public inclusion and consistency proofs, but rely on separately governed logs, monitors, witnesses, or gossip to detect equivocation — they do not themselves establish one permissionless consensus over a canonical sequence. Permissioned BFT databases tolerate a bounded number of faulty nodes, but membership and ultimate control remain within a predefined administrative domain.

Consortium Model

A multi-institutional consortium model implements Chrono-Ledger with institutionally distributed authorization. Five roles:

Role	Power	Cannot
Registry agencies	Authorize ordinary transactions with institutional keys	Control canonical history
Courts	Authorize correction or annulment transactions	Issue ordinary registrations
Municipalities / local registrars	Attest local facts	Override court rulings
Audit office	Oversee key rotation and procedural compliance	Authorize transactions
Observer nodes	Independently verify public blockchain history	Alter the ledger

No single role can authorize, submit, correct, and erase the same transaction. The public blockchain serves as the operational layer — every authorized transition is recorded on-chain, and under its consensus assumptions, its independent validator set makes alteration of the canonical record history publicly detectable without depending on any single registry institution.

Blockchain Substrate Selection

Having established the canonical-layer requirements, selecting among qualifying public blockchains requires a second-stage assessment of six properties: distribution of validation power, finality, data availability, throughput, cost, and compatibility with the registry's disclosure rules.

Specific considerations by network:

Solana: parallel execution + PoH/PoS design makes it a candidate for frequent transitions, but validator distribution must be assessed, not inferred from throughput.
Ethereum rollups: move execution from L1 while retaining settlement on-chain. Suitability depends on sequencer control, proof design, withdrawal latency. A rollup qualifies only if its complete canonical history remains reconstructible and no registry institution can control the accepted sequence through the sequencer or upgrade mechanism. Validium introduces off-chain data availability dependency under different security assumptions.
Polkadot: application-specific execution with shared security, but canonical history must live within the shared-security arrangement, not a separately controlled parachain.
Avalanche: rapid probabilistic finality, but custom subnets qualify only when validator membership remains independent of registry institutions.
Bitcoin: slower probabilistic settlement with strong external anchoring — better suited to periodic commitments than high-frequency operational transitions. An anchor alone does not make the underlying registry a Chrono-Ledger if the complete authorized sequence remains under unilateral custodial control.

5. Architectural Invariants and Threat Model

The architecture is stated as six operational invariants that translate the defining conditions into implementation requirements:

Integrity. For all n, Hₙ is append-only — any modification of a past transaction is detectable by any party with read access.
Open verification. Any participant may verify the public records, transitions, and past states that the law requires the registry to disclose.
Reproducibility of registered legal status. Sₙ is the deterministic output of F applied to Hₙ. If Hₙ contains unresolved conflicting acts, F returns disputed status with references to every competing act. F does not select a prevailing claim. The status changes only when a competent institution issues a legally operative resolution.
Competent authority. A transaction Tᵢ is admissible only if signed by an institutional key holder empowered under the applicable law and jurisdiction-specific rules.
Correction transparency. C(Tⱼ) does not delete Tⱼ from Hₙ. It appends, and Sₙ is recomputed over the full sequence including C(Tⱼ).
Non-exclusivity. No single institutional role can both authorize a transaction and control the canonical record history.

Chrono-Ledger therefore requires a sufficiently numerous and independently controlled validator set, such that no feasible colluding group can control the canonical sequence.

Adversarial Model

The adversary may: (i) compromise an institutional authorization key; (ii) issue authorized but false transactions through oracle failure; or (iii) instruct a captured sovereign to abandon the chain for a rival fork.

Key compromise can permit false but formally authorized entries until the key is revoked. The ledger preserves those entries and any subsequent correction as auditable evidence but cannot determine their factual truth. A large and independently controlled public validator set guarantees the integrity of the canonical record history by preventing any single registry institution from unilaterally rewriting the accepted sequence.

In an authority fork, the architecture guarantees technical persistence but not legal continuity: a captured sovereign can fork the chain, while the pre-fork history survives as an independently verifiable record for transitional-justice or successor-state audit.

6. Sovereignty and the State

Sovereignty, as the paper defines it for this argument, refers specifically to the state's legally recognized capacity to produce binding institutional decisions — the authority to determine what counts as a valid legal act — not to exclusive physical custody of records.

The sovereignty objection is direct: if the state no longer controls the registry alone, has sovereignty been weakened?

The answer: Chrono-Ledger reconfigures the state's role from custodian of records to authorized participant in a public blockchain protocol whose integrity is maintained by independent consensus. The state retains authority to determine which transactions are legally authorized; what it loses is unilateral power to alter authoritative history. This redistributes power within sovereignty rather than delegating sovereignty away.

As Bodin and Jellinek established, sovereignty is a negative boundary — it defines what no external power may override, not a catalogue of operational tasks the state must perform itself. Chrono-Ledger follows this logic at the registry layer. The state does not acquire a new power of authorization. What changes is the record layer after authorization. Once a transaction is signed and submitted to a public chain whose consensus is maintained by independent validators, no single custodian — including the state itself — can silently alter or destroy the evidence of what was authorized. The sovereign function of determining legal validity is untouched; the custody function that enabled retrospective control over the record is redistributed.

The most direct counterargument concerns the sovereign exception: if consensus rules prevent the state from altering a record during war, revolution, or catastrophic oracle failure, the protocol appears to determine when the rules may bend. The architecture's answer: the state may cease using the chain or fork it, but cannot thereby erase the independently verifiable pre-fork history. Sovereign action remains possible under more demanding conditions of accountability. Departure from the recorded sequence becomes a visible public act.

Architectural trust does not replace institutional trust. Citizens who distrust a state have no automatic reason to trust a protocol written and operated by its contractors. Verifiability can nevertheless be relocated from particular custodians to procedures, allowing trust in the record to survive failures of trust in those custodians. Where both forms of trust fail together, the architecture protects the past as evidence but cannot restore the present as authority.

7. Conclusion

Recording, preserving, and reproducing property rights is a constitutive function of the state. Law operates across time only to the extent that later institutions can establish what was decided earlier, by whom, and with what continuing effect. History shows that every record architecture — from the guarded document to the bureaucratic archive, from the centralized database to the DLT pilot — eliminates one vulnerability and opens another, because in each of them the record history, the legal status reproduced from it, and the authority to alter that status remain with the same party.

The answer is architectural and reduces to three requirements. The current legal status must be reproduced from a replicated, cryptographically linked sequence of authorized transitions open to independent verification. Record history, legal status, and authority must be separated: the canonical sequence can and must be maintained by validators independent of the institutions empowered to alter the register, while the question of legal validity remains with the competent institutions under applicable law. Correction must take the form of a later authorized transaction, never the deletion of the past: history is immutable, status is alterable, and these two properties are compatible.

The architecture's contribution stated precisely: blockchain does not produce truth, legality, or trust automatically — these remain the province of existing institutions. The architecture does something different: it renders the history of property-rights records non-rewritable by any single custodian, legal status recomputable from that history, and the authority to alter it recorded and auditable. Where an error enters the register, correction adds to the history rather than erasing from it.

At the scale of state registries — land cadastres, corporate registrations, and identification systems — this would mark a different form of institutional resilience: state memory would no longer depend on a discrete archive but on a distributed, self-verifying foundation of legal reality. The design of that archive is part of the design of sovereignty.

Safarov, A. I., & Osovsky, M. (2026). From Archive to Architecture: Chrono-Ledger and the Institutional Logic of State Memory. SSRN.
Full paper. CC BY 4.0.

Hermes Agent Skills Hub: Why I Stopped Calling It a 'Prompt Marketplace'

Azamat Safarov — Mon, 08 Jun 2026 10:41:12 +0000

🧩 Hermes Agent Skills Hub: Real CLI Tools, Not Prompts

Why I'm Writing This

I use TouchDesigner — a nod-based environment from Derivative where you build everything from nodes: CHOPs for data, SOPs for geometry, TOPs for textures, COMPs for components. You can do generative art, data visualization, VJ sets, interactive installations, real-time video processing. Download it free — the non-commercial license covers most use cases.

I have NewProject1.toe open on my desktop right now. datto1 CHOP, hessen_geo geoCOMP holding a dot Sphere SOP, render1 and cam1 — a basic scene I spin up when testing ideas.

I also use Hermes Agent — an AI agent from Nous Research that works through CLI and recently got a desktop version on Electron. I give it tasks, it executes them through terminal, browser, API. It has skills — extensions that add new tools.

I realized something: TouchDesigner can visualize literally anything. Feed it data — it draws. Feed it text — it renders. Feed it a 3D model — it shows it. The only question is how to get and process that data.

Hermes can process text, code, web data, run scripts. But it can't draw. TouchDesigner can draw, but it can't think.

So I thought: what if I connect them? Through MCP (Model Context Protocol). So Hermes can send data to TouchDesigner, TouchDesigner can respond, and the whole thing works as one organism.

This isn't just a nice idea. It's a practical need: I want my AI agent to visualize its work in real-time, right in TD. And I want to control TD from my Hermes chat.

That's when Skills Hub appeared.

What Skills Hub Actually Is

Nous Research launched Skills Hub — a catalog of skills for Hermes Agent. I opened it and realized: this isn't a prompt catalog like I initially thought. These are real CLI tools you can install and invoke directly from a session.

Not "ask the agent to do something." Install a skill — and you get a new command.

The Numbers Are Messy (I Want to Be Honest)

The original tweet from @Fluyeporlaweb says "89 built-in, 81 optional, 521 community." My own screenshot shows different numbers: 74 built-in, 95 optional, and 90,576 community entries (including third-party registries). The discrepancy probably means the tweet was posted after the screenshot was taken — the hub refreshes twice daily. I'm going with ~691 as the working estimate.

Source	What	Screenshot	Tweet
Built-in	Ships with Hermes	74	89
Optional	Install separately	95	81
Community	All registries	90,576 (all)	521 (curated)
Registries	Data sources	Built-in + Optional + Anthropic + OpenAI + HuggingFace + NVIDIA + skills.sh (19,956) + ClawHub (69,471) + browse.sh (377) + LobeHub (505) + gstack (52)

What These Skills Actually Do

Here are concrete examples I found on the first page:

macos-computer-use

Takes desktop screenshots, moves mouse, types keys, scrolls. Runs in background without stealing focus. This is not "instructions for controlling macOS." It's a real headless UI driver. I've tested it — it actually clicks on my screen while I work in another window.

comfyui

Generates images, video, and audio via ComfyUI from inside a Hermes session. Not "ask ComfyUI nicely" — actual pipe calls through CLI. I've installed it, it works.

humanizer

Strips passive voice, AI clichés, and generic phrasing from text. Returns text that doesn't look generated. I've used it for Telegram posts.

popular-web-designs

54 real design systems (Stripe, Linear, Vercel, etc.) as deployable HTML/CSS templates. Not links to articles — actual code.

claude-code / codex

Delegates coding tasks to Claude Code CLI and OpenAI Codex CLI respectively. Hermes doesn't try to write the code itself — it hands the task to the right specialist.

manim-video

3Blue1Brown-style math/algorithm visualizations. These are Python scripts that render video.

excalidraw

Hand-drawn architecture diagrams from text descriptions. I've used it for post diagrams.

ascii-video

Converts any video to colored ASCII MP4 or GIF.

touchdesigner-mcp

And this is the most interesting one for me. Controls a running TouchDesigner instance through MCP. Two channels: one for sending data to TD, one for receiving. This is exactly what I was thinking about at the start of this article.

The Compatibility Part That Matters

These aren't Hermes-only plugins. They work through the standard MCP (Model Context Protocol), meaning you can also install them in:

Claude Code
Cursor
Codex
OpenCode
Any MCP-compatible agent

Hermes is the coordinator, not the sole consumer.

What Changed for My TouchDesigner Workflow

Before: I wrote a Python script outside TD, ran it, then manually moved the result into TD through DAT or CHOP.

Now: I can tell Hermes "visualize this API data in TD", Hermes installs the right skills (or uses existing ones), data flows through MCP directly into TD — into a CHOP or TOP — and TD draws in real-time.

Or the reverse: TD sends data (e.g., audio spectrum) through MCP to Hermes, Hermes analyzes and responds.

Price

Zero. Open source. No paywall, no token credits per call. The Hermes repo has 186k stars and 31.9k forks.

The Hub Website Is Down

The Skills Hub website (hermes-agent.nousresearch.com/skills) is currently returning an error. I checked myself — right now. But the repository is fully active and hermes skills install works from CLI. The website is a wrapper, not the product itself.

Bottom Line

Skills Hub makes Hermes not just a "chatbot with terminal access" but a platform with an ecosystem. And for me, this is concrete: I can now connect my TouchDesigner with an AI agent through a standard protocol, without writing a single line of integration code.

This is not a "prompt marketplace." This is a toolkit I can use right now.

Source: X/Twitter post by @Fluyeporlaweb

TouchDesigner: derivative.ca | Download

Skills Hub: hermes-agent.nousresearch.com/skills (site temporarily down)

Hermes Docs: hermes-agent.nousresearch.com/docs

Hermes Desktop: hermes-agent.nousresearch.com/desktop

GitHub: github.com/NousResearch/hermes-agent

My Telegram: t.me/azamat_dasein

Hermes Agent Burned 603M Tokens Behind My Back — I Cut Background Costs by Up to 125x

Azamat Safarov — Tue, 02 Jun 2026 00:03:08 +0000

Last Tuesday I noticed my Ollama Cloud Pro quota draining faster than usual. Way faster. I had burned through 603 million tokens in seven days without understanding where they went.

I opened my Hermes Agent logs and found something I did not know existed: an auxiliary: block with twelve background tasks. Compression, web extraction, vision, session search, skills matching — all running silently every time I typed a message. Every task was set to provider: auto. And because I had no API keys for the fallback chain, every one silently fell back to kimi-k2.6, my one-trillion-parameter main model.

I had no idea this was happening. The agent was sending eleven background prompts to the same model I was actively chatting with, through the same quota, without showing me the prompts. Compression alone fired 10–20 times per long session, each pass sending the full conversation history.

This is what I fixed immediately.

The Fix

Here is what I changed in the auxiliary block of my ~/.hermes/config.yaml. The complete YAML is in the Full Config section below.

Apply with /reset or restart Hermes. Config changes only take effect on new sessions.

If you just want the config and don't care about the story, jump to Full Config below, copy it, /reset, done.

How the Routing Works

Twelve tasks used to collapse into one trillion-parameter model. Now they are distributed across six models, from 8B to 1T.

What `provider: auto` Actually Does

I searched dozens of Hermes guides online. Not a single one mentions the auxiliary block. The official docs describe the YAML structure, but there's no warning that provider: auto silently falls back to your main model. I only found one video by AI Garage discussing this — nothing else. No blog posts, no Discord threads, no Reddit discussions.

The auto chain is: openrouter → new portal → codex → gemini flash. If none of these backends have an API key configured, it falls back to your main chat model.

So while I was typing one message to k2.6, the agent was sending eleven others to the same model through the same quota, without showing me the prompt. Compression alone was firing 10–20 times per long session, sending the full conversation history every time.

My Ollama Cloud Pro Catalog

I have an Ollama Cloud Pro subscription. Here are the models available in my catalog that matter for routing:

Model	Size	Strength	Best for
`kimi-k2.6`	~1T params, 256K context	Reasoning, architecture, debugging	Main chat only
`kimi-k2.5`	~1T params	Same family, optimized for long context	Summarization, compression
`qwen3-vl:235b-instruct`	235B params	Multimodal (vision + text)	Screenshots, image analysis
`deepseek-v4-flash`	~20B params	Fast, good at structured output	Safety checks, classification
`gemma3:12b`	12B params	Lightweight, fast	Triage, profile tasks
`rnj-1:8b`	8B params	Cheapest in catalog	Titles, search, skills matching
`gemma4:e2b`	2B params	Smallest	Not used — too weak for any auxiliary task

I pulled all of these and tested them against the twelve auxiliary tasks. The routing below is the result of that testing.

Twelve Background Tasks

My Hermes version has twelve auxiliary tasks. I ordered them by how much they cost in practice:

#	Task	What it does	Why it costs money
1	`compression`	Summarizes conversation when context exceeds limits	Fires 10–20 times per long session. Each pass sends the full conversation history.
2	`web_extract`	Strips HTML boilerplate after `web_search`	Fires every time you search the web.
3	`vision`	Processes screenshots and images	Multimodal tokens are expensive.
4	`flush_memories`	Writes facts to memory files on `/new` or `/exit`	Runs at every session end.
5	`kanban_decomposer`	Breaks Kanban tasks into steps	Medium complexity, runs on board operations.
6	`curator`	Analyzes skill quality and redundancy	Heavy analysis task.
7	`session_search`	Searches past sessions and summarizes matches	Runs when you look up old conversations.
8	`skills_hub`	Matches your query to installed skills	Runs on most questions.
9	`triage_specifier`	Classifies incoming messages	Binary classification.
10	`approval`	Binary safety check before terminal commands	Simple yes/no on safety.
11	`profile_describer`	Generates profile bio	Rare, lightweight.
12	`title_generation`	Auto-names new sessions	Trivial, runs constantly.

Note: older Hermes versions (like the one in the AI Garage video below) show eight tasks. My version has twelve — four were added in recent updates.

How I Mapped Models to Tasks

The logic is dead simple: put the lightest model that doesn't break on each task, and keep k2.6 for actual conversations.

Task	Model	Why this one
Main chat	`kimi-k2.6`	Architecture, debugging, discussion. The only task that actually needs a trillion parameters.
Compression, web_extract, kanban, curator	`kimi-k2.5`	Same Kimi family, optimized for long context. Summarization quality stays high. Using k2.6 for compression was burning quota for no quality gain.
Vision	`qwen3-vl:235b-instruct`	Only multimodal model in the catalog at this level. No alternative exists for image analysis.
Triage, profile	`gemma3:12b`	12B params vs 1T. Classification and bio generation do not need reasoning depth.
Approval	`deepseek-v4-flash` (~20B)	Binary safety check. Fast response time matters more than reasoning quality.
Titles, search, skills, MCP	`rnj-1:8b`	8B params. 125 times lighter than k2.6. The bulk of the savings are here — these tasks run constantly but need minimal intelligence.

What I Tried First: Local Models

Before settling on cloud routing, I tried running auxiliary tasks locally. I already had gemma4:e2b pulled via Ollama on my machine.

RTX 5070 Ti, 8 GB VRAM. One 6B-parameter model fits. Two is already borderline. Every time Hermes switched from compression to approval, Ollama unloaded one model and loaded another. Five to ten seconds of dead air. The GPU fan kicked in. I lost more time waiting for model swaps than I saved on tokens. I abandoned local auxiliary models the same day.

The Numbers

Here is what the routing actually means in terms of model size:

Task	Before (default)	After (routed)	Reduction
Titles, search, skills, MCP	`kimi-k2.6` (~1T)	`rnj-1:8b` (8B)	125x lighter
Triage, profile	`kimi-k2.6` (~1T)	`gemma3:12b` (12B)	83x lighter
Approval	`kimi-k2.6` (~1T)	`deepseek-v4-flash` (~20B)	50x lighter
Compression, web_extract	`kimi-k2.6` (~1T)	`kimi-k2.5` (~1T)	Same family, frees k2.6 for chat
Vision	`kimi-k2.6` (~1T)	`qwen3-vl` (235B)	Dedicated multimodal model

The video by AI Garage measured compression cost directly: Claude Opus at 50K context = 13 cents per pass. Kimi K2 for the same task = 1.9 cents. That is an 85% reduction for a single compression pass. Compression fires 10–20 times per day for heavy users. The author estimated that with default settings, compression alone can cost $60/month with Claude Opus. Routed to a cheaper model, it drops to $9/month.

I cannot confirm exact dollar savings for Ollama Cloud — they do not expose per-call pricing. But the scale difference is unambiguous.

Current Status

Component	Status	Notes
Heavy auxiliary on k2.5	Working	Compression and web_extract no longer block the main model
Vision on qwen3-vl	Working	Only multimodal option available
Medium tasks on gemma3:12b	Working	Triage and profile classification
Approval on deepseek-v4-flash	Working	Fast binary decisions
Light tasks on rnj-1:8b	Working	Titles, search, skills, MCP
`provider: auto` removed	Done	Explicit provider on every task
Local Ollama auxiliary	Abandoned	VRAM contention on 8 GB laptop
Cost tracking per task	Not possible	Ollama Cloud does not expose per-call pricing

Sessions no longer pause for Compressing messages. The token counter stopped monopolizing k2.6. Quota exhaustion mid-session is gone.

Full Config

Here is the complete auxiliary: block from my ~/.hermes/config.yaml:

auxiliary:
  compression:
    provider: ollama-cloud
    model: kimi-k2.5
    timeout: 120
  web_extract:
    provider: ollama-cloud
    model: kimi-k2.5
    timeout: 360
  kanban_decomposer:
    provider: ollama-cloud
    model: kimi-k2.5
    timeout: 180
  curator:
    provider: ollama-cloud
    model: kimi-k2.5
    timeout: 600
  vision:
    provider: ollama-cloud
    model: qwen3-vl:235b-instruct
    timeout: 120
    download_timeout: 30
  triage_specifier:
    provider: ollama-cloud
    model: gemma3:12b
    timeout: 120
  profile_describer:
    provider: ollama-cloud
    model: gemma3:12b
    timeout: 60
  approval:
    provider: ollama-cloud
    model: deepseek-v4-flash
    timeout: 30
  title_generation:
    provider: ollama-cloud
    model: rnj-1:8b
    timeout: 30
  session_search:
    provider: ollama-cloud
    model: rnj-1:8b
    timeout: 30
    max_concurrency: 3
  skills_hub:
    provider: ollama-cloud
    model: rnj-1:8b
    timeout: 30
  mcp:
    provider: ollama-cloud
    model: rnj-1:8b
    timeout: 30

Try It

If you run Hermes Agent and have never touched the auxiliary block:

hermes config edit

Find auxiliary:. Set explicit provider and model for every task — the one that handles it without dragging extra parameters. Save. Run /reset.

Then tomorrow run hermes insights --days 1. Your main model should stop eating the entire token budget.

If you use Claude or another frontier model as your main provider, the default config is even more expensive — every background task inherits that model. Route them to smaller models. Or go local if your hardware handles it.

What auxiliary routing are you using? Drop it in the comments.

LinkedIn — https://www.linkedin.com/in/azamat-safarov-4a37b93a7/

X / Twitter — https://x.com/Azamat__Safarov

Automating NotebookLM with Hermes Agent: From Research to Multi-Platform Content

Azamat Safarov — Wed, 27 May 2026 13:23:16 +0000

Automating NotebookLM with Hermes Agent: From Research to Multi-Platform Content

I write every day. NotebookLM made the writing smarter — analyzing sources, generating podcasts, building visuals. But getting those artifacts out of Google and into my publishing pipeline still took 30 minutes of manual clicking and downloading. I fixed that by wiring NotebookLM directly into Hermes Agent. Now research turns into publish-ready content in about two minutes.

The Problem I Was Solving

NotebookLM is one of the best research tools Google has shipped. Drop in a PDF, a few URLs, or a research query and it builds a notebook — a living summary you can chat with, quiz, or turn into artifacts.

But here is where it breaks for daily publishing. After NotebookLM generates a podcast, a mind map, or a slide deck, you are back to manual mode. Visit the site. Click each artifact. Download. Rename. Move to the right folder. Format for the platform you are posting to. I was spending nearly half an hour on this for every article. The AI did the creative work; I did the file management.

Worse, the standard approach for automating this — browser automation via Playwright — hits a wall. Google detects headless Chromium and Firefox instantly. The login page throws "browser not secure" and you are done. Every automation script I tried failed at authentication.

I needed a way to run NotebookLM from code, download artifacts programmatically, and route them into my publishing pipeline. Hermes Agent already handled the platform distribution. I just needed the bridge.

The Cookie Export Hack That Works

The only authentication method that survived Google's bot detection was exporting cookies from my real Chrome browser. No headless browsers, no Puppeteer tricks. Just real cookies from a real session.

Here is what works reliably:

Log into notebooklm.google.com in your normal Chrome or Edge
Export cookies for domains google.com and notebooklm.google.com as Netscape format using any cookie-export extension
Convert that text file to Playwright's storage_state.json format
The notebooklm-py wrapper reads that state file and gets a valid token

# convert_netscape_cookies.py
import json, sys, datetime, urllib.parse

netscape_lines = open(sys.argv[1]).readlines()
cookies = []
for line in netscape_lines:
    line = line.strip()
    if not line or line.startswith("#"):
        continue
    parts = line.split("\t")
    if len(parts) < 7:
        continue
    domain, flag, path, secure, expiry, name, value = parts[:7]
    cookies.append({
        "name": name, "value": value, "domain": domain.lstrip("."),
        "path": path, "expires": int(expiry) if expiry.isdigit() else None,
        "httpOnly": "HttpOnly" in flag or "httponly" in flag,
        "secure": "Secure" in flag or "secure" in flag,
        "sameSite": "Lax"
    })

storage = {"cookies": cookies, "origins": []}
with open("storage_state.json", "w") as f:
    json.dump(storage, f, indent=2)

I run this once per session. 23 cookies are enough for full API access. Until Google rotates their auth, this is the only reliable path.

The NotebookLM CLI That Does Everything

Once authenticated, notebooklm-py exposes a clean CLI and Python API. I wrapped this into Hermes skills so the agent can create notebooks, add sources, generate artifacts, and poll for completion without me touching the browser.

Creating a Notebook and Adding Sources

python -m notebooklm create "Philosophy Notes"
# → notebook ID returned

python -m notebooklm source add <notebook-id> https://example.com/article.pdf
python -m notebooklm source add-research <notebook-id> "Stoicism in modern productivity"

Sources can be URLs, local files, Google Drive URLs, or research queries. NotebookLM processes them and builds an indexed knowledge base you can chat with.

Generating Artifacts

Each artifact has its own command and output format.

Artifact	Command	Output	Best For
Audio Overview	`generate audio`	MP3	Podcasts, Telegram voice messages
Infographic	`generate infographic "cover..."`	PNG	Article covers, diagrams, flowcharts
Mind Map	`generate mind-map --instructions "..."`	JSON	Architecture overviews, concept maps
Slide Deck	`generate slide-deck "5 slides..."`	PDF	Presentations, LinkedIn carousels
Quiz	`generate quiz`	Text	Telegram polls, engagement

Note the positional argument for prompts — --prompt does not exist. Most artifacts accept the description as a positional string.

One catch: mind-map does not accept --style or --orientation. Only --instructions. And --wait can time out on slow generations, so I poll separately:

# Launch generation without waiting
python -m notebooklm generate infographic "Cover image for article about..." --orientation landscape --style professional --json
# → {"task_id": "...", "status": "pending"}

# Poll until done
python -m notebooklm artifact poll <task_id>

When the status flips to completed, a Google Cloud Storage URL is returned. I download that asset and route it to the right platform folder.

Wiring It Into the Publishing Pipeline

The full flow in Hermes Agent looks like this:

Source material (markdown, PDFs, URLs)
        ↓
NotebookLM notebook created
        ↓
Sources added → NotebookLM indexes and summarizes
        ↓
Artifacts generated (infographic, mind-map, audio, slides)
        ↓
Hermes downloads, compresses, renames assets
        ↓
Platform-specific routing:
   Dev.to      → full article with embedded infographic
   Telegram    → voice message (audio compressed to 48kbps mono)
   LinkedIn    → carousel from slide deck PDF
   Medium      → essay with timeline / quote cards
   Bluesky     → dense teaser + link to full article
   Mastodon    → threaded summary with cover image

The whole sequence runs as a single Hermes skill. I trigger it with one line: generate notebooklm article for <topic>. The agent creates the notebook, waits for artifacts, downloads them, compresses audio for Telegram's 20 MB limit, and writes platform drafts in parallel.

No more clicking through Google UI. No more drag-and-drop. The AI generates; the pipeline publishes.

A Working Integration Script

Here is the core pattern I use inside the Hermes skill:

from notebooklm import NotebookLMClient
import requests, os, time

client = NotebookLMClient()

# 1. Create notebook
nb = client.create_notebook("Stoic Productivity Analysis")

# 2. Add sources — mix of URLs and research queries
client.add_source(nb.id, source_url="https://example.com/seneca-essay.pdf")
client.add_source(nb.id, source_research="modern applications of Stoic principles")

# 3. Generate cover image (infographic)
artifact = client.generate_artifact(
    nb.id,
    artifact_type="infographic",
    instructions="Dark-themed cover image for a technical article about AI-powered research tools. Ocean color palette."
)

# 4. Poll for completion
task_id = artifact.task_id
while True:
    status = client.poll_artifact(task_id)
    if status.status == "completed":
        break
    time.sleep(10)

# 5. Download
cover_url = status.url
r = requests.get(cover_url)
open("assets/generated/cover.png", "wb").write(r.content)

# 6. Generate audio podcast
audio = client.generate_artifact(nb.id, artifact_type="audio")
audio_task = audio.task_id
# ... same poll pattern ...
audio_url = client.poll_artifact(audio_task).url
r = requests.get(audio_url)
open("assets/generated/podcast.mp3", "wb").write(r.content)

# 7. Compress for Telegram (20 MB limit)
os.system("ffmpeg -i assets/generated/podcast.mp3 -b:a 48k -ac 1 assets/generated/podcast_tg.mp3")

The NotebookLMClient reads the same storage_state.json I built from Chrome cookies. No login step, no browser puppetry. Just API calls against a valid Google session.

Where This Fits in the Larger Stack

NotebookLM is not where content starts — it is where research gets processed. My pipeline already had source material (markdown drafts, PDFs, web pages). NotebookLM adds three things:

Audio Overview — two-voice podcast that I can drop straight into Telegram as a voice message. Compression takes a 30 MB raw file down to 7-10 MB. Voices stay clear at 48 kbps mono.
Infographics — article covers and process diagrams generated from a prompt. Before this I used Python Pillow locally. It worked, but every cover looked like the same template. NotebookLM generates unique styles per article. I just describe what I want.
Mind Maps — architecture and concept maps that I embed in Dev.to and Medium articles. The output comes as JSON with node coordinates, so I can render it or let NotebookLM produce the visual.

I still write the original text. I still decide the angle. But the repetitive work — cover design, audio production, diagram drawing — moved from my desk to the agent's queue.

What Broke Along the Way

Playwright login is dead. Every Chromium and Firefox instance I tried was detected. "Browser not secure" at the Google login screen, every time. The cookie export method is the only survivor.

Wrong prompt syntax. I spent an hour debugging generate infographic --prompt "..." before realizing the flag does not exist. Positional arguments only.

Audio timing. NotebookLM audio generation takes 5-10 minutes. If I use --wait, the CLI sometimes times out after 60 seconds. I now always launch with --json to get the task ID, then poll in a loop until completed.

Image size limits. Bluesky caps images at 2 MB. Raw NotebookLM PNGs are often 2.3-2.8 MB. I run them through ffmpeg for JPEG compression at 800px width before uploading.

Results After Running This

Content production time dropped from research-plus-design-plus-publishing to research-plus-two-minutes. The bottleneck is no longer tooling — it is deciding what to write. NotebookLM handles visuals and audio. Hermes handles routing and platform formatting. I handle ideas.

The full pipeline code and architecture diagrams are in the repository linked below. If you are already using Hermes Agent, the notebooklm skill slots in with two CLI commands and a cookie file.

This whole pipeline runs on the LLM Wiki pattern by Andrej Karpathy — a persistent wiki that the LLM builds and maintains as you go, instead of RAG that re-discovers everything from scratch on every query.

https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f#file-llm-wiki-md

Dev.to
https://dev.to/azamat_safarov_119e17602f/

Medium
https://medium.com/@akutagorasava777

Paragraph
https://paragraph.com/@azamatsafarov/how-i-cut-my-publishing-time-from-thirty-minutes-to-two

X
https://x.com/Azamat__Safarov

Automating NotebookLM with Hermes Agent: From Research to Multi-Platform Content

Azamat Safarov — Wed, 27 May 2026 12:22:13 +0000

Automating NotebookLM with Hermes Agent: From Research to Multi-Platform Content

NotebookLM made the writing smarter — analyzing sources, generating podcasts, building visuals. But getting those artifacts out of Google and into my publishing pipeline still took 30 minutes of manual clicking and downloading. I fixed that by wiring NotebookLM directly into Hermes Agent. Now research turns into publish-ready content in about two minutes.

The Problem Was Mechanical Work

I would finish an article, open NotebookLM, upload sources, wait for generation, then manually download each artifact. Podcast for Telegram. Infographic for cover image. Mind map for architecture section. Each download meant clicking through Google UI, renaming files, moving to assets folder, compressing for platform limits. Half an hour of file management for every article. The AI did the creative work; I did the clicks.

Worse, browser automation failed. Google detects headless Chromium instantly. The login page throws "browser not secure" and blocks every script. Puppeteer, Playwright, Selenium — all detected. I needed a way to run NotebookLM from code without fighting Google's bot detection.

The Solution: Cookie Export

The breakthrough was cookie export. Real Chrome session, real cookies, no headless browser. I log into notebooklm.google.com normally, export cookies as Netscape format using a Chrome extension, convert to Playwright storage state with a Python script. The notebooklm-py wrapper reads that state and gets a valid token. Twenty-three cookies are enough for full API access.

The CLI Workflow

Once authenticated, the CLI exposes clean Python API:

from notebooklm_cli import NotebookLMClient
client = NotebookLMClient(storage_state_path)
notebook = client.create("Research Topic")
client.source_add(notebook.id, "sources/my-article.md")
client.generate_infographic("Cinematic visualization")

The gotcha is timing. Audio generation takes five to ten minutes. The positional argument syntax matters — infographic and slide-deck take prompts as positionals, mind-map only accepts --instructions, audio builds from sources directly.

Key commands that work:

# Create and use notebook
notebooklm create "My Research" --json
notebooklm use <id>

# Add sources
notebooklm source add article.md

# Generate artifacts (positional args)
notebooklm generate infographic "Visual description" --wait
notebooklm generate audio "Podcast" --format deep-dive

# Poll manually for audio
notebooklm artifact poll <task_id>
notebooklm download artifact.mp3 --latest

Integration with Hermes Agent

The full pipeline is one command:

# Hermes Agent skill calls
hermes notebooklm-bridge create-research \
  --sources "articles/*.md" \
  --outputs "cover,podcast,mindmap" \
  --compress-for-platforms

Behind the scenes it runs: create notebook, add sources, generate cover infographic, poll for completion, download, compress audio for Telegram's 20MB limit, write platform drafts in parallel.

What Broke Along The Way

Playwright login is dead for NotebookLM — every Chromium instance detected by Google's bot protection.

Wrong prompt syntax cost an hour debugging --prompt before realizing positional arguments only for most commands.

Audio timing taught me to poll separately instead of waiting — --wait times out after 60 seconds.

Image size limits for Bluesky's 2MB meant ffmpeg compression before upload.

Results

Content production dropped from research plus 30 minutes manual to research plus 2 minutes automated. NotebookLM handles visuals and audio. Hermes handles routing and platform formatting. I handle ideas. The bottleneck is no longer tooling — it is deciding what to write.

Resources

The full pipeline is open source: https://github.com/AzamatSafarov/hermes-notebooklm-bridge

This pipeline runs on the LLM Wiki pattern by Andrej Karpathy — persistent wiki maintained by the LLM as you go, instead of RAG that re-discovers everything from scratch on every query.

Reference: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

Tags: #python #automation #notebooklm #hermes #content-pipeline #ai-tools

Automating NotebookLM with Hermes Agent: From Research to Multi-Platform Content

Azamat Safarov — Tue, 26 May 2026 10:38:27 +0000

The Problem I Was Solving

The Cookie Export Hack That Works

Here is what works reliably:

Log into notebooklm.google.com in your normal Chrome or Edge
Export cookies for domains google.com and notebooklm.google.com as Netscape format using any cookie-export extension
Convert that text file to Playwright's storage_state.json format
The notebooklm-py wrapper reads that state file and gets a valid token

# convert_netscape_cookies.py — one-time setup, reusable
import json, sys, datetime, urllib.parse

netscape_lines = open(sys.argv[1]).readlines()
cookies = []
for line in netscape_lines:
    line = line.strip()
    if not line or line.startswith("#"):
        continue
    parts = line.split("\t")
    if len(parts) < 7:
        continue
    domain, flag, path, secure, expiry, name, value = parts[:7]
    cookies.append({
        "name": name, "value": value, "domain": domain.lstrip("."),
        "path": path, "expires": int(expiry) if expiry.isdigit() else None,
        "httpOnly": "HttpOnly" in flag or "httponly" in flag,
        "secure": "Secure" in flag or "secure" in flag,
        "sameSite": "Lax"
    })

storage = {"cookies": cookies, "origins": []}
with open("storage_state.json", "w") as f:
    json.dump(storage, f, indent=2)
print(f"Converted {len(cookies)} cookies, saved to storage_state.json")

Usage: python convert_netscape_cookies.py exported_cookies.txt

I run this once per session. 23 cookies are enough for full API access. Until Google rotates their auth, this is the only reliable path.

The NotebookLM CLI That Does Everything

Creating a Notebook and Adding Sources

# Create a notebook
python -m notebooklm create "Philosophy Notes"
# → returns notebook ID

# Add sources — URLs, files, research queries
python -m notebooklm source add <notebook-id> https://example.com/article.pdf
python -m notebooklm source add-research <notebook-id> "Stoicism in modern productivity"

Sources can be URLs, local files, Google Drive URLs, or research queries. NotebookLM processes them and builds an indexed knowledge base you can chat with.

Generating Artifacts

Each artifact has its own command and output format.

Artifact	Command	Output	Best For
Audio Overview	`generate audio`	MP3	Podcasts, Telegram voice messages
Infographic	`generate infographic "cover..."`	PNG	Article covers, diagrams, flowcharts
Mind Map	`generate mind-map --instructions "..."`	JSON	Architecture overviews, concept maps
Slide Deck	`generate slide-deck "5 slides..."`	PDF	Presentations, LinkedIn carousels
Quiz	`generate quiz`	Text	Telegram polls, engagement

Note the positional argument for prompts. --prompt does not exist for most artifacts. Infographic, slide-deck, and report accept the description as a positional string. Mind-map only accepts --instructions. Audio accepts a positional topic or nothing — it builds the podcast from your sources directly.

One gotcha: --wait can time out on slow generations (over 60 seconds). I always launch without waiting, get the task ID, then poll separately:

# Launch generation without waiting
python -m notebooklm generate infographic "Dark-themed cover for article about AI research tools, ocean palette" --orientation landscape --style professional --json
# → {"task_id": "...", "status": "pending"}

# Poll in a loop until done
python -m notebooklm artifact poll <task_id>

When the status flips to completed, a Google Cloud Storage URL is returned. I download that asset and route it to the right platform folder.

Wiring It Into the Publishing Pipeline

The full flow in Hermes Agent looks like this:

Source material (markdown, PDFs, URLs)
        ↓
NotebookLM notebook created
        ↓
Sources added → NotebookLM indexes and summarizes
        ↓
Artifacts generated (infographic, mind-map, audio, slides)
        ↓
Hermes downloads, compresses, renames assets
        ↓
Platform-specific routing:
   Dev.to      → full article with embedded infographic
   Telegram    → voice message (audio compressed to 48kbps mono)
   LinkedIn    → carousel from slide deck PDF
   Medium      → essay with timeline / quote cards
   Bluesky     → dense teaser + link to full article
   Mastodon    → threaded summary with cover image

No more clicking through Google UI. No more drag-and-drop. The AI generates; the pipeline publishes.

A Working Integration Script

Here is the core pattern I use inside the Hermes skill:

from notebooklm import NotebookLMClient
import requests, os, time

client = NotebookLMClient()

# 1. Create notebook
nb = client.create_notebook("Stoic Productivity Analysis")

# 2. Add sources — mix of URLs and research queries
client.add_source(nb.id, source_url="https://example.com/seneca-essay.pdf")
client.add_source(nb.id, source_research="modern applications of Stoic principles")

# 3. Generate cover image (infographic)
cover = client.generate_artifact(
    nb.id,
    artifact_type="infographic",
    instructions="Dark-themed cover image for a technical article about AI-powered research tools. Ocean color palette."
)

# 4. Poll for completion
task_id = cover.task_id
while True:
    status = client.poll_artifact(task_id)
    if status.status == "completed":
        break
    if status.status in ("failed", "error"):
        raise RuntimeError(f"Artifact failed: {status.error}")
    time.sleep(10)

# 5. Download
cover_url = status.url
r = requests.get(cover_url)
open("assets/generated/cover.png", "wb").write(r.content)

# 6. Generate audio podcast
audio = client.generate_artifact(nb.id, artifact_type="audio")
audio_task = audio.task_id
while True:
    status = client.poll_artifact(audio_task)
    if status.status == "completed":
        break
    time.sleep(10)

# 7. Download
audio_url = status.url
r = requests.get(audio_url)
open("assets/generated/podcast.mp3", "wb").write(r.content)

# 8. Compress for Telegram (20 MB limit)
os.system("ffmpeg -i assets/generated/podcast.mp3 -b:a 48k -ac 1 assets/generated/podcast_tg.mp3")

The NotebookLMClient reads the same storage_state.json I built from Chrome cookies. No login step, no browser puppetry. Just API calls against a valid Google session.

Where This Fits in the Larger Stack

NotebookLM is not where content starts — it is where research gets processed. My pipeline already had source material (markdown drafts, PDFs, web pages). NotebookLM adds three things other tools do not:

Audio Overview — two-voice podcast generated from your sources. I drop this straight into Telegram as a voice message. Compression takes a 30 MB raw file down to 7-10 MB. Voices stay clear at 48 kbps mono.
Infographics — article covers and process diagrams generated from a text description. Before this I used Python Pillow locally. It worked, but every cover looked like the same template with slightly different text. NotebookLM generates unique styles per article. I just describe what I want.
Mind Maps — architecture and concept maps that I embed in Dev.to and Medium articles. The output includes node coordinates in JSON, so I can render it or let NotebookLM produce the visual directly.

I still write the original text. I still decide the angle and the argument. But the repetitive work — cover design, audio production, diagram drawing — moved from my desk to the agent's queue.

What Broke Along the Way

Playwright login is dead. Every Chromium and Firefox instance I tried was detected by Google. "Browser not secure" at the login screen, every time. The cookie export method is the only approach that still works.

Wrong prompt syntax. I spent an hour debugging generate infographic --prompt "..." before realizing the flag does not exist. Positional arguments only. For mind-map, use --instructions.

Image size limits. Bluesky caps images at 2 MB. Raw NotebookLM PNGs are often 2.3-2.8 MB. I run them through ffmpeg for JPEG compression at 800px width before uploading. Yes, ffmpeg — it handles image scaling too.

Results and What Changed

Content production dropped from research plus design plus publishing to research plus about two minutes. The bottleneck is no longer tooling — it is deciding what to write. NotebookLM handles visuals and audio. Hermes handles routing and platform formatting. I handle ideas.

The full pipeline code is open-source:

https://github.com/AzamatSafarov/hermes-notebooklm-bridge

It includes the cookie converter, the one-command pipeline, a Chrome bookmarklet for one-click cookie export, and a working example of Hermes Agent integration. If you are already using Hermes, you can slot it in with two CLI commands and a cookie file.

https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f#file-llm-wiki-md

Medium
https://medium.com/@akutagavasora777

Paragraph
https://paragraph.com/@azamatsafarov

X
https://x.com/Azamat__Safarov

Building an Autoposting Pipeline with Hermes Agent: Why Waterfall Beats Parallel, and the Edge Cases Nobody Talks About

Azamat Safarov — Mon, 25 May 2026 07:07:31 +0000

I write every day. Distributing to 8 platforms used to take 50 minutes. Now it takes 90 seconds. Here's what I learned building the pipeline, why waterfall beats parallel, and every API trap that almost made me quit.

The Problem

I write every day. For two years, every article ended the same way: open eight tabs, copy the markdown, strip formatting for Telegram, compress images for Mastodon, rewrite the hook for Bluesky's 300-character limit, paste URLs into each platform, log what went where. Fifty minutes of mechanical work after the creative part was done.

The real cost isn't time. It's context switching. After four hours of writing, switching to "platform adaptation mode" feels like starting a second job. You think "I'll distribute tomorrow" and tomorrow you don't remember what the article was about.

I tried Buffer. Tried Zapier. Both fail on the same two fronts: they don't handle markdown-to-plaintext adaptation (Telegram and VK show **bold** literally, not bold), and they don't support Bluesky AT Protocol or Paragraph GraphQL. For niche platforms, custom publishers are the only path.

So I built one. Eight platforms, four pipeline stages, one command.

Architecture: Why Waterfall, Not Parallel

First attempt was naive: blast all platforms simultaneously. Failed immediately.

The issue is dependency chains. Bluesky teasers need the WordPress URL to build link cards — you can't post a teaser before the canonical article exists. Dev.to and Paragraph have rate limits that, when hit in parallel, cascade into 429 storms across all publishers. One platform choking kills the entire run.

Solution: waterfall with selective concurrency. Four stages, each producing artifacts the next stage consumes.

┌─────────────────────────────────────────────────────────────────────┐
│  PIPELINE: WATERFALL WITH SELECTIVE CONCURRENCY                       │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  Stage 1: Content Adaptation (sequential)                           │
│    → Parse markdown source                                          │
│    → Generate platform-specific variants via Jinja2 templates       │
│    → Compress images per platform limits (FFmpeg)                    │
│                                                                     │
│  Stage 2: Primary Hub (sequential, blocking)                        │
│    → WordPress: publish full article → get canonical URL            │
│    → Dev.to: publish markdown variant → get dev.to URL              │
│                                                                     │
│  Stage 3: Social Teasers (parallel, 4 threads)                     │
│    → Bluesky: 300 chars + compressed image + link                   │
│    → Mastodon: 500 chars + media upload + link                      │
│    → Tumblr: photo post + caption + link                            │
│    → Paragraph: markdown + external image URLs + link               │
│                                                                     │
│  Stage 4: Archive (sequential)                                      │
│    → Git commit with all published URLs                             │
│    → Update LLM-Wiki index                                          │
│    → Write execution log for debugging                              │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

Full architecture: LLM-Wiki vault → adaptation → 20+ platforms. Hermes Agent orchestrates each stage.

Why waterfall? Each stage produces artifacts the next stage consumes. WordPress URL becomes the canonical reference for all social platforms. Without it, you're posting orphaned content that disappears in 48 hours.

Stage 1: Content Adaptation

This is where most pipelines die silently. You can't post the same markdown to Dev.to, Telegram, and Bluesky. Dev.to renders ## headers natively. Telegram shows raw # symbols. Bluesky strips all markdown and shows plain text. Each platform needs its own variant.

I built an adaptation layer with Jinja2 templates — one per platform. The source is always the same markdown file in the LLM-Wiki vault. The adapter reads it, applies platform rules, and generates the variant.

# scripts/adaptation.py
import re
from pathlib import Path
from jinja2 import Environment, FileSystemLoader

TEMPLATES_DIR = Path(__file__).parent.parent / "templates"
env = Environment(loader=FileSystemLoader(TEMPLATES_DIR))

def adapt_for_platform(source_md: str, platform: str) -> str:
    """Generate platform-specific variant from canonical markdown."""
    template = env.get_template(f"{platform}.j2")

    # Platform-specific preprocessing
    if platform in ("telegram", "vk"):
        # Strip all markdown — these platforms don't render it
        text = re.sub(r'\*\*(.*?)\*\*', r'\1', source_md)   # bold
        text = re.sub(r'\*(.*?)\*', r'\1', text)             # italic
        text = re.sub(r'__(.*?)__', r'\1', text)            # underline
        text = re.sub(r'~~(.*?)~~', r'\1', text)            # strikethrough
        text = re.sub(r'\[(.*?)\]\((.*?)\)', r'\2', text)   # links → bare URL
        text = re.sub(r'!\[.*?\]\(.*?\)', '', text)        # remove images
        text = re.sub(r'#{1,6}\s+', '', text)              # remove headers
        return template.render(content=text, has_images=False)

    elif platform == "bluesky":
        # 300 graphemes hard limit — distill to hook + detail + URL
        text = re.sub(r'#{1,6}\s+', '', source_md)
        text = re.sub(r'\*\*(.*?)\*\*', r'\1', text)
        text = re.sub(r'\n+', ' ', text)
        # Leave room for URL (~30 chars)
        return text[:270].strip() + "..."

    elif platform == "devto":
        # Markdown-native but SVG doesn't render
        text = source_md.replace(".svg)", ".png)")  # rough SVG→PNG swap
        return template.render(content=text, tags=extract_tags(source_md))

    elif platform == "wordpress":
        # Full HTML conversion for WordPress REST API
        return template.render(content=markdown_to_html(source_md))

    elif platform == "mastodon":
        # 500 chars, no markdown
        text = re.sub(r'\*\*(.*?)\*\*', r'\1', source_md)
        text = re.sub(r'\n+', ' ', text)
        return text[:470].strip() + "..."

    elif platform == "paragraph":
        # Markdown accepted, but images must be external URLs
        return template.render(content=source_md, images_are_external=True)

    return source_md  # fallback

def extract_tags(md: str) -> list:
    """Extract tags from YAML frontmatter, limit to 4 for Dev.to."""
    match = re.search(r'^tags:\s*(.+)', md, re.MULTILINE)
    if match:
        tags = [t.strip() for t in match.group(1).split(",")]
        return tags[:4]  # Dev.to hard limit
    return ["python", "automation"]

Platform rules (hard-won through failure):

Platform	Markdown	Images	Length Limit	Special Rules
Telegram / VK	Strip all	External URL previews only	~4000 chars	Bare URLs for previews, no markdown
Bluesky	Strip all	Blob upload (2MB max)	300 graphemes	Must count graphemes, not bytes
Mastodon	Strip all	Two-step media upload	500 chars	`POST /api/v1/media` → `id` → `POST /api/v1/statuses`
Dev.to	Native	Must be PNG (SVG breaks)	None	4 tags max, draft mode available
WordPress	HTML	External URLs only (free plan)	None	`posts` scope only, no `media`
Paragraph	Native	External URLs only	None	GitHub raw URLs hotlink-blocked

The adaptation stage takes ~30 seconds — reads source, applies all rules, writes 8 variants. Each variant is git-versioned.

Stage 2: Primary Hub — WordPress & Dev.to

Two platforms publish first. Both produce URLs that downstream platforms need.

WordPress is the SEO anchor. Every social teaser links back to it as canonical source. Social platforms are not indexed by Google; WordPress is. Without it, you're posting orphaned content.

# api/publishers/wordpress.py
import os
import requests

ACCESS_TOKEN = os.environ.get('WORDPRESS_ACCESS_TOKEN')
BLOG_ID = os.environ.get('WORDPRESS_BLOG_ID')

def publish_post(title: str, content: str, featured_image_url: str = None,
                 categories: list = None, tags: str = "") -> dict:
    url = f"https://public-api.wordpress.com/rest/v1.2/sites/{BLOG_ID}/posts/new"
    headers = {
        "Authorization": f"Bearer {ACCESS_TOKEN}",
        "Content-Type": "application/json",
    }
    payload = {
        "title": title,
        "content": content,
        "status": "publish",
    }
    if categories:
        payload["categories"] = categories
    if tags:
        payload["tags"] = tags
    if featured_image_url:
        payload["featured_image"] = featured_image_url

    r = requests.post(url, headers=headers, json=payload, timeout=30)
    data = r.json()

    return {
        "success": "ID" in data,
        "url": data.get("URL"),
        "id": data.get("ID")
    }

Critical limitation: Free WordPress.com plans only grant posts OAuth scope. media scope requires paid plan. Cannot upload images via API on free tier. Workaround: host images externally and reference by URL.

Dev.to is the technical hub. Markdown-native, code blocks work, frontmatter tags auto-categorize. The Dev.to URL becomes the "also published on" link.

# api/publishers/devto.py
import os
import requests

API_KEY = os.environ.get('DEVTO_API_KEY')

def publish_article(title: str, body: str, tags: list, published: bool = False) -> dict:
    url = "https://dev.to/api/articles"
    headers = {
        "api-key": API_KEY,
        "Content-Type": "application/json"
    }

    payload = {
        "article": {
            "title": title,
            "body_markdown": body,
            "published": published,
            "tags": tags[:4]  # Dev.to hard limit: 4 tags max
        }
    }

    r = requests.post(url, headers=headers, json=payload, timeout=30)
    data = r.json()

    if r.status_code == 201:
        return {"success": True, "url": data.get("url"), "id": data.get("id")}
    return {"success": False, "error": data.get("error", f"HTTP {r.status_code}")}

Invisible limits discovered:

4 tags maximum. Sending 5 returns 422 "Tag list exceed the maximum of 4 tags".
SVG images don't render. Dev.to's CDN doesn't process SVG. Convert to PNG via FFmpeg before upload.
Draft mode: published: false creates a draft visible in your dashboard. You review, then hit "Publish" manually.

Both must complete before Stage 3 starts. If WordPress fails, the pipeline halts.

Stage 3: Social Teasers — Parallel

Once WordPress and Dev.to return URLs, four social platforms fire in parallel.

Bluesky: AT Protocol Is Not REST

Bluesky doesn't use REST. It uses AT Protocol — binary blob uploads, record creation via JSON-RPC, 2MB blob size limit.

# api/publishers/bluesky.py
import os
import requests
from datetime import datetime, timezone

HANDLE = os.environ.get('BLUESKY_HANDLE')
APP_PASSWORD = os.environ.get('BLUESKY_APP_PASSWORD')
BASE_URL = "https://bsky.social/xrpc"

def create_session() -> dict:
    r = requests.post(
        f"{BASE_URL}/com.atproto.server.createSession",
        json={"identifier": HANDLE, "password": APP_PASSWORD},
        timeout=30
    )
    data = r.json()
    return {
        "success": "accessJwt" in data,
        "accessJwt": data.get("accessJwt"),
        "did": data.get("did")
    }

def upload_blob(image_path: str, session: dict) -> dict:
    ext = image_path.lower().split(".")[-1]
    mime = {"jpg": "image/jpeg", "jpeg": "image/jpeg", "png": "image/png", "gif": "image/gif"}.get(ext, "image/png")

    with open(image_path, "rb") as f:
        data = f.read()

    r = requests.post(
        f"{BASE_URL}/com.atproto.repo.uploadBlob",
        headers={
            "Authorization": f"Bearer {session['accessJwt']}",
            "Content-Type": mime
        },
        data=data,
        timeout=120  # 1.5MB uploads need time
    )

    blob = r.json().get("blob")
    return {"success": bool(blob), "blob": blob}

def post(text: str, image_path: str = None) -> dict:
    session = create_session()
    if not session["success"]:
        return session

    now = datetime.now(timezone.utc).isoformat().replace("+00:00", "Z")

    record = {
        "$type": "app.bsky.feed.post",
        "text": text,
        "createdAt": now,
    }

    if image_path and os.path.exists(image_path):
        if os.path.getsize(image_path) > 2_000_000:
            compressed = image_path.replace(".png", "-compressed.jpg")
            os.system(f"ffmpeg -y -i {image_path} -q:v 2 {compressed}")
            image_path = compressed

        blob = upload_blob(image_path, session)
        if blob["success"]:
            record["embed"] = {
                "$type": "app.bsky.embed.images",
                "images": [{"alt": "", "image": blob["blob"]}]
            }

    r = requests.post(
        f"{BASE_URL}/com.atproto.repo.createRecord",
        headers={"Authorization": f"Bearer {session['accessJwt']}"},
        json={
            "repo": session["did"],
            "collection": "app.bsky.feed.post",
            "record": record
        },
        timeout=30
    )

    data = r.json()
    if "uri" in data:
        post_id = data["uri"].split("/")[-1]
        return {
            "success": True,
            "url": f"https://bsky.app/profile/{HANDLE}/post/{post_id}"
        }
    return {"success": False, "error": data}

Three traps in this code:

uploadBlob expects raw bytes with Content-Type header — not multipart files={...}. requests.post(..., data=bytes, headers={"Content-Type": "image/png"}) — not files={"image": open(...)}.
Default 30-second timeout is too short for 1.5MB uploads. Increased to 120 seconds after three consecutive failures.
300-grapheme limit is hard. len(text) counts codepoints; Japanese emoji counts as multiple grapemes. Must use regex.findall(r'\X', text) for accurate counting.

Mastodon: Two-Step Media

Mastodon requires separate media upload before status creation.

# api/publishers/mastodon.py
import os
import requests

BASE_URL = os.environ.get('MASTODON_URL')
ACCESS_TOKEN = os.environ.get('MASTODON_ACCESS_TOKEN')

def upload_media(image_path: str) -> dict:
    url = f"{BASE_URL}/api/v1/media"
    headers = {"Authorization": f"Bearer {ACCESS_TOKEN}"}

    with open(image_path, "rb") as f:
        files = {"file": (os.path.basename(image_path), f)}
        r = requests.post(url, headers=headers, files=files, timeout=60)

    data = r.json()
    return {
        "success": "id" in data,
        "id": data.get("id"),
        "url": data.get("url")
    }

def post_status(text: str, media_ids: list = None) -> dict:
    url = f"{BASE_URL}/api/v1/statuses"
    headers = {"Authorization": f"Bearer {ACCESS_TOKEN}"}
    payload = {"status": text}
    if media_ids:
        payload["media_ids[]"] = media_ids

    r = requests.post(url, headers=headers, data=payload, timeout=30)
    data = r.json()

    return {
        "success": "id" in data,
        "url": data.get("url")
    }

Single-call status creation with both text and file does NOT work. Must be two requests.

Tumblr and Paragraph follow similar patterns — media upload first, then post creation with media IDs or external URLs.

Stage 4: Archive & The Orchestrator

Hermes Agent schedules tasks but never autopublishes without explicit approval.

# scripts/orchestrator.py
import sys
from pathlib import Path
from concurrent.futures import ThreadPoolExecutor

sys.path.insert(0, str(Path(__file__).parent.parent))

from api.publishers.bluesky import post as publish_bluesky
from api.publishers.wordpress import publish_post as publish_wordpress
from api.publishers.devto import publish_article as publish_devto
from api.publishers.mastodon import post_status as publish_mastodon, upload_media as upload_mastodon_media
from api.publishers.paragraph import publish_post as publish_paragraph
from scripts.adaptation import adapt_for_platform

def run_pipeline(article_path: str, image_path: str, dry_run: bool = True):
    with open(article_path) as f:
        full_text = f.read()

    # Stage 1: Adaptation
    variants = {
        "wordpress": adapt_for_platform(full_text, "wordpress"),
        "devto": adapt_for_platform(full_text, "devto"),
        "bluesky": adapt_for_platform(full_text, "bluesky"),
        "mastodon": adapt_for_platform(full_text, "mastodon"),
        "tumblr": adapt_for_platform(full_text, "tumblr"),
        "paragraph": adapt_for_platform(full_text, "paragraph"),
    }

    if dry_run:
        print("[DRY RUN] Platform variants generated:")
        for platform, text in variants.items():
            print(f"  {platform}: {len(text)} chars")
        return

    # Stage 2: Primary Hub (sequential, blocking)
    wp = publish_wordpress({
        "title": "Article Title",
        "content": variants["wordpress"],
        "status": "publish",
        "categories": ["Productivity", "Tools"],
        "tags": "automation, python, publishing, hermes"
    })
    canonical_url = wp.get("url")

    dev = publish_devto({
        "title": "Article Title",
        "body_markdown": variants["devto"],
        "published": False,  # Draft for review
        "tags": ["python", "automation", "publishing", "hermes"]
    })

    # Stage 3: Social Teasers (parallel, 4 threads)
    def publish_bluesky_trailer():
        text = f"{variants['bluesky']} → {canonical_url}"
        return publish_bluesky(text, image_path)

    def publish_mastodon_trailer():
        media = upload_mastodon_media(image_path)
        text = f"{variants['mastodon']} → {dev.get('url', canonical_url)}"
        return publish_mastodon(text, [media["id"]] if media["success"] else [])

    def publish_tumblr_post():
        # Tumblr API: photo post with caption
        return publish_tumblr(image_path, variants["tumblr"], canonical_url)

    def publish_paragraph_article():
        return publish_paragraph("Article Title", variants["paragraph"])

    with ThreadPoolExecutor(max_workers=4) as executor:
        futures = {
            "bluesky": executor.submit(publish_bluesky_trailer),
            "mastodon": executor.submit(publish_mastodon_trailer),
            "tumblr": executor.submit(publish_tumblr_post),
            "paragraph": executor.submit(publish_paragraph_article),
        }
        social_results = {k: v.result() for k, v in futures.items()}

    # Stage 4: Archive
    log_publish_results(wp, dev, social_results)
    git_commit_with_urls(wp, dev, social_results)
    update_llm_wiki_index(wp, dev, social_results)

Human-in-the-loop design:

User says "publish this article"
Agent generates all variants, shows previews
User reviews Dev.to draft (most complex variant)
User says "confirmed" — only then API calls execute

This prevents the "oh no I just live-posted a draft" panic. Every publisher has dry_run=True default.

Failure handling: If Bluesky fails, the pipeline logs the error, continues with remaining platforms, reports partial success:

Bluesky: FAILED (blob > 2MB)
WordPress: SUCCESS — https://azamatsafarov.wordpress.com/...
Dev.to: SUCCESS (draft) — https://dev.to/...
Mastodon: SUCCESS — https://mastodon.social/@...

Edge Cases: The Real Curriculum

Edge Case	How I Discovered It	The Fix
Bluesky blob > 2MB	Three consecutive failures Thursday evening, all 400 with no error body	FFmpeg compression: `ffmpeg -y -i input.png -q:v 2 output.jpg`
WordPress free plan blocks media upload	403 on every image upload, docs say "check token scope"	Host images externally, reference by URL
Dev.to SVG broken	Pipeline diagram showed empty box for a week	`ffmpeg -y -i diagram.svg diagram.png` in adaptation stage
Dev.to 5th tag rejected	Got 422, read error, realized the limit	Hard truncate to 4 tags. No negotiation
Mastodon two-step media	Posted text without image three times	Two separate requests: `POST /api/v1/media` → `id` → `POST /api/v1/statuses`
Bluesky 300 graphemes	Posted 305-char teaser, got `"record too large"` with no details	Grapheme counting via `regex.findall(r'\X', text)` before posting
Paragraph hotlink blocking	GitHub raw URLs showed as broken images	VK CDN URLs from `photos.getById` after VK upload
LinkedIn token expires	Posts failed with 401 after 60 days	Manual refresh. Not worth automating for monthly posting
Markdown divergence	Telegram showed `bold` literally, VK showed raw brackets	Strip all markdown for Telegram/VK in adaptation stage
NotebookLM cookies expire	Cron job ran at 11:00, failed silently at auth	Two-step cron: 10:30 reminder → user pastes cookies → 11:00 publish

Results: What Actually Changed

Metric	Before Pipeline	After Pipeline
Time per article	50 minutes (8 platforms × ~6 min each)	90 seconds (automation) + 5 min review
Platforms covered	3–4, depending on energy	8 automated + drafts for 10 more
Failed uploads	~30% (forgot image, wrong format, expired token)	~5% (token expiration only)
SEO indexing	None — social content ephemeral	WordPress as canonical, indexed by Google
Context switching	8 tabs, 8 different UIs, 8 copy-paste operations	One command, one preview, one approval
Article versioning	None — distributed copies diverged	Git tracks every variant, platform, URL

The biggest change isn't speed. It's consistency. Before the pipeline, I distributed to 3–4 platforms depending on how tired I was. The pipeline makes 8 platforms the default. Energy-independent.

DEV Community: Azamat Safarov

Chrono-Ledger Architecture: A Technical Deep-Dive into State Registries on Public Blockchains

1. Archival Resonances: Registries as Political Memory

2. Four Vulnerability Pathways of State Memory

3. Chrono-Ledger Architecture: Core Concept

Correction Without Deletion

Integrity vs. Validity

Three-Layer Separation

Prior Art and Differentiation

4. Implementation Models

Consortium Model

Blockchain Substrate Selection

5. Architectural Invariants and Threat Model

Adversarial Model

6. Sovereignty and the State

7. Conclusion

Hermes Agent Skills Hub: Why I Stopped Calling It a 'Prompt Marketplace'

🧩 Hermes Agent Skills Hub: Real CLI Tools, Not Prompts

Why I'm Writing This

What Skills Hub Actually Is

The Numbers Are Messy (I Want to Be Honest)

What These Skills Actually Do

macos-computer-use

comfyui

humanizer

popular-web-designs

claude-code / codex

manim-video

excalidraw

ascii-video

touchdesigner-mcp

The Compatibility Part That Matters

What Changed for My TouchDesigner Workflow

Price

The Hub Website Is Down

Bottom Line

Hermes Agent Burned 603M Tokens Behind My Back — I Cut Background Costs by Up to 125x

The Fix

How the Routing Works

What provider: auto Actually Does

My Ollama Cloud Pro Catalog

Twelve Background Tasks

How I Mapped Models to Tasks

What I Tried First: Local Models

The Numbers

Current Status

Full Config

Try It

Automating NotebookLM with Hermes Agent: From Research to Multi-Platform Content

Automating NotebookLM with Hermes Agent: From Research to Multi-Platform Content

The Problem I Was Solving

The Cookie Export Hack That Works

The NotebookLM CLI That Does Everything

Creating a Notebook and Adding Sources

Generating Artifacts

Wiring It Into the Publishing Pipeline

A Working Integration Script

Where This Fits in the Larger Stack

What Broke Along the Way

Results After Running This

Automating NotebookLM with Hermes Agent: From Research to Multi-Platform Content

Automating NotebookLM with Hermes Agent: From Research to Multi-Platform Content

The Problem Was Mechanical Work

The Solution: Cookie Export

The CLI Workflow

Integration with Hermes Agent

What Broke Along The Way

Results

Resources

Automating NotebookLM with Hermes Agent: From Research to Multi-Platform Content

The Problem I Was Solving

The Cookie Export Hack That Works

The NotebookLM CLI That Does Everything

Creating a Notebook and Adding Sources

Generating Artifacts

Wiring It Into the Publishing Pipeline

A Working Integration Script

Where This Fits in the Larger Stack

What Broke Along the Way

Results and What Changed

What `provider: auto` Actually Does