Code415 Radar

Key ideas

Allow rule

An entry under permissions.allow in a Claude Code settings file that lets a specific tool call run without asking again.

Global git excludes

A per machine ignore file that git applies to every repository on that computer, but which is never committed or shared with teammates.

Secret rotation

Revoking a leaked credential at its provider and issuing a new one, which is the only fix once a secret has been public.

Steps

1. Read the Cyber Security News write up first for the numbers, the cause and the recommended order of fixes.
2. Read the section on keeping personal settings out of a repository in the Claude Code settings docs to see exactly where the allow rule is written and which ignore file protects it.
3. Skim the HN thread for how teams describe finding these files in their own repos.
4. Self check: why can a repo still leak .claude/settings.local.json even though Claude Code added it to your global git excludes?

Steps

1. In each of your own repositories, check whether .claude/settings.local.json is tracked now or ever appeared in git history.
2. Open any copy you find and read every allow rule for literal passwords, tokens, connection strings and authorization headers.
3. For each real secret, rotate it at the provider first, then run git rm --cached .claude/settings.local.json and add the path to the repository's own .gitignore.
4. Open your global git excludes file, which is ~/.config/git/ignore unless core.excludesFile points elsewhere, and confirm it contains **/.claude/settings.local.json.
5. In a throwaway local repo, write a fake allow rule containing a dummy PGPASSWORD value and run your secret scanner on it to see whether it is flagged.

Small angles to try

• Also review shared .claude/settings.json files and saved agent transcripts for embedded secrets.
• Add a pre commit check that rejects any commit touching .claude/settings.local.json.
• Rewrite approved commands to read credentials from a secret manager or environment variable instead of literal values.

Key ideas

Injected context

The small memory layer loaded into every session, such as the start of a MEMORY.md index, so it must stay short.

Dreaming

An offline job in which the model rereads past transcripts and its notes, corrects them and promotes key facts to the injected layer.

Memory representation

A structured form of memory, such as a wiki with one page per entity, that is easier to search and update than loose notes.

Steps

1. Read Anthropic's post The Components of Agent Memory first, focusing on the layer diagram and the experiment tables.
2. Read the Claude Code memory docs to map the layers onto CLAUDE.md files and the auto memory folder.
3. Skim the HN thread for the arguments against automatic memory.
4. Self check: why did one page per contract preserve all 57 facts when a shared table did not?

Steps

1. Run claude --version and confirm it is v2.1.59 or later, which auto memory requires.
2. Start Claude Code in a sample repo, run /memory, make sure auto memory is on and open the memory folder.
3. Give it two or three related tasks across separate sessions, then read MEMORY.md and the topic files under ~/.claude/projects/<project>/memory/.
4. Repeat a similar task in a fresh session started with CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 and compare how much context it has to rediscover.
5. Trim MEMORY.md to a short index pointing at one file per component, then rerun the task and compare again.

Small angles to try

• Add a CLAUDE.md line telling it to record only failures and see whether its notes get worse, mirroring the post's finding.
• Ask a session to act as a dreaming pass that reviews the memory folder against recent work and cleans it up.
• Try the memory tool on the Claude API, linked from the post, in your own agent.

Key ideas

Time to first audio

How long a streaming speech model takes before the first sound can play, which matters more than total generation time for voice apps.

p95 latency

The value that 95% of measured requests stay under, so it reflects slow cases instead of the average.

Voice prompt

Precomputed speaker latents loaded from the phonon-voices repo that tell the model which voice to imitate.

Steps

1. Read the Hugging Face blog post on Phonon first for the model sizes, licenses and latency table.
2. Open the phonon-31m-en model card and compare the ptts runtime snippet with the Transformers snippet.
3. Note which models are Apache 2.0 and which are CC BY-NC before planning any product use.
4. Self check: why would a model with lower p95 time to first audio feel faster in a voice assistant even if total generation time were similar?

Steps

1. Create a fresh virtual environment and run pip install ptts.
2. Load the model with ptts.TTS("hf://gradium/phonon-31m-en", lang="en", quant="q8") and call tts.save("speech.wav", "Hello from Phonon.", voice="Easton").
3. Use tts.stream(...) as shown on the model card and time how long the first PCM chunk takes to arrive on your CPU.
4. For the Transformers path, run pip install git+https://github.com/huggingface/transformers in another environment and follow the card's GradiumPhononTTSForConditionalGeneration example.
5. Listen to both outputs and compare load time and memory use.

Small angles to try

• Swap in other voices from the gradium/phonon-voices repo.
• Feed it long paragraphs and numbers to see where pronunciation breaks.
• Compare first audio latency with a TTS model you already use, on the same machine.

Key ideas

ISUCON

A Japanese contest where teams get eight hours to make a web app as fast as possible under an official benchmarker.

Ralph style loop

A harness that keeps restarting a coding agent on the same goal with fresh context until a stop condition is met.

Supervisor agent

A second agent that reviews the main agent's decisions against a checklist partway through the run.

Steps

1. Read Kawasaki's Zenn competition day report first, in Japanese or via a translator, for the timeline and final stats.
2. Read the laiso post for the harness components and the list of winning changes.
3. Compare how the harness decided when to stop with how a human team would decide.
4. Self check: why does run to run score noise make an autonomous agent's stop rule important?

Steps

1. Pick your own small app and write a load test script that prints a single score.
2. Write a short conditions file stating the goal, the allowed changes and how to run the benchmark, then start Claude Code with a prompt that points to it.
3. Have it run the benchmark three times on the unchanged app to measure noise before any change.
4. Let it propose and apply one change at a time, rerunning the benchmark after each and keeping a log.
5. Add a stop rule, such as no gain beyond the measured noise over three runs, and see when it halts.

Small angles to try

• Add a reviewer subagent halfway through that checks earlier decisions against a checklist.
• Plant a misleading AGENTS.md in your own test repo and see whether the agent follows it.
• Compare one change per run with several changes per run for how clearly gains can be attributed.

Key ideas

Actor model

A design where each unit of work owns its state and is reached only through messages, so many can run without sharing memory.

Hibernation

An idle actor writes its state to storage and unloads, then reloads on the next request with nothing lost.

Tiered storage

Writes land on fast local SSDs first and are later batched to cheaper object storage such as S3.

Steps

1. Read the rivet-dev/rivet README first for the feature list and supported runtimes.
2. Read the Launch HN post for the founders' design and cost claims, and skim the comments for objections.
3. Read the backend quickstart to see how an actor, its SQLite table and its actions are defined.
4. Self check: what does an actor that hibernates save compared with keeping one container running per agent session?

Steps

1. In an empty folder run npm install rivetkit.
2. Save the quickstart's SQLite backed counter actor as index.ts, with setup and registry.start() as shown in the docs.
3. Start it with npx tsx --watch index.ts, or bun --watch index.ts on Bun; it listens on port 6420.
4. Write the docs' client script using createClient from rivetkit/client and call increment on a my-counter actor a few times.
5. Stop and restart the server, call increment again, and check whether the count continued from where it left off.

Small angles to try

• Open a realtime connection with connect() and listen for the newCount event from a second terminal.
• Run npx skills add rivet-dev/skills and ask your coding agent to build one actor per chat session.
• Create many actors with different keys and watch memory use on your machine.

Key ideas

Agent Merge

A mode where Copilot waits on a pull request and merges it by itself once required checks and repository rules are satisfied.

Assisted approvals

Personal instructions telling Copilot which tool requests in a local session it may approve without asking you each time.

Review effort

A Copilot code review setting that trades cost for depth; the Balanced level uses three reviewer models plus one model that merges their findings.

Steps

1. Read the GitHub changelog post "GitHub Copilot weekly releases, November 2" first and list each feature with the product it lives in.
2. Open the Copilot code review API changelog and note which roles can change which settings at enterprise, org and repo level.
3. Read the PR Overview changelog and compare its merge box with the classic one you use today.
4. Write down which of your repos have required checks strong enough that an automatic merge would be safe.
5. Self check: if Agent Merge is on and a required check is still pending, what happens to the pull request?

Steps

1. Create a throwaway repository you own and add one simple required status check through branch protection or a ruleset.
2. Open a small pull request there, then select the Try the Overview page button in the PR header and look at the readiness summary.
3. From the GitHub Copilot app, enable Agent Merge on that pull request and confirm it stays waiting while the check is pending.
4. Let the check pass and record whether and how quickly Copilot merges, and what appears in the PR timeline.
5. In a terminal, start Copilot CLI and run /settings to see plugins, MCP servers and other configuration in one place.
6. Switch back to the classic overview from the same menu and note which view you would keep.

Small angles to try

• Make the required check fail on purpose and confirm Agent Merge never merges.
• Request a Copilot code review on the same PR and inspect which sources it reports for each comment.
• Write assisted approval instructions that allow only read only tools and see which requests still prompt you.

Key ideas

Privacy preserving classification

A language model labels each session by field and task, only the labels are kept, and results are reported in aggregate.

SciNet taxonomy

A map of 7,262 research tasks across 34 fields and 318 subfields used to tag what each session was doing.

Physical bottleneck

Lab and bench steps that software cannot do, which cap how much faster a field can get even with perfect AI.

Steps

1. Read the Anthropic research post "How researchers use Claude" first, focusing on the task share table.
2. Compare the share of sessions for data analysis, writing and data gathering with the share of researcher time each takes.
3. Read the acceleration scenarios and note the cost assumptions behind them, such as the AI hour and researcher hour prices.
4. Read the caveats on consumer plans only and the self selected survey sample.
5. Self check: why does the model give computer science a far higher ceiling than chemistry?

Steps

1. Export or list titles of your own last 30 AI assistant or coding agent sessions.
2. Tag each one with a task type that mirrors the post: data analysis, writing, data gathering, ideation, coding, other.
3. Compute the share of each task and compare it with the Claude Code shares reported in the post.
4. Estimate, for your own work, what fraction of steps are physical or need another person, which is your personal bottleneck.
5. Write a short note on which task you under use AI for and try one session of it this week.

Small angles to try

• Repeat the tagging for a teammate's anonymized session titles and compare.
• Tag only sessions longer than 20 minutes and see whether the mix changes.
• Track ideation sessions separately for a month to see if the 4.2% share holds for you.

Key ideas

SFT only post training

Training on example answers from a teacher model, with no reinforcement learning or preference optimization.

Teacher distillation

A stronger model writes target answers that the smaller model learns to imitate.

Capability regression check

Running general benchmarks before and after a narrow fine tune to make sure nothing else got worse.

Steps

1. Read the Nous Research Arete post first, especially the results table and the data profile section.
2. Open the Propaganda_Eval dataset card and look at its columns, such as required_facts and official_frame_markers.
3. Open the arete-data-pairs card and note its three subsets: paired, sft_accepted and reasoning.
4. Compare the Hermes Bench and Terminal Bench numbers and read why Nous does not claim the Terminal Bench gain.
5. Self check: what evidence would you need before trusting a 22% to 1% drop on an eval written by the same team?

Steps

1. Download the NousResearch/Arete-27B weights and the base Qwen3.8-27B weights from Hugging Face onto your own machine.
2. Load the Propaganda_Eval dataset and pick 20 prompts across several categories.
3. Generate answers from both models with the same sampling settings and the model's chat template.
4. Check each answer against the required_facts and official_frame_markers fields and count how many contain official framing.
5. Run 10 ordinary coding or reasoning prompts of your own through both models to spot any capability drop.

Small angles to try

• Write 10 new political prompts that are not in the eval to check for overfitting.
• Try the same prompts in Chinese as well as English.
• Compare against a quantized copy of Arete to see if the effect survives quantization.

Key ideas

Coordinator and workers

One agent triages and assigns work while separate agents do the tasks, so the human talks to only one of them.

Visibility gate

A rule that agents must stop and ask before any action other people will see.

Decision queue

A single list of yes or no questions for the human, so attention goes only where judgment is needed.

Steps

1. Read the Rescuenow Zenn article first, in Japanese or through a translator, focusing on the panel screenshots.
2. List the three priority rules and the points where the coordinator pauses.
3. Note how numbered review comments and short replies keep the human's answers brief.
4. Think about which actions in your own workflow are visible to others and should be gated.
5. Self check: why does the panel need a separate red box for workers waiting on permission prompts?

Steps

1. Create a scratch repository with five fake tasks in a markdown file, each with an owner, deadline and dependencies.
2. Write a project skill or instructions file that tells Claude Code to sort tasks by who is waiting, then deadline, then dependencies.
3. Add a rule that it must stop and ask before any push, PR creation or comment, and log each pause to a decisions file.
4. Run it on the task file and check whether the sort order and the pauses match your rules.
5. Answer the logged decisions with short numbered replies and see whether it follows up correctly.

Small angles to try

• Add numbered review comments, N1 and N2, to a self review of one of your own PRs.
• Run two worker sessions in parallel and have the coordinator track which one is blocked.
• Replace the markdown file with a Notion database you own.

Key ideas

Data residency

A requirement that data is processed and stored only inside a given country or region.

AI gateway

A service that sits in front of model servers and handles API access, keys and billing.

Cache read pricing

A much lower price for prompt tokens the server has already processed and can reuse.

Steps

1. Read the ITmedia AI+ article first, through a translator if needed.
2. Write down the division of roles between Fixstars and the gateway partner.
3. Convert the yen prices into the cost of one typical request from your own app.
4. List the open questions the article leaves, such as GPU type and API format.
5. Self check: does a no storage promise alone satisfy your company's data residency policy, and what else would you ask for?

Steps

1. Pull one week of your own LLM usage and total the input, output and cached input tokens.
2. Compute the weekly cost at ¥48, ¥192 and ¥0.96 per 1M tokens.
3. Compute the same week at your current provider's prices and note the difference.
4. Estimate the cost of self hosting a similar open model on a rented GPU in Japan for the same load.
5. Draft the list of questions to send the vendor: GPU, latency, API format, logging and contract terms.

Small angles to try

• Recompute assuming your cache hit rate doubles.
• Model a peak month at three times normal traffic.
• Add a compliance column for which workloads truly need data kept in Japan.

Key ideas

Step distillation

Training a diffusion model to reach a good sample in a handful of denoising steps instead of dozens.

Classifier free guidance

A trick that runs the model twice per step to push output toward the prompt, which doubles compute; this release drops it.

GGUF quantization

A file format that stores weights at reduced precision such as 4 bits so large models fit in less GPU memory.

Steps

1. Read the GitHub README first, especially the memory and timing tables.
2. Open the Hugging Face model card and compare the six GGUF sizes from Q3_K_M at 7.2 GB to Q8_0 at 14.9 GB.
3. Read the license summary on the model card and note the territory, revenue and output disclosure rules.
4. Skim the Show HN thread for questions about quality loss after compression.
5. Self check: why does removing classifier free guidance roughly halve the work per step?

Steps

1. Confirm your location and use case are covered by the MiniMax H3 Community License before downloading weights.
2. Install with pip install git+https://github.com/Video-Rebirth/hyperflow-h3-flash.
3. Generate a first clip with hyperflow-h3-flash --prompt "..." --output clip.mp4 using a short scene description.
4. Rerun with --steps 4 and compare quality and wall time against the default 6 steps.
5. Try a keyframe run with --image first.png --last-image last.png using your own images.
6. Record peak VRAM with nvidia-smi and compare with the README table.

Small angles to try

• Run the Q4_K_M GGUF through stable-diffusion.cpp as the model card shows and compare speed with the INT8 path.
• Use --text-encoder-precision fp8 to see how much system RAM it saves when offloading.
• Feed --reference images of your own scenes to test the reference mode.

Key ideas

Rollout

One full attempt by an agent at a task, from first action to final output.

Deterministic verifier

A script that checks an output against fixed criteria, so the same answer always gets the same grade.

Expert rubric

A scoring guide written by a domain expert for qualities a script cannot check, such as soundness of an argument.

Steps

1. Read the abstract on the Hugging Face paper page first.
2. Open the project page and study the leaderboard columns for overall, verifier and Pass@3 scores.
3. Read the arXiv paper's failure analysis section to see example trajectories.
4. Compare how verifiers and rubrics split the grading work.
5. Self check: why might an agent pass the verifier but still fail the overall score?

Steps

1. Install the harness with uv tool install --python 3.12 --upgrade benchflow and confirm with bench --version.
2. Make sure Docker is running with docker info.
3. Log in with claude auth login or codex login, or export your API key.
4. Run the README sample task with bench eval run --source-repo benchflow-ai/skillsbench --source-path tasks/citation-check --agent claude --model claude-sonnet-4-6 --sandbox docker.
5. Open the task folder and read its task file, environment and verifier to see the same structure FrontierPhysics uses.

Small angles to try

• Swap to --agent codex --model gpt-5.5 and compare outcomes on the same task.
• Write a tiny task from your own field with a deterministic verifier and run it through the harness.
• Run the sample three times and see how often it passes, mirroring Pass@3.

Key ideas

Generated mini app

A small interface with its own state that an assistant builds from a plain request instead of a developer shipping it.

Connected app data

Information the agent pulls from linked accounts such as email to fill and refresh a mini app in the background.

Steps

1. Read the Impress Watch Spaces article first for hands on examples.
2. Read the ITmedia article on the voice and avatar update.
3. Check the App Store listing for current ranking and in app purchase notes.
4. List which single purpose apps on your own phone a Space could replace.
5. Self check: what does an app builder like this need from connected data that a static app does not?

Steps

1. Open Muse and ask it to build a simple habit tracker as a Space.
2. Ask for one change, such as a new field or a sound alert, and see whether it edits the existing Space.
3. Close the app, reopen it later and check whether the Space kept its data.
4. If you choose to connect an account, try a log that fills itself, then review what data it read.
5. Note the time spent and any errors, as the Impress Watch reviewer did.

Small angles to try

• Rebuild the same tracker in another assistant and compare build time and fix rounds.
• Ask for a tiny game and test how well it handles timers and sound.
• Check which permissions Muse requests before and after connecting apps.

Key ideas

Stable ABI

A promise that compiled programs keep working with newer library versions without being rebuilt.

VT sequences

Escape codes inside terminal output that move the cursor, set colors and change modes, which an emulator must parse.

Opaque handle

A pointer whose internal layout is hidden so the library can change internals without breaking callers.

Steps

1. Read Hashimoto's libghostty 1.0 post first.
2. Open lib.ghostty.org and read the short hello example using ghostty_terminal_new and ghostty_terminal_vt_write.
3. Read the installing page to see the Zig 0.17 requirement and pkg-config names.
4. Browse the awesome-libghostty list for projects in your language.
5. Self check: why does a library that creates no threads suit embedding in an agent harness?

Steps

1. Download the source with curl -LO https://release.files.ghostty.org/libghostty-vt/1.0.0/libghostty-vt-1.0.0.tar.gz and verify the SHA256SUMS signature as the installing page shows.
2. Extract it, enter the folder and build with zig build -Doptimize=ReleaseFast --prefix "$HOME/.local".
3. Save the hello example from lib.ghostty.org as hello.c and set export PKG_CONFIG_PATH="$HOME/.local/lib/pkgconfig".
4. Compile with cc -o hello hello.c $(pkg-config --cflags --libs libghostty-vt) -Wl,-rpath,"$HOME/.local/lib" and run ./hello.
5. Change the input string to output captured from one of your own CLI tools and check the formatted result.

Small angles to try

• Build the WebAssembly target with zig build -Demit-lib-vt -Dtarget=wasm32-freestanding -Doptimize=ReleaseSmall and check the size.
• Feed recorded output from a coding agent session into the terminal and render it as plain text for test assertions.
• Try a community binding in Rust, Go or Python from the awesome-libghostty list.

Key ideas

Preparedness Framework

OpenAI's scheme for rating how dangerous a model's capabilities are in areas such as cybersecurity and biology.

ExploitGym

A benchmark that measures how often a model achieves the intended exploit on prepared vulnerable targets.

IP allowlisting

An API setting that only accepts requests from network addresses the customer has registered.

Steps

1. Read the GPT-6 Cyber system card first, focusing on the access controls section.
2. Compare the benchmark table rows against GPT-6 Astra to see where the gains are.
3. Read the TechCrunch analysis for the defender access debate.
4. Check the Nov 5 entry in the OpenAI API changelog.
5. Self check: which access controls would your own team need to put in place before applying?

Steps

1. Read the access requirements in the system card and write down which ones your organization already meets.
2. Pick a small service from your own repository and ask a generally available model for a defensive code review focused on input validation and authentication.
3. Triage each finding by reading the code yourself and marking it real, unclear or false.
4. Fix one confirmed issue and add a regression test.
5. Run your existing test suite to confirm nothing else broke.

Small angles to try

• Compare review findings from two different generally available models on the same code.
• Check your own API keys against least privilege and IP allowlisting, which the card treats as baseline controls.
• Draft an internal policy for AI found vulnerabilities based on the reporting route described by TechCrunch.

Key ideas

Labor uplift

How many times faster a researcher gets work done with AI help across all their tasks, not how many extra people they effectively have.

Compute multiplier

An algorithmic gain that gives the same result as having a given factor more training compute, which Cotra treats as the measure of AI progress.

Fast feedback loop

A task where each attempt can be scored automatically within seconds or minutes, which Panickssery found is where models do best.

Steps

1. Read Cotra's Planned Obsolescence post first and note where each number comes from: 2x overall, 2 to 3x compute multipliers, 4 to 9x labor, about 10x now.
2. Read Panickssery's LessWrong shortform and list his failures and his one big success in two columns.
3. Skim the summary of the METR report for the 2x estimate and the section on redacted evidence.
4. Sort your own recent agent sessions into tight feedback tasks and judgment tasks, and note which went well.
5. Self check: why does Cotra square the compute multiplier to get the labor uplift, and what does Panickssery's Scrabble result say about where that uplift is real?

Steps

1. Write a few lines of Python that take a target speedup and a labor share and return the required labor uplift, using Cotra's simple model where labor and compute matter equally.
2. Check that a 2 to 3x compute multiplier target gives 4 to 9x labor uplift, then try a labor share of 0.3 and 0.7 to see how sensitive the result is.
3. Pick one tight feedback task in your own repo, such as speeding up a function with an existing benchmark, and let your agent iterate on it for 10 minutes.
4. Pick one judgment task, such as asking the agent for the three most important papers or libraries on a topic you know well, and grade its picks.
5. Write down where the agent's output was clearly useful and where your own insight decided the result, mirroring Panickssery's comparison.

Small angles to try

• Ask the agent to report what it actually tested and with how much data, then check whether the comparison could tell the options apart.
• Repeat the tight feedback task with and without telling the agent a target number, as Panickssery did.
• Ask two teammates for their own uplift guess and compare it with the 12x staff figure.

Key ideas

AutoGen

Microsoft's open source framework for orchestrating multiple LLM agents, now marked as in maintenance mode.

Maintenance mode

A project still receives fixes but no major new features, so new users are steered elsewhere.

Research versus scaling labs

A split between groups that explore new methods and groups that mainly push bigger training runs, which Langford says clashed here.

Steps

1. Read Langford's hunch.net post first, end to end.
2. Open the AutoGen GitHub README and find the maintenance mode notice and the named successor.
3. List which AIF projects, AutoGen, Fara or Dion3, your team uses or follows.
4. Self check: if your stack depends on AutoGen, what does maintenance mode change for you over the next year?

Steps

1. Search your own repositories and lock files for autogen packages and note the pinned versions.
2. In a fresh virtual environment, install the current packages with pip install -U "autogen-agentchat" "autogen-ext[openai]" as the README shows.
3. Run the README hello world sample with your own key to confirm your usage still works on the latest release.
4. Read the README section on Microsoft Agent Framework and write a short note on what a migration would involve for your code.
5. Record a decision: stay pinned, migrate, or switch frameworks, with a review date.

Small angles to try

• Check open issue and pull request activity on the AutoGen repo over the last month as a maintenance signal.
• Port one small agent to the successor framework as a spike before committing.
• Swap the model client to a local or different provider to reduce lock in while you decide.

Key ideas

MCP connector

A ChatGPT integration that lets the model call tools on an MCP server on the user's behalf.

OAuth client binding

Tying a token or code to the specific client that obtained it, so another client cannot redeem it.

Token audience validation

The MCP spec rule that a server must accept only tokens issued specifically for it.

Steps

1. Read the forum report first, focusing on the setup with a developer mode connector and a published app.
2. Read the Token Audience Binding and Access Token Privilege Restriction sections of the MCP authorization spec.
3. Map how your own server would handle a code issued under one client and redeemed under another.
4. Self check: which check in the reporter's server stopped the cross connector call, and does your server have an equivalent?

Steps

1. Start your own MCP server locally with two separate OAuth test clients registered for the same test user.
2. Launch MCP Inspector with npx @modelcontextprotocol/inspector and connect to your server as client A.
3. Call a tool that issues a confirmation code, then connect as client B and try to redeem that code.
4. Confirm the server rejects it; if it does not, store the issuing client id with each code and check it on redemption.
5. Also confirm the server rejects tokens whose audience is not its own canonical URI.

Small angles to try

• Add a short expiry to confirmation codes and test redemption after it.
• Log the client id on every tool call so cross connector routing shows up in your own logs.
• Test the same flow with a reused code to confirm single use enforcement.

Key ideas

Real time factor

How many seconds of audio a model produces per second of compute, so 13.8x means far faster than playback.

Audio decoder

The part of a speech model that turns predicted audio tokens into a waveform, here 15.3M of the 38.24M parameters.

Non commercial license

Terms that allow free personal and research use with credit but require a separate deal for commercial products.

Steps

1. Read the Hugging Face model card first, including the speed, memory and license sections.
2. Read the TechCrunch article for context on the demo game and Underdog's other models.
3. Compare the 402 MB and 601 MB peak memory figures for the two voices with your target device.
4. Self check: could you ship Woof in a paid app today, and why or why not?

Steps

1. Install numpy with pip install numpy and make sure the Hugging Face CLI is installed.
2. Download the model with hf download ConwayResearch/Underdog-Woof --local-dir underdog-woof and change into that folder.
3. Generate speech with python -m underdog_woof "your text here" -o hello.wav and play the file.
4. Try the second voice with python -m underdog_woof "your text here" --voice mira -o mira.wav.
5. Time both runs on your machine and compare with the card's 13.8x and 7.2x figures.

Small angles to try

• Use the Python API, Woof(voice="mira"), inside a small script that reads your own notes aloud.
• Feed numbers, dates and abbreviations to see how the text normalizer handles them.
• Run it on an older laptop or a single board computer you own to find the slowest usable device.

Key ideas

Training data consent

Whether the artists whose work trained a model agreed to that use, the core of Sakurai's point about exploitation.

Asset provenance

A record of where each image, sound or text in a product came from and under what rights.

Steps

1. Read the Famitsu article first; a browser translation works if needed.
2. Note his three points separately: no use in his own work, trust and exploitation concerns, and the risk of doing nothing.
3. Compare them with your own team's or company's AI usage rules.
4. Self check: which of his concerns would a tool vendor need to answer before a studio like his would adopt it?

Steps

1. List the assets in one of your own projects, such as images, icons, sounds and copy.
2. Mark each one by origin: made in house, licensed, open source, or AI generated.
3. For each AI generated item, note the tool used and what its terms say about training data and commercial use.
4. Write a one page usage rule for your team covering where AI output is allowed, where it is not, and how it is recorded.
5. Share the draft with one teammate and revise it based on their questions.

Small angles to try

• Add an origin field to your asset pipeline or file naming so provenance is tracked automatically.
• Apply the same audit to code generated by assistants and their license terms.
• Draft how a tool for creative studios would show consent and provenance to satisfy a skeptical lead.