标签：#Claude

Anthropic will extend support for watermarking AI generations for older models as well.

Spawning a subagent in Claude Code feels free. It isn't. We measured it across a real review pipeline, and the number that matters is one almost nobody talks about: each subagent costs roughly 436,000 tokens in fixed overhead before it does any useful work. This post explains where that number comes from, how to reproduce the measurement on your own setup, and what it changes about how you should split work between agents. The experiment We run a weekly review pipeline over a catalog of digital products (Markdown-heavy repos: rules files, skills, templates). The pipeline embeds each product's full content into a reviewer prompt and asks for structured findings. We ran the same product, same full content, two ways: Arm A: three subagents , one per review perspective (buyer value, niche accuracy, compliance). Total prompt size: ~314k characters. Arm B: one subagent covering all three perspectives in sequence. Total prompt size: ~105k characters. Billed token totals, from the session transcript: Arm A (3 agents) Arm B (1 agent) Total tokens 2,150,310 809,070 Distinct defect classes found 20 11 Primary-source fetches performed 0 2 Arm B cost 37.6% of Arm A. The naive expectation — "three agents read the same content, so about 3x" — roughly holds, but the reason is not the content. Where the tokens actually go Breaking the transcript down per turn, each agent carried about 436k tokens of overhead that had nothing to do with the review itself : the initial context load at spin-up plus the cache write on its final turn. The embedded product content — the thing we assumed dominated cost — was only about 46k tokens per agent. That's a 9.5:1 ratio of fixed cost to payload. Two consequences fall out immediately: Embedding full content is cheap. We had been truncating embedded files to save tokens, which quietly excluded the files that carried the product's actual value from review. Full-content embedding turned out to cost almost nothing relative to what we were already paying

Screenshot prompting has a ceiling. You paste the design, the model makes a plausible approximation, you correct it, and on the next turn it drifts again. Nothing is anchored. The model has no source of truth to check itself against between turns. A context bundle changes the contract. Instead of a pixel reference the model has to interpret every time, you get a structured, referenceable set of files — design tokens, layout IR, component inventory, UI strings — that stay in the session and stay consistent. Claude Code can read them, implement from them, and check its own output against them on demand. This post walks the full pipeline, from bundle export to a reviewed, token-verified implementation, using figmascope , a browser tool that turns any Figma file into exactly that bundle. What makes this deterministic Three things make the bundle referenceable rather than interpretable: Tokens are typed and keyed. tokens.json maps semantic names ( spacing.16 , color.7f5cfe ) to exact values. The model can check its output against the file without re-processing the design. The IR is a tree, not pixels. screens/home.json describes the layout in terms of stack/overlay/absolute/leaf nodes — the same abstraction the implementation target (Compose, React, etc.) uses. There's no visual interpretation step. The bundle is stable across turns. Once it's in the repo, every prompt in the session can reference the same files. Token drift is detectable: ask the model to compare its output against tokens.json and it can do it mechanically. Step 1: Generate the bundle Open figmascope.dev in your browser. Paste your Figma file URL. The exporter runs client-side using the Figma REST API — your Figma personal access token is stored in localStorage and never sent to figmascope's servers. Click Export Agent Context . The page exports top-level frames, resolves design tokens, builds the IR, and downloads context-bundle.zip . Step 2: Unzip into your project # from your project root unzip ~/Dow

Avoiding "AI Slop" in Design "AI slop" happens when you let artificial intelligence build everything all at once with zero guidance, resulting in generic, corporate-looking interfaces. By taking on the role of a creative director—providing specific style references, establishing a design system, and tweaking the output iteratively—you can steer AI toward unique, high-quality UI. Access & Requirements Before getting started, note where and how to access the tool: Availability: Claude Design 2.0 (Design Labs) is accessible via the Claude Desktop App and web interface. Account Tiers: It requires an active paid plan (Claude Pro, Team, or Enterprise). Free tier accounts do not currently have access to Design Labs. Step 1: Gather Real-World Design Inspiration Before opening any AI tool, establish the visual direction you want to pursue. Browse Live Sites for Style: Use platforms like Mobbin to look at real, production websites rather than static concepts. Filter by Vibe: Search categories by style. For example, selecting a "Fun" filter yields vibrant, interactive sites with custom animations—a sharp contrast to standard corporate templates. Collect Visual References: Take screenshots of specific components (hero sections, cards, layout structures) across different sites that capture your target aesthetic. Step 2: Set Up a Custom Design System in Claude Instead of prompting a full web page from scratch, start by establishing your brand identity inside Claude Design. Launch Design Labs: Open the desktop app, navigate to Design Labs, and select Design Systems > Create Design System . Define Brand Context: Enter your company name and a brief pitch (e.g., FunAddict – We make running fun ). Upload Reference Assets: Drag and drop your curated screenshots directly into the asset uploader. Prompt the System: Instruct Claude to capture the collective mood, colors, and playful UI styles from your screenshots to generate a single, coherent design system. Step 3: Refine Your Design Sy

I have three files in this repo that shell out to something over the network or a subprocess and can fail in interesting ways: publish_devto.py , server.py , and git_commit.py . Two of them have --selftest blocks that stub the risky call and exercise the actual failure branches. One doesn't, and I only noticed because I went looking for a reason to be suspicious of my own test coverage after seeing a trending post about counting assertions in a test suite and not liking what you find. git_commit.py reads a staged diff and calls claude -p to turn it into a commit message. It has five distinct exit paths, all guarding real failure modes I've hit before in this project: try : diff = subprocess . check_output ([ " git " , " diff " , " --staged " ], text = True , timeout = 20 ) except subprocess . TimeoutExpired : print ( " git diff --staged timed out after 20s " , file = sys . stderr ) raise SystemExit ( 1 ) if not diff . strip (): print ( " Nothing staged. Run `git add` first. " ) raise SystemExit ( 1 ) try : raw = subprocess . check_output ( [ " claude " , " -p " , " --safe-mode " , SYSTEM + " \n\n " + diff ], text = True , timeout = 20 , stderr = subprocess . PIPE , ). strip () except subprocess . TimeoutExpired : print ( " claude -p timed out after 20s " , file = sys . stderr ) raise SystemExit ( 1 ) except subprocess . CalledProcessError as e : print ( f " claude -p exited { e . returncode } : { ( e . stderr or '' ). strip ()[ : 200 ] } " , file = sys . stderr ) raise SystemExit ( 1 ) except FileNotFoundError : print ( " claude CLI not found on PATH " , file = sys . stderr ) raise SystemExit ( 1 ) That's a held index lock hanging git diff , an empty staging area, a claude -p call that times out, one that exits non-zero, and one where the claude binary isn't even on PATH . Real scenarios — the timeout on this exact git diff --staged call was itself a bug I'd already found and fixed once ( docs/project_notes/bugs.md , 2026-08-06: a prior fix claimed to add a timeout

Programming with Claude Code will soon require even less human oversight.

Le 1er septembre 2026, le tarif de lancement de Claude Sonnet 5 s'arrête. L'input passe de 2 $ à 3 $ le million de tokens, l'output de 10 $ à 15 $ : +50 % sur les deux lignes, pour tout le monde qui appelle l'API en paiement à l'usage. La panique par défaut, c'est de couper des fonctionnalités ou de rétrograder vers un modèle plus faible. Il y a mieux, et c'est déjà dans l'API. Deux mécanismes — le prompt caching et le batch — encaissent la hausse à ta place, souvent avec de la marge. Voici le code, les chiffres, et les pièges que j'ai payés pour que tu ne les paies pas. Ce qui bouge exactement le 1er septembre Trois lignes suffisent à raisonner. Le reste du barème (Opus, Haiku, contexte 1M) ne change pas. Poste Sonnet 5 (par M de tokens) Jusqu'au 31 août Dès le 1er sept. Input standard 2 $ 3 $ Output 10 $ 15 $ Lecture cache (hit) 0,20 $ 0,30 $ Retiens la troisième ligne, parce que c'est elle qui gagne la partie. Un cache hit coûte 10 % du prix d'input . Même après la hausse, lire depuis le cache à 0,30 $ reste moins cher que l'ancien input plein à 2 $. Autrement dit, le contexte que tu répètes à chaque appel — un system prompt costaud, une doc, des exemples few-shot — peut être payé une fois puis relu pour trois fois rien. Le prompt caching, concrètement Le principe est simple : tu marques un bloc stable avec cache_control , et tout ce qui précède ce marqueur est mis en cache. Le premier appel paie une écriture ; les suivants, dans la fenêtre TTL, lisent à 10 %. import anthropic client = anthropic . Anthropic () DOCS = load_docs () # ~20 000 tokens, identiques à chaque requête def ask ( question : str ): return client . messages . create ( model = " claude-sonnet-5 " , max_tokens = 1024 , system = [ { " type " : " text " , " text " : " Assistant support de l ' app Lumière. " }, { " type " : " text " , " text " : DOCS , " cache_control " : { " type " : " ephemeral " }, # TTL 5 min }, ], messages = [{ " role " : " user " , " content " : question }], ) La question de

Coder à la voix avec ChatGPT, ça marche. Le hic tient en une ligne : chaque mot que tu dictes part chez OpenAI. Depuis le 23 juillet 2026, Codex se pilote à la voix — il ouvre une pull request, cherche l'origine d'un bug, tout ça dans une phrase. Pratique pour un side-project. Rédhibitoire quand le code appartient à un client. On voulait le même confort sans la fuite. Le résultat est un pipeline 100 % local : faster-whisper pour la transcription, Claude Code et sa commande /voice pour l'agent. Rien ne sort de la machine — ni la voix, ni le contexte, ni le code. Voici la config exacte, la latence qu'on mesure sur un M2, et les deux bugs qui nous ont coûté une demi-journée. Pourquoi pas simplement Codex vocal ? Parce que « coder à la voix » cache deux choses qu'on confond tout le temps. Le mode vocal de ChatGPT est fait pour converser : il répond, il temporise, il reformule. Dicter du code, c'est l'inverse — tu veux une transcription fidèle et muette, qui ne discute pas, ne reformule pas et n'ajoute rien à ce que tu dis. Deux gestes opposés. Le vrai stack n'est donc jamais « ChatGPT vocal seul ». C'est un outil de dictée précis d'un côté, un agent de code de l'autre. Codex vocal fait les deux dans le cloud pour 20 €/mois ; un setup local sépare les deux briques et garde tout sur ta machine. Le tour d'horizon complet — prix, outils, cas d'usage — est dans le guide de référence ; ici, on reste sur le terrain technique. Le chemin le plus court : /voice Depuis mars 2026, Claude Code embarque un mode vocal. Tu tapes /voice dans le terminal, tu tiens la barre d'espace, tu parles, tu relâches. La transcription passe par un Whisper local, pas par une API distante. > /voice [hold space to talk · release to send] Pour 90 % des cas, ça suffit. Tu dictes une intention, l'agent écrit le code, tu relis. Si tu veux garder la main sur le modèle, la langue et le vocabulaire technique, il faut descendre d'un cran et brancher ta propre transcription. Le pipeline DIY, brique par brique T

You want to send a screenshot to a vision model. All three of the big ones — OpenAI's GPT-4o, Anthropic's Claude, Google's Gemini — accept images the same fundamental way: Base64-encode the bytes and put them in the JSON request. No file uploads, no multipart, just text in a payload. And yet the single most common error people hit is some flavor of invalid image / could not process image . The reason is almost never the image. It's that each provider wants the Base64 wrapped in a differently shaped object , and the traps are subtle — especially the data: URL prefix, which one provider requires and the other two reject. Here's the exact payload each one wants, side by side. OpenAI (GPT-4o) GPT-4o uses a content array of parts. The image is an image_url part, and — this is the trap — the url field takes a full data URL , prefix and all: import base64 from openai import OpenAI client = OpenAI () with open ( " photo.png " , " rb " ) as f : b64 = base64 . standard_b64encode ( f . read ()). decode ( " utf-8 " ) resp = client . chat . completions . create ( model = " gpt-4o " , messages = [{ " role " : " user " , " content " : [ { " type " : " text " , " text " : " What ' s in this image? " }, { " type " : " image_url " , " image_url " : { " url " : f " data:image/png;base64, { b64 } " }, }, ], }], ) print ( resp . choices [ 0 ]. message . content ) The literal payload shape: { "type" : "image_url" , "image_url" : { "url" : "data:image/png;base64,<BASE64>" } } Note the data:image/png;base64, is part of the value. Send raw Base64 here and it fails. Anthropic (Claude) Claude uses an image content block with a source object. Here the MIME type is a separate field ( media_type ), and the data field wants raw Base64 — no data: prefix : import base64 import anthropic client = anthropic . Anthropic () with open ( " photo.png " , " rb " ) as f : b64 = base64 . standard_b64encode ( f . read ()). decode ( " utf-8 " ) msg = client . messages . create ( model = " claude-opus-4-8 " , m

I manage a dev team, and we've been running Claude Code daily for months. I built a set of custom skills for us — code review, a debugging protocol, our team conventions — and the biggest lesson I learned surprised me: The body of your skill barely matters if the description is wrong. The failure mode nobody warns you about Here's what happens to most developers who discover skills. They get excited, write a detailed 200-line SKILL.md encoding everything they know about code review... and then it never triggers. Not once. They conclude skills "don't really work" and go back to re-typing the same prompt every session. The skill was probably fine. The description killed it. The description is a routing rule, not documentation A skill's description is the only part Claude sees upfront. The full instructions load only after the description matches your request. So the description isn't marketing copy — it's a routing rule, and it needs to be written like one. Compare: # WEAK — reads nicely, never triggers description : Helps with code quality and best practices. # STRONG — names the situations AND the phrasings description : Security-first code review for Python/FastAPI. Trigger when the user asks to "review", "check", or "look at" code, pastes a function or endpoint, mentions a bug, or asks "what's wrong with this". Also trigger on short requests like "review this". The difference: the strong version contains the actual words you type. Including the lazy ones. Nobody writes "please perform a comprehensive quality assessment" at 11pm — they write "review this". If your description doesn't cover the two-word tired version, your skill sleeps through most of your real requests. Three rules that fixed my skills 1. List your real trigger phrases. Open your chat history and look at how you actually phrase requests. Those exact phrases go in the description — "fix it", "what's wrong here", "check this". Your real vocabulary, not your professional vocabulary. 2. Name the artifa

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is...

I used to spend hours rewriting AI-drafted video scripts that sounded nothing like me. At best, I might finish one or two that were just okay, but most of the work was still on my shoulders. Now, with my new system, I can get 15 scripts done in one session. They match my writing style, my voice, and my company's knowledge. Instead of full rewrites, each script just needs a quick review. I built the system in about a week, and the difference showed up before the week was out. The first project was an internal video series to teach people about the software factory and LaunchDarkly, and I barely had to edit those scripts. For the first time, the AI handles most of the work. My recent projects have mostly involved agentic software delivery. The software factory is where all of it was heading, and my company spent months preparing to help customers build their own. We had internal material, public documentation, and ongoing conversations I wanted to add clarity to. So my challenge wasn't just learning, it was learning while producing content at the same time. Essentially, devrel. By the end, I had built what I like to call my own personal content factory. At first, it was separate from the software factory it describes, but over time, the line between them blurred. My approach is to let AI handle the bulk of the work, while I step in for the important decisions. This is the only way I've found to make AI content sound like me. The AI creates the drafts, and I step in at three key points: checking the voice, the facts, and the overall feel. The quality ceiling is set before the first draft. I didn't just ask for a video script about a topic. Instead, I gave Claude access to every source I had—public docs, internal notes, and product requirements. It used research agents to read everything at once and came back with clear, organized notes I could use. I set two important rules for this step. First, every part of the research was labeled as either public-safe or internal-o

I read back six months of my own work journal and found three different note-taking systems, only one of which I remember deciding to build. This is what the volume of information actually did to my notes, what got better, what I lost, and how I capture things now.

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing Mexico is our heritage. Yet, we have no family there to visit. That sounds sadder than it is. What it actually meant, for the years before my wife and I were married and most of our time off since, is that we had to go find it ourselves. No family kitchen waiting. No grandmother's recipe with an address attached. Just the two of us and a country that is ours and that we did not know. So we did what every hungry person in a new city does...we ate. Six cities, six completely different cuisines, and somewhere in there it stopped feeling like traveling. A tlayuda from a stand outside Santo Domingo in Oaxaca. An hour in line at El Yaqui with a michelada in Rosarito. Different food every time. Same feeling every time, and there is no English word for that feeling. There is a Spanish one. What I Built Sobremesa is the time you stay at the table after the food is gone, still talking. Not the meal. The part after the meal. That is the whole site. Six meals across six Mexican cities, and the thing it measures is not how good the food was. It is how long we stayed. Tijuana, one hour. Rosarito, two. Ensenada, one. Guadalajara, ninety minutes. Mexico City, two hours. Oaxaca, two. The page adds them up at the end. Nine hours and thirty minutes at six tables. Comfort food usually means a kitchen you can go back to. We do not have one over there. So the six tables became it. The stand at Plaza Santo Domingo is the family table. The hour in line at Tacos El Yaqui is the Sunday afternoon table. Each entry has the dish, where we ate it, one verified fact about the food, and one line that is just ours, from our experience. There is a form at the bottom where you add your own table and download a card of it, generated in your browser. Nothing gets sent anywhere. One static HTML file. No framework, no build step, no tracking, no cookies, no storage. Two fonts off Google Fonts and nothing else. Designed an

Claude Code writes PHP in Laravel quite well, but it starts every session as a generalist. It does not know your project has three hundred migrations that should be thirty, that a @foreach two files over is firing an N+1, or that your modals follow one specific pattern. You end up re-explaining the same context constantly. LaraClaude packages that context as slash commands. It is a Claude Code plugin with over thirty Laravel skills, each a /lc: command. Install it once and you have audits, scaffolders and cleanup tools that already know Laravel. Here are the ones I run most. How to install LaraClaude installs through Claude Code's plugin system. Add the marketplace once, then install, so you get updates later: /plugin marketplace add edulazaro/laraclaude /plugin install laraclaude@edulazaro Or grab it directly from GitHub: /plugin install github:edulazaro/laraclaude You need Claude Code and a Laravel project. That is it for most skills; a couple that hit a live database also want Docker. Audit before you change anything Most skills default to a read-only report and only touch files when you add fix , so start by looking. /lc:find-n-plus-one scans your Blade views, Livewire components and controllers for a relationship accessed inside a loop, traces it back to the query that built the collection, and tells you the exact with() to add. /lc:find-n-plus-one /lc:security-audit is the other one I run on any project I inherit. It looks for SQL injection, XSS, mass-assignment and secrets committed to the repo, and like most fixable skills it takes a preview flag before it changes anything. /lc:security-audit # report /lc:security-audit fix --dry-run # preview the fixes /lc:security-audit fix # apply, with confirmation Clean up what has piled up Every long-lived Laravel app accumulates migration cruft: a create followed by twenty add_column and change_column files. /lc:consolidate-migrations groups them by table, classifies each table as safe to merge or not, and folds the A

I'm a big fan of using Claude and Claude Code for development. Many organizations are currently using these tools to improve developer productivity and ultimately build better products. Our role and our tools have changed — we went from powerful autocomplete to autonomous agents that can refactor, review, and implement features, most of the time better than we can on our own. Authentication methods There are several authentication methods, each with different billing, cost tracking, and governance options. Depending on your organization, you will choose the one that fits best. Personal development — Anthropic API key I use this for experimenting with the Anthropic library for learning and prototyping. You set ANTHROPIC_API_KEY in your environment (or a .env file), and the SDK picks it up automatically. Pay-as-you-go per token, no infrastructure needed. from dotenv import load_dotenv load_dotenv () import json import anthropic client = anthropic . Anthropic () tools = [ { " name " : " get_weather " , " description " : ( " Returns current weather for a city. Use ONLY for weather queries. " " Input: city name (string). Output: temperature in Celsius and conditions. " ), " input_schema " : { " type " : " object " , " properties " : { " city " : { " type " : " string " }}, " required " : [ " city " ], }, }, { " name " : " get_time " , " description " : ( " Returns the current local time for a city. Use ONLY for time/timezone queries. " " Input: city name (string). Output: local time string. " ), " input_schema " : { " type " : " object " , " properties " : { " city " : { " type " : " string " }}, " required " : [ " city " ], }, }, ] def get_weather ( city : str ) -> dict : return { " city " : city , " temp_c " : 22 , " conditions " : " sunny " } def get_time ( city : str ) -> dict : return { " city " : city , " local_time " : " 14:35 " } TOOL_FUNCTIONS = { " get_weather " : get_weather , " get_time " : get_time , } def run_agent ( user_message : str ) -> str : messages =

The UK AI Security Institute, or AISI, has put independent cyber-capability testing at the center of the debate over how frontier AI systems should be governed. Its work on Anthropic's Claude Mythos models and OpenAI's GPT-5.6 Sol examines how advanced systems perform on controlled cyber tasks when evaluators have access beyond the safeguards normally applied in public deployment. The most important takeaway is not that a single model has crossed a clearly defined threshold. It is that external, pre-deployment evaluation is becoming a practical governance mechanism for assessing what frontier models can do in realistic but contained environments. Company materials from Anthropic and OpenAI confirm AISI's involvement in testing related Mythos-class and GPT-5.6 systems, while AISI has published findings on the cyber capabilities of Claude Mythos Preview. AISI's evaluation of Claude Mythos Preview's cyber capabilities provides the clearest official account in the supplied evidence. The institute assessed the model in controlled settings designed to test cyber-relevant capability. Anthropic has also said that Mythos 5 would undergo external testing with UK AISI as part of its trusted-access Project Glasswing program. Separately, OpenAI's GPT-5.6 System Card says UK AISI received early access to GPT-5.6 Sol for a pre-deployment evaluation. That distinction matters. The publicly documented materials refer to different model variants, access arrangements, and stages of evaluation. They nevertheless point to a shared development: AISI is being used as an independent evaluator of frontier-model cyber capability before or alongside restricted access programs. What the evaluations establish The available research supports a measured conclusion. Mythos-family models and GPT-5.6 Sol demonstrated substantial cyber capabilities in controlled test environments, including work involving autonomous cyber tasks and simulated environments. Those results should not be read as evidence t

Anthropic shipped OS-level sandboxing for Claude Code. If you run an agent against a repo you care about, it's worth understanding precisely what moved — because a fair amount of the commentary treats it as "agents are contained now," and that's not what the documentation says. I read the docs carefully, partly because I build a tool in adjacent territory and needed to know whether I'd just been made redundant. Short answer: no. The longer answer is more interesting, and it starts with a compliment: the docs are unusually honest about their own limits. Most of what follows isn't something I discovered — it's something Anthropic wrote down, and more people should read it. What it actually does The sandbox uses OS primitives — Seatbelt on macOS, bubblewrap on Linux and WSL2. By default, sandboxed commands can write only to your working directory and the session temp directory. No network domains are pre-allowed: the first time a command needs a new host you're prompted, and approving it lasts the session. Crucially, this is enforced by the operating system on the running process , not by the model correctly interpreting a command. The docs put it well: the boundary holds regardless of what the model chose to run, and even if an allowed command does more than its name suggests. That's a real improvement over asking an agent nicely, and it's the right layer for what it solves. The motivation named in the docs is the same one I keep seeing in the wild: reducing the permission prompts that people stop reading. Approval fatigue is the disease; this is a real treatment for part of it. Five things worth knowing before you rely on it It's Bash-only. The sandbox constrains Bash commands and their child processes. Claude Code's own Read, Edit and Write tools don't run through it — they go through the permission system instead. "The sandbox is on" means shell commands are contained, not that every file operation is. Your working directory is inside the boundary by design. The de

I built an orchestration skill for Claude Code that delegated everything to subagents. It worked. It also cost somewhere on the order of 1-2 million Opus tokens per task - including tasks whose final diff was a handful of lines. Nothing was broken. Every individual decision was defensible. Three modest multipliers stacked, and then the whole stack ran on every single request. This is the postmortem, the redesign, and the enforcement layer I should have written first. v1: pure delegation The design goal was context hygiene. The main session gets polluted fast - it accumulates file contents, tool output, and dead ends, and its judgment degrades as the window fills. So: don't let it do any work. Make it a coordinator, and give every unit of real work a fresh context. That produced four rules: A hard gate. The main session was forbidden from reading, editing, or running anything itself. Every action went through a subagent. A fixed 5-phase pipeline on every task: Plan → Approve → Execute → Review → Report. Fresh subagents per phase. No reuse. Each phase got clean context by construction. Mandated reviewers with "loop until clean." A review phase that re-ran until it found nothing. And the trigger was broad - essentially any actionable request. "do this," "implement," "fix," "build," "change." Read those four rules again with a cost lens instead of a correctness lens. That is the whole postmortem. The three multipliers 1. The dispatch schema made model optional The subagent dispatch tool takes a model parameter. My skill never set it. Omitted, it inherits from the parent session - which was Opus 4.8. So every subagent, including the ones whose entire job was "read this file and summarize it," ran on the most expensive tier available. Here's what that actually costs at list prices: Model Input $/MTok Output $/MTok vs. Opus Claude Opus 4.8 ( claude-opus-4-8 ) $5.00 $25.00 1× Claude Sonnet 4.6 ( claude-sonnet-4-6 ) $3.00 $15.00 0.6× Claude Haiku 4.5 ( claude-haiku-4-5 ) $1.

This tutorial was written by Néstor Daza . This is the third article in a series about building Claudius , my own Claude-based chatbot ( Github ). The previous article discussed the MongoDB data model to use for the app. The previous article decided the shape of the data. None of it matters until the app around it is working, and getting it there is the unglamorous half of this phase. It comes down to three things: an identity system the client cannot tamper with, proof that Claudius can reach the two services it depends on, and the deployment realities that decide whether any of it runs at all. This is the boring work that quietly decides whether a project survives contact with production. Identity: the client never gets a vote Any Google account on Earth can sign into Claudius safely because a user's role is never something the client sends. It is decided on the server every time. One piece of this lives outside the code. The Google provider needs an OAuth (Open Authorization) client that you register once in the Google Cloud Console, and the client identifier and secret from that registration are set in corresponding env variables. These setup steps live in the Auth.js and Google documentation, so I am not repeating them here. Sign-in runs on Auth.js v5 with the Google provider and the MongoDB adapter. There are three roles, admin, member, and guest, and they resolve in exactly one place on the server, with a clear precedence: export async function resolveRole ( email : string | null | undefined ): Promise < Role > { if ( ! email ) return " guest " ; const normalized = email . toLowerCase (); if ( normalized === env . ADMIN_EMAIL . toLowerCase ()) return " admin " ; const settings = await settingsCol (); const allowlist = await settings . findOne ({ _id : " allowlist " }); if ( allowlist && " emails " in allowlist ) { const allowed = allowlist . emails . some (( e ) => e . toLowerCase () === normalized ); if ( allowed ) return " member " ; } return " guest " ; }