Code415 Radar

Key ideas

Direction in activation space

A fixed vector that layers write into the hidden state, which can line up with one behavior such as looping.

Directional ablation

Subtracting that vector from a layer's output weights so the layer can no longer write the behavior, without any retraining.

Forward pass budget

How many times the editing model may run the target model to test ideas, here 10, 25 or 50.

Steps

1. Read the MIT CSAIL blog post on weight space programming first, focusing on Experiment 8 and its results table.
2. Compare the 10, 25 and 50 pass rows and note how the share of answers hitting the token limit tracks the accuracy jump.
3. Read the Gemma 3 270M section and why the authors think it did not improve.
4. Skim the exp8_math folder README in the lm_understand-logs repo to see what Astra actually ran.
5. Self check: why can removing one direction raise accuracy on a model that already knows the math, yet fail on a model that does not loop?

Steps

1. Clone the public RikiyaT/lm_understand-logs repo from GitHub and open the exp8_math README.
2. Read the included weight diffs and apply script for the Qwen3.5-0.8B edit, and check which layers and columns they touch against the blog post.
3. Load Qwen3.5-0.8B with transformers on your own machine and answer 20 MATH-500 style problems with thinking on, logging how many hit a fixed token cap.
4. Apply the published edit with the repo's apply script and rerun the same 20 problems with the same settings.
5. Compare accuracy and the share of capped answers before and after the edit.

Small angles to try

• Lower the token cap and see whether the edited model gains more than the base model.
• Run a few non math prompts before and after the edit to look for side effects on ordinary chat.
• Read the exp7_sycophancy logs to see how the same setup diagnoses a different behavior.

Key ideas

Abliteration

Finding a direction in a model's hidden states tied to a behavior and projecting it out of the weights.

Sycophancy

A model's habit of agreeing with or flattering the user instead of giving an accurate answer.

KL divergence scorer

A measure of how far the edited model's outputs drift from the original on harmless prompts, used to keep edits from damaging the model.

Steps

1. Read the Heretic README on GitHub first, especially the list of what each config can do.
2. Open config.noslop.toml and config.nosyco.toml and compare them with config.default.toml.
3. Read docs/migration_v1_to_v2.md to see how modifiers and scorers are now split.
4. Self check: what two quantities does Heretic trade off when it searches for an edit, and why does that matter for a sycophancy fix?

Steps

1. Install the tool with pip install -U heretic-llm in a fresh virtual environment.
2. Download config.nosyco.toml from the repo and set Heretic to use it in place of the default, following the configuration notes in the README and config.default.toml.
3. Write 10 prompts where the user states a wrong fact confidently and record how a small local instruct model replies.
4. Run Heretic on that model with the sycophancy config and save the result locally when it finishes.
5. Ask the edited model the same 10 prompts and count how often it corrects the user instead of agreeing.

Small angles to try

• Repeat with config.noslop.toml and compare reply length and filler phrases.
• Enable 4 bit quantization in the config to see how VRAM and quality change.
• Run a few ordinary coding questions on both models to check nothing else broke.

Key ideas

Sliding window attention

Each new token attends only to a limited recent span instead of the whole sequence, so cost stops growing with length.

Working references

A small fixed set of visual and text tokens the decoder keeps attending to while it reads a long document.

KV cache

Stored keys and values from earlier tokens; its size usually grows with document length and drives memory use.

Steps

1. Read the Hugging Face model card for baidu/Unlimited-OCR-2 first, especially the SR-SWA section.
2. Open the linked arXiv paper and find the figure comparing memory and latency against page count.
3. Compare how a standard decoder's KV cache grows with a 100 page document.
4. Self check: what does the model give up by attending to a fixed 512 token reference set, and when might that hurt accuracy?

Steps

1. Start a local server with python3 -m sglang.launch_server --model-path "baidu/Unlimited-OCR-2" --host 0.0.0.0 --port 30000 as shown on the model card.
2. Alternatively load it in Python with AutoModel.from_pretrained("baidu/Unlimited-OCR-2", trust_remote_code=True, device_map="auto") and the card's multi page example.
3. Run OCR on a 5 page document of your own and save the output.
4. Run a 50 page document and record GPU memory and time per page.
5. Spot check tables and headings in the output against the original pages.

Small angles to try

• Try a scanned document with poor image quality.
• Compare against a quantized build in LM Studio or Ollama on a laptop.
• Try vllm serve "baidu/Unlimited-OCR-2" and compare throughput with SGLang.

Key ideas

Buy for me agent

An AI assistant that browses a store and completes checkout on the user's behalf.

Bot management default

A CDN or WAF rule set that blocks or challenges automated traffic unless the site owner changes it.

Agent checkout

A sanctioned path where the store exposes checkout to agents and hands control back to the human for confirmation and authentication.

Steps

1. Read the Engadget article by Husain Parvez on why websites block AI agents first.
2. List each retailer's stance: block, accidental block, ban in terms, or sanctioned path.
3. Read Cloudflare's documentation on its AI crawler and agent controls for your own zone.
4. Self check: if an agent buys on your site and the order goes wrong, which of the four stances gives you the clearest audit trail?

Steps

1. Open the Apple top free feed for Japan in a browser and confirm where Muse from Meta ranks today.
2. On your own site, read robots.txt and any WAF or bot rules and list what they do to automated browsers.
3. If your domain is on Cloudflare, open its bot and AI crawler settings and note whether agents are blocked by default.
4. Write a one paragraph agent policy for your site: blocked, allowed, or allowed only through a confirmed checkout step.
5. Check your own server logs for a week of user agents that look like AI assistants.

Small angles to try

• Compare the US and Japan feeds to see how fast Muse is spreading.
• Sketch how a Shopify style confirm step would fit your own checkout.
• List which of your CAPTCHAs would also stop an accessibility tool.

Key ideas

Speculative decoding

A small drafter proposes several tokens and the big model verifies them in one pass to speed up generation.

Medusa

A speculative decoding method that adds extra prediction heads to the model; vLLM no longer supports it.

CUDA wheel

A prebuilt Python package compiled against one CUDA version, which must match what your driver supports.

Steps

1. Read the v0.33.0 notes on the vLLM GitHub releases page first, starting with the breaking changes.
2. Check which CUDA version your GPU driver supports and whether it covers CUDA 13.0.
3. Search your serving configs for Medusa, MLP speculator, Ray compiled graph or LM Format Enforcer settings.
4. Self check: what breaks first if you pull the new default image on a host whose driver only supports CUDA 12?

Steps

1. Pull the new image with docker pull vllm/vllm-openai:v0.33.0 on a test host, not production.
2. Start it with a small model you already serve and confirm it loads on your current driver.
3. Send the same 20 requests you use as a smoke test and compare latency with your current version.
4. If you use speculative decoding, swap any Medusa or MLP speculator config for a supported method and rerun.
5. If you use structured output, test it and note any LM Format Enforcer deprecation warnings.

Small angles to try

• Try uv pip install vllm --torch-backend=auto in a clean virtual environment instead of Docker.
• Pause generation and send a request to confirm you now get HTTP 503.
• On AMD hardware, compare the ROCm 10.0 and ROCm 7.2 images.

Key ideas

Total versus active parameters

A mixture of experts model stores many expert networks but routes each token through only a few, so compute per token tracks the active count, about 48B here, not the 1.6T total.

Agentic RL on codebases

Reinforcement learning where the model attempts multi step tasks in real repositories and is rewarded for outcomes such as passing tests.

Unified token space

Images and text are turned into tokens the same model reads together, instead of bolting a separate vision encoder onto a text model.

Steps

1. Read the TechNode report first for the confirmed numbers and availability.
2. Open the HN thread for LongCat-2.0 from June to see what the previous open release looked like and how people ran it.
3. Compare 48B active with the active counts of open weight coding models you already use, to estimate serving cost if weights ship.
4. Note which claims come from Meituan only, such as domestic chips, and which are independently reported.
5. Self check: why does a 1.6T model with 48B active cost roughly like a 48B dense model per token, yet still need far more memory?

Steps

1. Pick one small repository of your own and write a multi step task for it, such as adding a feature plus tests.
2. Open Meituan's LongCat chat service and confirm LongCat-2.5 Preview is the selected model.
3. Paste the relevant files and the task, then ask for a step by step plan before any code.
4. Ask it to implement the plan, apply the changes locally and run your tests.
5. Record how many rounds it took to reach passing tests and where it lost track of earlier steps.

Small angles to try

• Give it a screenshot of a simple web page and ask for matching HTML and CSS to test the visual coding claim.
• Run the same task with a coding model you already use and compare rounds to green tests.
• Check again in a few weeks whether weights appear on Hugging Face and what license they carry.

Key ideas

Semantic layer

A shared catalog that maps business terms such as revenue to the exact tables, columns and SQL that define them.

Grounded text to SQL

Generating SQL only from certified term definitions, so the model does not guess which of several revenue columns is right.

MCP server

A standard interface that lets agent clients such as Cursor or Claude Desktop call tools like ask_question or search_terms.

Steps

1. Read the README of NVIDIA/auto-ontology first for the architecture and requirements.
2. Read docs/mcp.md in the repo to see the read only tools it exposes, such as ask_question, check_answerable and get_term.
3. Pick one metric your team defines in two different ways and write down both definitions.
4. Sketch how a term, its columns and its SQL attribute would represent that metric.
5. Self check: why would check_answerable reduce wrong answers compared with letting an agent write SQL directly?

Steps

1. Clone the repo into a folder named auto_ontology and enter it.
2. Run cp .env.example .env and fill in DEFAULT_MODELS_API_KEY, AUTH_SECRET and APP_URL.
3. Start the stack with docker compose up -d --build and open http://localhost:3000.
4. Connect a small local DuckDB or Postgres database of your own and let it build terms from the metadata.
5. Ask a question about a metric and compare the returned SQL with the definition you expect.

Small angles to try

• Define the same metric two ways in your data and see whether it flags the conflict.
• Point an MCP client at the local server per docs/mcp.md and call check_answerable before ask_question.
• Swap the default model for a self hosted NIM and compare answer quality.

Key ideas

Silent speech interface

A system that recognises words a person mouths or articulates without making sound.

Visemes

Mouth shapes visible on camera; several phonemes share one viseme, which caps how well pure lip reading can do.

Word error rate

The share of words a recogniser gets wrong through substitutions, deletions or insertions, compared with a reference transcript.

Steps

1. Read the Show HN post and the founders' replies first.
2. Note the three sensing options they tried, EMG, lip reading video and radio, and the reason each was kept or dropped.
3. Read about phonemes versus visemes to see why vision alone hits a ceiling.
4. Think about the calibration step: a new user read 20 sentences in the demo before decoding improved.
5. Self check: why would a radio signal through the mouth carry information a camera cannot see?

Steps

1. Write 20 short sentences and record yourself reading them aloud on your own laptop.
2. Transcribe the recordings with any local speech recogniser you already have, or type a second noisy transcript by hand.
3. Write a small Python script that computes word error rate with an edit distance between reference and hypothesis.
4. Group errors by word pairs that look alike on the lips, such as pat, bat and mat.
5. Compare your numbers with the 17% figure and note which errors vision alone could never fix.

Small angles to try

• Measure how WER drops as you add more of your own calibration sentences to a simple adaptation step.
• Make a table of English phonemes that map to the same viseme.
• Read the HN comments on privacy and social use and list the open questions for a product team.

Key ideas

Lean verification

Writing a proof in the Lean proof assistant so a computer checks every step, independent of who or what wrote it.

Attribution norms

Rules for crediting prior work; Calegari says many AI papers break them by ignoring earlier results.

Egoless mathematics

The view that a result's value does not depend on who found it, so AI discoveries count as truths gained rather than threats.

Steps

1. Read Calegari's post on Tao's blog first, focusing on the list of proposals.
2. Read the egoless mathematics post and note where it agrees and differs.
3. Skim the top HN comments for how engineers map this onto code review and hiring.
4. Pick one proposal, such as judging all work as if AI assisted, and write how it would change your own team's review process.
5. Self check: what does Lean verification guarantee about a proof, and what does it not tell you about whether the result matters?

Steps

1. Open the Lean 4 web editor at live.lean-lang.org.
2. Type a tiny theorem such as the commutativity of addition on natural numbers and close it with an existing library lemma.
3. Change the statement to something false and watch the checker reject it.
4. Write two sentences on what the checker verified and what a reader still has to judge.
5. Apply the same split to a recent AI generated pull request: what tests verified, and what review still had to decide.

Small angles to try

• Find one of the OpenAI papers Calegari refers to and check how it cites prior work.
• Draft a short team policy that treats every pull request as possibly AI assisted.
• Compare the two guest posts on who should get credit for an AI found result.

Key ideas

Mention mining

Extracting named entities such as book titles from free text and counting how often they appear.

Distinct author counting

Counting how many different people mention an item, so one enthusiastic commenter cannot inflate it.

Stance detection

Classifying whether a mention is positive, negative or neutral, which separates a recommendation from a criticism.

Steps

1. Read the Show HN post first for how the site was built and what it counts.
2. Browse HackerBooks and open one book to see the comments behind its count.
3. Read the open-index/hacker-news dataset card on Hugging Face for its columns and file layout.
4. List the pipeline steps: fetch comments, extract titles, match to Open Library, count distinct authors.
5. Self check: which step would you add so a book that people criticise does not rank as recommended?

Steps

1. Install DuckDB for Python with pip install duckdb.
2. Query one monthly parquet file from open-index/hacker-news through an hf:// path, keeping only comments where type is 2.
3. Search the comment text for a handful of book titles you choose and count distinct commenters per title; the by column must be quoted in DuckDB.
4. Read 10 matching comments per title and label each as positive, negative or neutral by hand.
5. Compare the raw mention ranking with a ranking that counts only positive mentions.

Small angles to try

• Ask a local small model to label stance and compare it with your hand labels.
• Repeat for one month in 2010 and one in 2025 to see which books rise.
• Try the same method for programming languages instead of books.

Key ideas

Recall versus precision for bug finding

Recall is the share of all known bugs an agent found, precision is the share of its reports that were real bugs.

Exploratory QA agent

An agent that uses a running app like a person would, without reading source code, and reports what breaks.

LLM judge

A model that decides whether each reported bug matches a labeled ground truth bug, which is cheaper than human grading but can be wrong.

Steps

1. Read the Launch HN post first for the setup and the results table.
2. Open the qa-bench README on GitHub and note how fixtures, ground truth and known invalid reports are stored per app area.
3. Skim the HN comments about cost per bug and lock in to see where engineers disagree.
4. Self check: why can an agent with lower precision still be the better choice, and what in this benchmark design could favor the vendor's own agent?

Steps

1. Clone the github.com/momentic-ai/qa-bench repository.
2. Open results/2026-10-31.csv and compare per area results for Mo, Codex, Claude Code and Devin.
3. Pick one area under fixtures/oss/saleor/ and read its ground-truth.json and known-invalid.json to see what counts as a real bug.
4. Write down two bug types you think an agent would miss without reading code, then check whether they appear in the ground truth.
5. Optional, with your own keys: follow the README to run one agent on one area, for example pnpm eval --agent codex-playwright-mcp --prevent-cheating --fixtures saleor/areas/vouchers --minutes 30, inside the E2B sandbox it provisions.

Small angles to try

• Compare 30 minute and 60 minute numbers to see which agents keep finding bugs over time.
• Rerun one area with --browser local instead of Browserbase and compare cost.
• Score a few judge decisions by hand to estimate how often the LLM judge is wrong.

Key ideas

Attack and defense CTF

A capture the flag format where each team defends its own service while trying to break the others, so patches must keep the service healthy.

Health check

An automated request that confirms a patched service still works, which catches patches that block attacks by breaking the app.

Expected score

A rating derived from match results by a statistical model, used instead of raw win counts because opponents differ.

Steps

1. Read the Hugging Face blog post first, especially the match format and failure analysis sections.
2. Open the live leaderboard and a few match replays on cyber-arena.ai.
3. Read the Octagon README to see how the per run firewall and egress gateway isolate matches.
4. Self check: why does an over blocking patch fail in this arena even though it stops the attacker?

Steps

1. Open the match replays on cyber-arena.ai and pick one match that ended with an unverified fix claim.
2. Note what the agent claimed, what the health check or capture showed, and what verification step would have caught it.
3. Write a short verification checklist for your own coding agent prompts, for example run the exploit test and the health check after every patch.
4. Optional, only on your own isolated machine: clone Octagon, run git submodule update --init, then build only the harness you use with AGENT_HARNESSES="claude codex" ./scripts/build_images.sh.
5. If you have the required token and keys, start the sample config from the README, watch the local panel, then run the matching teardown command.

Small angles to try

• Compare failure types across two harnesses on the replays page.
• Add your checklist to an agent's instructions and see whether it reports fixes differently on a toy bug in your own repo.

Key ideas

CAIO

Chief AI Officer, an executive who owns how a company adopts AI across functions.

Stop work build day

A day when regular work pauses so everyone can learn and build, giving explicit permission that busy teams otherwise lack.

Steps

1. Read page 1 of the ITmedia interview for the numbers and the upstream to downstream argument, using a browser translator if needed.
2. Read page 2 for the AI Agent Day format.
3. List which of your team's tasks sit upstream or downstream of coding, such as planning, reviews and checks.
4. Self check: why would a 7.6 times coding speedup fail to show up in company results?

Steps

1. Pick one repetitive non coding task you do weekly, such as writing a status update or checking a spec against a checklist.
2. Spend 10 minutes writing the instructions an agent would need: inputs, steps, output format and what counts as done.
3. Run it on your own recent data in your assistant and compare the output with what you produced by hand.
4. Present it to one colleague in five minutes, the way AI Agent Day ends with demos, and note their questions.

Small angles to try

• Run the same exercise on a planning task upstream of code.
• Draft a one page agenda for a half day version for your team.

Key ideas

OpenAI compatible endpoint

A server, local or hosted, that accepts the same request format as OpenAI's API, so one client can talk to many models.

Default model

The model llm uses when a command does not name one, which changes behavior and cost silently on upgrade.

Multimodal embeddings

Vectors computed from text, images, audio or video in one space, so the input must declare its content type.

Steps

1. Read the llm 0.37 release note on simonwillison.net.
2. Read the llm docs section on configuring an OpenAI compatible model.
3. Check the GitHub release page for the full change list.
4. Self check: what happens to an unpinned cron job that calls llm after this upgrade?

Steps

1. Install or upgrade with pip install -U llm.
2. Run llm models default to see which model your scripts now use.
3. Start a local OpenAI compatible server on your machine, then register it with llm openai endpoint add http://localhost:8080 -m <model-name> --id local-test.
4. Run a prompt with the -m local-test option and confirm it reaches your local server.
5. Run llm openai endpoint list to see the saved record, then llm openai endpoint remove local-test to clean up.

Small angles to try

• Add a hosted provider with --key and --alias as in the docs example.
• Compare the same prompt on gpt-6-luna and the local model for cost and quality.

Key ideas

BTOS

The Business Trends and Outlook Survey, a biweekly Census Bureau survey of US businesses.

Series break

A point where a question or method changes, so values before and after should not be compared as one trend.

Trailing average

An average over the latest several survey waves, used to smooth noise in small samples.

Steps

1. Read Simon Willison's post for the wording history and chart.
2. Open the Census document on AI question wording updates linked from the post.
3. Look at the BTOS data downloads page to find the employment size class file.
4. Self check: which two dates should a chart of this series flag, and why?

Steps

1. Download the employment size class XLSX from the BTOS data downloads page on census.gov.
2. Load it and filter to the AI use question for the 250 or more employees group.
3. Plot the values over time with vertical lines at November 2025 and October 19, 2026.
4. Compute a six wave trailing average and check that the latest value under the old wording is close to 40.7%.
5. Once the first Super Intelligence wave is published, add it to the chart as a separate segment.

Small angles to try

• Repeat for the smallest size classes, which sit near 21% to 23%.
• Compare the series with and without the trailing average to see how noisy single waves are.

Key ideas

Statistical text watermark

The model nudges its word choices in a pattern that a detector holding a secret key can later recognize, with no visible change to the text.

Detection access

Only approved parties can run the detector, so a third party cannot check text on demand and outside AI detectors remain guesses.

Edit versus authorship

A watermark shows Claude produced the final wording, which also happens when it only proofreads or translates human writing.

Steps

1. Read the GIGAZINE article first for the model list, the source email and the detection audiences.
2. Read a plain explainer of LLM watermarking, such as the Kirchenbauer et al. paper on green list watermarks, to see how token choices carry a signal.
3. List every place in your own product where Claude rewrites user text, for example docs, translations or support replies.
4. Decide what disclosure your users need if that text could later be flagged as AI edited.
5. Self check: why can a watermark appear on an essay a student wrote entirely by hand?

Steps

1. Pick a small local model and a fixed prompt that asks for a 150 word paragraph.
2. Write a short script that, at each generation step, splits the vocabulary into a green and red half using a hash of the previous token and a secret seed, then adds a small bonus to green token scores.
3. Generate one paragraph with the bonus and one without, using the same prompt.
4. Count the share of green tokens in each paragraph with the same seed and compare them.
5. Paraphrase the watermarked paragraph by hand and count again to see how much signal survives editing.

Small angles to try

• Vary the bonus strength and note when the text starts reading worse.
• Run the detector on a paragraph you wrote yourself to see the false positive rate.
• Translate the watermarked text and back to see whether the signal survives.

Key ideas

Claude Code skill

A folder of instructions and scripts that Claude Code loads when you call its slash command, so the agent follows a fixed workflow.

Scripted browser capture

Playwright drives a real Chromium window through clicks and typing while recording, which makes the demo repeatable.

Brief as code

A YAML file holds the product URL, audience, beats, brand and duration, so the video is rebuilt from text you can review in a pull request.

Steps

1. Read the skill-video-studio README first, then docs/installation.md in the repo.
2. Open the brief template at .claude/skills/devrel-video/templates/brief.example.yaml and note each field.
3. Skim how brands/acme stores brand tokens that the title cards reuse.
4. Trace the pipeline: plan, Playwright capture, HyperFrames composition, FFmpeg mastering.
5. Self check: which part of the pipeline would you rerun after a button label changes in your app?

Steps

1. Clone the repo with git clone https://github.com/aaitor/skill-video-studio.git, enter the folder and start claude.
2. Follow docs/installation.md to install the capture and rendering dependencies.
3. Run /devrel-video and ask for a 25 second silent walkthrough of the bundled Acme app reusing brands/acme, with the plan shown before capture.
4. Review the plan, approve it, and watch the rendered file for pacing and cut points.
5. Copy the brief template into projects/<your-slug>/brief.yaml pointing at a local app you own and render again.

Small angles to try

• Change one beat in the brief and compare render time with a manual re recording.
• Add your own brand folder and check that title cards pick up its colors.
• Run the repo checks with python3 scripts/check.py after installing requirements-dev.txt.

Key ideas

Quantization

Storing weights in 4 or fewer bits lets a 27B model fit in 24 to 32GB of GPU memory at a small quality cost.

Unified memory

Apple Silicon and Strix Halo share one large memory pool between CPU and GPU, trading speed for room to load bigger models and longer context.

Prompt versus generation speed

Reading the prompt and writing new tokens run at different rates, so a single tok/s number hides half the story.

Steps

1. Read the Ask HN thread first and note each hardware, model and quantization trio.
2. Estimate memory for a 27B model at 4 bits, about half a byte per weight plus room for the KV cache.
3. Read the llama.cpp llama-bench README to learn how pp and tg speeds are measured.
4. Match your own GPU or Mac memory to the closest setup in the thread.
5. Self check: why does a 260k context need far more memory than the model weights alone?

Steps

1. Build llama.cpp or use a release binary, and place a small GGUF model in a models folder.
2. Run ./llama-bench -m models/your-model.gguf -p 512 -n 128 to measure prompt and generation speed.
3. Record the pp and tg tok/s values from the output table.
4. Repeat with a lower or higher quantization of the same model.
5. Compare your tg number with the 55 tok/s V100 report and explain the gap from memory bandwidth.

Small angles to try

• Raise -p to 4096 to see how prompt processing scales with long input.
• Run the same model on CPU only to see how much the GPU adds.
• Try a mixture of experts model such as a 35B A3B variant and compare speed per total parameter.

Key ideas

Chat versus Work mode

Chat answers in turns, while Work runs longer agent tasks with files, plugins and a browser that you review afterward.

Shared allowance

ChatGPT and Codex draw from one token pool, so heavy agent runs in one can shorten what is left in the other.

Steps

1. Read the TechCrunch article first for what merges, what stays separate and the rollout plan.
2. Revisit the Nov 2 item on the shared ChatGPT and Codex allowance.
3. List which of your tasks use Chat, Work and Codex today.
4. Self check: after the merge, which of those tasks will eat into the same limit as your Codex coding sessions?

Steps

1. Pick one real task you currently split between Chat and Work, such as drafting a spec then building a slide deck from it.
2. Run it once as you do today and note how many hand offs between tabs it takes.
3. Check your usage page before and after to see how much allowance the task consumed.
4. Write down what a single merged flow would save and what you would lose by mixing chat and agent work.

Small angles to try

• Repeat the task in Claude, which already merged chat and Cowork, and compare.
• Track one week of Codex and ChatGPT usage to see whether the shared pool would run out.

Key ideas

Domain mid training

Extra pretraining on legal text before fine tuning, so the model absorbs legal vocabulary and document structure.

Mandatory thinking mode

The model always produces hidden reasoning tokens first, which raises output cost and latency on every call.

Single provider routing

With only Z.ai serving the model, OpenRouter has no fallback provider if Z.ai is slow or down.

Steps

1. Read the OpenRouter model page first for capabilities, price and provider stats.
2. Check Z.ai's pricing page to confirm the same rates on the direct API.
3. Read OpenRouter's quickstart to see the endpoint and the OPENROUTER_API_KEY header.
4. Self check: why might a cheap per token price still give an expensive bill on long contracts with thinking on?

Steps

1. Export your key as OPENROUTER_API_KEY.
2. Send a request to OpenRouter with model id z-ai/glm-5.3-flashx-legal, following the curl example in the OpenRouter quickstart.
3. Ask it to list termination, liability cap and governing law clauses from one sample contract as JSON.
4. Give it both contracts and ask for inconsistencies between them, then check each claim by hand.
5. Read the token usage in the response and compute the cost at $0.37 input and $1.25 output per million.

Small angles to try

• Run the same prompts on a general model and compare clause recall.
• Feed a scanned page image to test the image input.
• Measure how many reasoning tokens thinking mode adds per request.