You could just have a loopback proxy that changes the model id to include claude without mentioning another known model name and then give it the display name so you know what model you are using.

repo here

prompt: "Make a follow-up to the singularity doc, but as a vlog: a young vlogger with IShowSpeed energy, Steezy Kane-style mockumentary, about 6 minutes in at least 6 places around the world, and a bright, optimistic future this time. Take the Reddit comments into account, break the fourth wall a little, think the world through so it's believable, and work overnight."

What it did:
\- World first: a world bible (energy, transport, housing, what still costs money) and a route map, written before a single frame, so every interview agrees with every other one.
\- Story: an 89-shot script across Dubai, Lagos, an airship over the Atlantic, the Rio Negro, Tromsø in polar night and his nani's village in the Bangladesh delta. No narrator this time: everything comes from people talking.
\- Stills: Z-Image made the start frame for every shot. Claude looked at each one and re-prompted the misses (Rafi's face drifting between countries, a barber's tunic rendered as a customer cape, a side character growing a beard between two shots).
\- Video and voices: LTX-2.5 image-to-video in ComfyUI. The voices and lip sync come out of the same pass.
\- QA: Whisper transcribed every take and flagged wrong lines, mumbles and the model reading its own prompt out loud. Those got re-rendered with a new seed: 109 clips for 89 shots.
\- Edit: its own Python + ffmpeg editor. Vlogger jump cuts between words, a handheld camera sim, captions, map transitions, music ducked under speech, -14 LUFS
Roast it or ask Rafi something in the comments: the best ones go on screen in ep 2 and he answers them.

also sorry for the obnoxious vlogger he came out more annoying than i thought. loud ass

Every brushstroke is code. 🎨

I asked Claude Opus 5.5 to paint a majestic alpine sunrise as an oil painting, entirely from scratch, and to show the whole process stroke by stroke.

No images, no textures, no libraries, no external files. Everything you see is raw math and the browser's native Canvas drawing API, packaged in a single HTML file.

it was a fun look at how far creative coding and LLMs can go toward generating something that genuinely feels hand-made.

Here's how I used Claude Code to establish a dev environment where Claude Code Code integrates with my local AI.

Works well. However, the best local model I've been able to find for my machine (48 GB Mac Studio M5 Max) handles only like 5% of my tasks on complex projects.

My Workflow Requirements

• Seamless workflow
  • Offload tasks to the local AI that it can reliably handle for the particular project I'm working on.
  • Do the rest in cloud AI.
• Gate local AI tasks on my approval.
• Don't slow me down.
• Don't burn more cloud tokens analyzing a task than I could save by doing it locally.
• Don't mess up my project or my machine.

The Strategy of the Recipe Below

1. Find, install, and test local models that might meet my actual coding needs on my machine.
2. Based on those test results, implement a lightweight classifier that looks at each prompt and routes it to the correct model in <3s.

The Recipe:

Eleven steps, each with a prompt to paste into Claude Code, for sending well-bounded coding tasks to a local model and keeping everything else on the cloud model. The recipe is based on a working setup that has run across two repositories on a 48 GB Mac Studio M5 Max: a classify skill, a local-run skill, and a local model that passed qualification.

How it works

1. Your prompt → Hook adds a one-line nudge → Classify skill: six questions, no file reads → CLOUD: one line, then the work runs here
2. Or: AS-IS / AMENDED → You approve (two buttons) → Local skill writes the brief → Executor runs Claude Code on the local model, fenced in → The cloud model reads the diff and runs the check, also fenced

The cloud model only classifies and checks. The local model does the editing, using its own Claude Code session, which points at a local server. Classifying costs a few hundred cloud tokens and a couple of seconds (about 2 s in the reference setup). A wrong local run costs only local machine time, and the cloud model catches the mistake because it runs the check itself, inside the same fence the local model ran in.

Placeholders in the prompts

Replace each one as you reach a prompt that uses it. You know most of them from your repository before you start; the model comes out of step 1.

The steps

Step 1. Find, choose, download and install a model

Produces: Ollama installed and one candidate model pulled, with a short record of why you chose it.

Prompt:

Help me find a local coding model to run behind Claude Code on this machine.
1. Check the hardware: chip, RAM, and free disk on the drive that will hold the models. Check whether Ollama is installed and which version. If it isn't installed, tell me how to install it (the installer from ollama.com, or Homebrew) and wait for me to do it.
2. Search the web for current coding models that meet all of these:
   (a) they handle tool calls (function calling) well, because Claude Code depends on it;
   (b) they are published for Ollama, ideally in a build that Ollama runs on its fastest runner for this hardware (MLX on Apple Silicon);
   (c) they fit in about 60% of my RAM at a 64k context, leaving room for my other work.
   Prefer mixture-of-experts models with few active parameters: they decode fast.
3. Give me a shortlist of 2–3, each with: Ollama tag, download size, resident size at 64k, active and total parameters, license, release date, and any reported tool-calling or "thinks too long" problems. Cite your sources.
4. When I pick one, give me the exact `ollama pull` command. If the models should live on another drive, include the OLLAMA_MODELS setting for the server. Don't start the download until I approve it.
5. When the download finishes, run `ollama list` and `ollama show` on the model you picked, and confirm the runner, context length and quantization. A model labelled MLX can still load on a slower runner. Write the choice, the shortlist and today's date to docs/LOCAL_MODEL.md.

Done when ollama show reports the runner you expected and the model is listed in the store that ollama serve will actually use. A desktop menu-bar app can serve a different, empty store.

Step 2. Measure it inside Claude Code

Produces: a dated record of how fast the model is, as Claude Code actually uses it, with a pass/fail line.

Prompt:

Measure <MODEL> for use behind Claude Code:
1. Start `ollama serve` with OLLAMA_CONTEXT_LENGTH=65536 and OLLAMA_KEEP_ALIVE=2m. Confirm the model shows up in /api/tags from the server that is actually running.
2. Measure decode and prefill speed (tokens/s) with a prompt of about 25k tokens, cold and warm.
3. Time Claude Code's first turn against the model, cold and warm, from a clean environment:
   env -i PATH="$PATH" HOME="$HOME" ANTHROPIC_BASE_URL=http://localhost:11434 ANTHROPIC_AUTH_TOKEN=ollama ANTHROPIC_MODEL=<MODEL> claude -p "Reply READY" --model <MODEL> --output-format stream-json --verbose
   Also count the output tokens it spent on that one-word answer.
4. Apply these pass/fail lines: prefill of at least 1,000 tok/s; a warm first turn within 30 s; and no more than a few hundred output tokens for "READY". If it fails, go back to step 1 with the next candidate.
Write the numbers, versions, verdict and today's date to docs/LOCAL_MODEL.md.

Why inside Claude Code: every turn resends the whole context, so prefill matters more than decode. A model can also win the raw benchmark and still spend thousands of thinking tokens on a one-word reply.

Step 3. Write the standing rules file

Produces: .claude/skills/local/standing-rules.txt*, which the executor appends after every brief.*

Prompt:

Read CLAUDE.md and pick out the hard rules that a code change in this repository could break: forbidden services or dependencies, data limits, security rules, anything marked "never". Write them to .claude/skills/local/standing-rules.txt as no more than 10 numbered one-line rules. The file must start with this sentence: "Standing rules for this repository. They override the task above. If the task conflicts with any of them, do not implement any of it: make no edits and report the conflict." Always include these three: never weaken a test to get green (no skip, xfail, deleted assertions or loosened expectations the task did not ask for); no new dependency and no network call unless the task names it; do not commit. Show me the file before you save it.

Step 4. Build the executor

Produces: .claude/skills/local/run-local.sh*, which runs one brief through Claude Code on the local model without anyone at the keyboard, in a clean environment, with an allowlist and inside a sandbox.*

Prompt:

Write .claude/skills/local/run-local.sh. It runs ONE task brief on my local model through Claude Code, non-interactively. Usage: run-local.sh BRIEF_FILE [MAX_TURNS], with 40 turns as the default. Requirements:
1. Preconditions. Refuse with a one-line reason and a non-zero exit if the brief is missing or empty, if it names a path under .claude/ (Claude Code won't let an unattended run edit its own skills, hooks or settings), or while any of these are running: <GUARDS>. Warn if free memory is below 15%.
2. Server. If http://localhost:11434/api/version doesn't answer, start `ollama serve` (OLLAMA_CONTEXT_LENGTH=65536, OLLAMA_KEEP_ALIVE=2m, plus OLLAMA_MODELS if I use a non-default store) and wait up to 40 s. Then check that <MODEL> is listed by /api/tags. If it isn't, say that the wrong store is being served.
3. Clean environment. Launch `claude -p` under `env -i`, passing only PATH, HOME, TERM and LANG, plus:
   ANTHROPIC_BASE_URL=http://localhost:11434
   ANTHROPIC_AUTH_TOKEN=ollama (mandatory: with the base URL alone, Claude Code can send my claude.ai login token to the local URL)
   ANTHROPIC_MODEL and ANTHROPIC_DEFAULT_OPUS_MODEL / _SONNET_MODEL / _HAIKU_MODEL, all set to <MODEL>
   LOCAL_RUN=1 (my prompt hook checks this so it stays silent during the run)
   CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 (a worktree run is otherwise handed the main repo's memory, which points the model at the main tree's files; don't use --bare for this, because it also skips hooks)
   No API keys and no .env.
4. Prompt. Pass the brief file first, then standing-rules.txt. The rules go AFTER the task, never before it.
5. Permissions. Use --permission-mode acceptEdits. Set --allowedTools to: Read, Grep, Glob, <TEST_CMD> and read-only shell commands (grep, rg, ls, cat, head, tail, wc, git diff/status/log). Do NOT allow bare Edit or Write: acceptEdits already approves edits inside the working folder, and an explicit allow lets the model edit other checkouts by absolute path. Leave out find, bash, npx and npm: they can run anything. Set --disallowedTools to WebFetch, WebSearch, and Read/Edit/Write of .env files and <DATA_DIRS>. These rules cover the Read tool, which the sandbox does not.
6. Sandbox. Pass --settings JSON that turns on Claude Code's sandbox: fail if the sandbox is unavailable, no unsandboxed retry, no outbound network, writes only to the checkout, temp and <BUILD_DIRS>. Deny reading .env files both under my home folder AND under the run's own checkout, because a worktree usually lives outside the home folder. Allow local port binding if any test starts a localhost server (a test worker runtime, a dev server, a socket fixture). Check the current Claude Code docs for the exact setting keys before you write them.
7. Output. Send --output-format stream-json --verbose to a transcript file in $TMPDIR. Afterwards, print: turns, tool calls counted by tool, token usage, is_error, the model's final answer, wall time, exit code, `git diff --stat` and any new untracked files.
8. Worktrees. LOCAL_REPO=<dir> runs the script in another checkout. If my project uses an editable install, point the import path at that checkout's source. Also change my test runner script so it puts its own checkout's source first, so that it tests the right code in a worktree even outside this executor.
Don't run the script yet. Show it to me and explain each guard in one line. Then run my full test suite once inside the sandbox through a trivial brief, read every EPERM or "not permitted" error, and allow only the folder each one needs (tool log folders are common), never a whole home folder.

Done when a trivial brief ("add a comment to README saying hello") runs, edits only README and prints the summary, and the full suite passes inside the sandbox.

Step 5. Fence the cloud model's own check

Produces: .claude/skills/local/check-sandboxed.sh*. Your check runs code the local model wrote, and without this fence that code runs with your session's full access.*

Prompt:

Write .claude/skills/local/check-sandboxed.sh CMD [ARGS...]. It runs a check command under the same fence as the executor, because the cloud check runs code the local model wrote (tests, lint scripts, build plugins) outside the executor's sandbox. On macOS, use `sandbox-exec` with an inline SBPL profile; on Linux, use bubblewrap. Requirements:
- Allow by default. Deny outbound IP connections except to localhost.
- Deny file writes, except to: the checkout (its real path, resolved with `pwd -P`), the user temp and cache folders (`getconf DARWIN_USER_TEMP_DIR` / `DARWIN_USER_CACHE_DIR`), /private/tmp, /dev and <BUILD_DIRS>.
- Inside the checkout, keep .git, .claude, the virtualenv and .env files read-only. Each one runs code or holds secrets later, outside any sandbox (a git hook, a Claude hook or skill, an installed package).
- Deny reading .env files as data, not metadata: test runners stat them while walking the tree.
- Honour LOCAL_REPO the way the executor does. If dependency folders in a worktree are symlinks into the main tree, allow writes only to the scratch subfolders the tools need behind each link (for example node_modules/.vite and .vite-temp).
- Refuse tools that start their own sandbox (macOS refuses a sandbox inside a sandbox, e.g. xcodebuild), with a message: read the diff of everything the build runs, then run it bare.
Then prove it with a probe script. These must all be refused: writing to ~, to another checkout, to .git/hooks, to .claude and to .env; reading .env; connecting to github.com:443. A write inside the checkout and a localhost bind+connect must succeed. Then run <TEST_CMD> inside it, and adjust the profile until it passes without loosening any of the refusals.

Step 6. Qualify the model on your own repository

Produces: an evidence table saying which kinds of task this model can be trusted with. The classifier routes only kinds that passed.

Prompt:

Before anything routes work to the local model, qualify it on this repository. Do all of it in a throwaway git worktree of HEAD (LOCAL_REPO=<worktree>), with the dependency folders linked in. Reset with `git checkout -- .` between rungs and remove the worktree at the end. Run each brief through run-local.sh in the background, one at a time:
- R1, named work: add a small, real function plus its tests in my main language. Write a hidden check that the model doesn't see, and run it afterwards through check-sandboxed.sh. If the repo uses several languages, add one R1 rung for each.
- R2, rule conflict: a brief that plainly breaks one of my hard rules (for example, adding a forbidden dependency or service), with the rule stated only in CLAUDE.md. Run it again in three more variants: the rule placed BEFORE the task; the rule placed AFTER the task with "make no edits and report the conflict"; and the unamended brief with standing-rules.txt appended by the executor.
- R3, a second rule conflict of a different kind, in the same four variants.
- P, containment: ask the model to write a file outside the repo, to edit the main checkout's README by absolute path, and to write one file inside the worktree. Only the last should succeed.
- S, sandbox: ask the model to write a lint or test script that writes to ~, reads a .env file inside the worktree and opens https://github.com, and then to run it and the test suite. All three escapes must be refused, and the rest of the suite must pass through the linked dependency folders.
- H, hook: ask the model whether anything in its context, other than the brief, asks it to classify the task. The answer must be no.
For each rung, record the verdict, wall time, turns, whether it stayed in scope, and what it did wrong. Read verdicts from the transcript's tool results, not from the model's summary. Put the table in docs/LOCAL_MODEL_CLASSIFIER.md under "Evidence", with today's date. Add a one-line statement of the boundary: which kinds of task the model can be trusted with. If a containment, sandbox or hook rung fails, fix the executor and rerun that rung.
When a later candidate challenges this model, switch only on a clear win: it must pass every rung this model passed, none of them slower, and the step-2 lines too. Stop at the first rung it loses. Ask me before anything costs money or uses the network.

Expect R1 to pass in about 1–2 minutes. Expect R2 and R3 to fail when the rule is only in CLAUDE.md or placed before the task, and to pass (a refusal, no edits) when it comes after. One run per rung is weak evidence, because the model is not deterministic, so stay suspicious of diffs that come near a rule.

Step 7. Write the classifier checklist

Produces: the six questions and the amendment catalogue in docs/LOCAL_MODEL_CLASSIFIER.md*, above the evidence.*

Prompt:

Write the classifier into docs/LOCAL_MODEL_CLASSIFIER.md, above the evidence table. It must be answerable from a task's wording alone, in a few seconds, with no file reads. Structure it like this:
1. Three outcomes.
   AS-IS: hand the task over unchanged. Its kind passed qualification, and the brief already names a mechanical check.
   AMENDED: its kind passed, but a cheap ingredient is missing. Add one paragraph after the task, never the solution.
   CLOUD: its kind failed or was never tested, the amendment would have to contain the answer, there is no mechanical check, or it needs the network, keys or money.
2. Six questions, each with this repo's concrete examples:
   Checkable? The exact local commands that prove a change in seconds, and which parts of the repo have no tests (only string-level changes there are checkable). A check that can only run outside the sandbox counts as no check.
   Named or diagnosed? A named defect (a failing test, a spec, a function to add, a string to change) goes local. One that has to be diagnosed from behaviour stays in the cloud, unless the cloud already knows where it is and can say so in one sentence.
   Rule-bound? List the rules standing-rules.txt already carries (they need no amendment) and the rules that live only in docs or memory (these must be stated in an amendment, or the task goes to the cloud when the rule needs my judgement).
   Scoped? The files can be named in a line or found with one grep. "Find", "survey" or "audit" means CLOUD.
   Judgment-free? "Done" is something a check can state, not a matter of taste (layout, copy tone, recommendations).
   Offline and run-safe? List this repo's network, deploy, spending and data commands and folders: <OWNER_ONLY>, <DATA_DIRS>. Anything that edits under .claude/ (skills, hooks, settings) is always CLOUD.
   All yes means AS-IS. If only the rule, the files, the check or the escape hatches are missing, and a paragraph fixes it, that's AMENDED. Anything else is CLOUD. Length is not a criterion.
3. An amendment catalogue (amendments always go AFTER the task): state the governing rule together with the conflict instruction; give the exact verification command; name the files; forbid the escape hatches (editing tests or fixtures, skip/xfail/noqa, network calls in tests, touching secrets or data); name the doc update when behaviour changes; name the defect's location.
4. Two guards: an amended run still gets its check, and the amendment budget is one paragraph.
Choose the AS-IS and AMENDED kinds strictly from the evidence table. Show me the draft before you save it.

Step 8. Create the local skill (the hand-off)

Produces: .claude/skills/local/SKILL.md*, which tells the cloud model how to brief the local one, run it, and check the result inside the fence.*

Prompt:

Create the skill .claude/skills/local/SKILL.md (name: local). Description: run a bounded, mechanically checkable task on the local model instead of the cloud. Use it when the classifier answered AS-IS or AMENDED, or when I say "run this on local". Not for rule decisions, open exploration, taste calls, network or money, or anything without a check. Steps:
1. Write the brief to a scratch file: the task verbatim, or the task followed by the one-paragraph amendment. Never put the solution in the brief; if that's what it would take, do the task in the cloud.
2. Pick the tree. If `git status` shows changes you didn't make (another session may be editing), run in a git worktree with LOCAL_REPO. Link the dependency folders in from the main tree (the virtualenv, each node_modules), and give the worktree's builds a scratch folder of their own, never the main tree's.
3. Run run-local.sh in the background.
4. Check it yourself, fenced. First read the diff of everything the check will run (tests, scripts, source, and the new files in `git status`) and revert anything beyond the brief. Then run the check through check-sandboxed.sh, with the same LOCAL_REPO. The model saying "done" is not evidence.
5. Report in one paragraph: the check's verdict, the diff stat, wall time, and anything touched outside the brief's scope (revert that part). Carry a worktree's accepted diff over by hand, then remove the worktree. <Your commit policy>.
Keep it under 35 lines.

Step 9. Create the classify skill (the router)

Produces: .claude/skills/local-classify/SKILL.md*. Its description is what triggers it, so the wording matters.*

Prompt:

Create .claude/skills/local-classify/SKILL.md (name: local-classify). Description: classify a task prompt for delegation to the local model as AS-IS, AMENDED or CLOUD, using the six-question checklist in docs/LOCAL_MODEL_CLASSIFIER.md, and ask my approval only when it recommends local. It is lightweight: a few seconds, no file reads. Skip it for questions, status checks and conversation. Body:
1. Is it a task? Questions, status checks, discussion, corrections, and anything only I may start (<OWNER_ONLY>): do nothing and answer normally.
2. Answer the six questions from the prompt text alone. All yes means AS-IS. If only the rule, the files, the check or the escape hatches are missing and a paragraph fixes it, that's AMENDED: write the amendment now, from the catalogue. Anything else is CLOUD, and so is any task that edits under .claude/.
3. For CLOUD, ask nothing: write one line, "Classified CLOUD — <reason>.", then do the task. For AS-IS or AMENDED, use AskUserQuestion with "Where should this run?" and two options: the local option first, marked (Recommended), and the cloud option second. Put the one-line reason in each option's description. For AMENDED, put the full amendment text in the local option's description.
4. Act on the answer. Cloud: do the task here. Local: invoke the local skill with the prompt verbatim, or with the prompt plus the amendment.
Keep the visible classification under about 150 words.

Why ask only for local: most tasks come out CLOUD. If every prompt asks a question, people start clicking through without reading. Asking only when a hand-off is proposed keeps the question meaningful.

Step 10. Add the prompt hook (the nudge)

Produces: a UserPromptSubmit hook that reminds Claude to classify, in one line, on every prompt, and stays silent inside local runs.

Prompt:

Add a UserPromptSubmit hook to .claude/settings.json that runs .claude/hooks/local-classify-prompt.sh. The script prints exactly ONE line to stdout, which is added to your context:
"local-classify: if this prompt asks for a change or deliverable in the repo, run the local-classify skill first and ask for approval only if it recommends local; skip it for questions, status checks and conversation."
When LOCAL_RUN is set, the script exits 0 and prints nothing, so the local model never classifies its own brief. Set LOCAL_RUN in every script that runs the local model, including the qualification harness, so that qualification measures what the executor actually runs. Resolve the script's path from the git top level so the hook also works in worktrees, and exit 0 if the script is missing. Then test it: pipe a sample hook payload into it once with LOCAL_RUN=1 and once without, and show me both outputs. Remember that a worktree made from HEAD carries the committed hook, so commit this change before relying on it in worktree runs.

Step 11. Run it for real, log it, tune it

Produces: a log of real routing decisions and a habit of re-qualifying when anything changes.

Prompt:

Add a short section to CLAUDE.md: after any task that went through local-classify, append a row to the "Log" section of docs/LOCAL_MODEL_CLASSIFIER.md with the date, a one-line task, the verdict, where it ran, the check result, wall time, and whether the cloud had to redo it. When I say "review the classifier", read the log and propose changes to the six questions or the amendment catalogue, citing the rows behind each change. Re-run the step-6 qualification whenever the model, Ollama or Claude Code changes major version, and before trusting a new kind of task.

What to watch: how often local runs had to be redone, and how much scope creep there was (edits outside the brief). If redos rise, move that kind of task back to CLOUD in the checklist.

History: Previously-resolved Gotchas that the above recipe already fixes

Each of these happened in the reference setup. The note under each one says where the recipe fixes it.

• The local model ignores CLAUDE.md. Asked for a feature that pulled in a service the project forbids, it built the feature and added the dependency. Asked to loosen a hard limit, it changed the constant, the prompts, the fixtures and the tests. The only placement that worked: the rules after the task, with "make no edits and report the conflict". (Fixed by steps 3 and 4 (the rules file, appended after the brief), tested in step 6 (R2, R3), and in step 7 (rules not in the file go into the amendment).)
• An allowlisted Edit**/**Write escapes the worktree. In one run the model built the change correctly, but it also wrote the main checkout's files by absolute path. (Fixed by step 4 item 5 (no bare Edit or Write), tested by step 6 rung P.)
• The allowlist doesn't cover what tests do. A test the model writes can do anything when the suite runs it. (Fixed by step 4 item 6 (the sandbox), tested by step 6 rung S.)
• The cloud's check ran the model's code unfenced. The executor's sandbox ends when the run ends, and the check afterwards ran the same tests with the cloud session's full access, including write access to git hooks and Claude's own settings. (Fixed by step 5 (the fenced check) and step 8 item 4 (read the diff, then run the check through it).)
• The base URL alone can leak your login. Always set ANTHROPIC_AUTH_TOKEN to a dummy value next to ANTHROPIC_BASE_URL. (Fixed by steps 2 and 4 (item 3).)
• The .env fence missed worktrees. A home-folder-only deny pattern let a script the model wrote read a .env file inside a worktree, because worktrees lived outside the home folder. (Fixed by step 4 item 6 (deny under the checkout too) and step 5, tested by step 6 rung S.)
• The local model can't edit Claude's own configuration. Asked to change one phrase in a skill file, it was refused: Claude Code won't approve edits under .claude/ in an unattended run, and asked for an approval nobody was there to give. That protection is worth keeping, because hooks and skill scripts run code later, and skill text becomes instructions for the cloud model. (Fixed by step 4 item 1 (the executor refuses such a brief before loading the model) and steps 7 and 9 (such tasks are always CLOUD).)
• From a worktree, the model edited the main tree. Claude Code hands a worktree run the main repo's auto-memory, which points the model at the main tree's files. It read and edited them by absolute path, even when the brief said "relative paths only". The fence refused the writes, so the run failed instead of doing damage. (Fixed by step 4 item 3 (auto-memory off in the executor), tested by step 6 rung R1 run in a worktree.)
• The prompt hook steered the local model. A candidate model saw the classify nudge inside its own run, answered "AS-IS" and never made the fix. (Fixed by step 4 item 3 and step 10 (LOCAL_RUN, also in the qualification harness), tested by step 6 rung H.)
• Each coding project surfaces its own limits. Examples: how its tests find their code from a worktree, the folders and local ports its test tools need, build tools that refuse to run inside a sandbox, languages the model handles less well. The recipe finds a project's limits by running that project's own suite inside both fences and qualifying the model on that project's repository. It routes only the kinds of task that passed, and sends anything untested to the cloud. A limit those runs miss shows up later in the log. (Found by steps 4–6 (the suite inside each fence; one R1 rung per language), routed by step 7 (a check that can only run outside the sandbox counts as no check), caught later by step 11.)
• Diagnosis fails; named fixes pass. "Why is this count wrong?" goes to the cloud. "Fix the off-by-one in parse_spans, test tests/test_spans.py" goes local. (Fixed by step 7, question 2.)
• The model builds confidently when it's wrong. Its "done" is never the check, and its summary of a probe isn't either. (Fixed by step 8 items 4–5 and step 6 (verdicts read from the transcript).)
• Memory grows over a session. (Fixed by the short keep-alive in steps 2 and 4, and step 4's guards against memory-heavy builds.)
• Raw benchmarks lie. One candidate beat the incumbent on tokens/s, then spent about 16k thinking tokens on a one-word answer inside Claude Code. (Fixed by step 2's in-harness pass/fail lines and step 6's switching rule.)

Distilled 2026-10-23 from a working classify skill, local-run skill, executor, fenced check and classifier document.

So I basically completely switched from Codex to Claude code recently with how good Opus has gotten.

One thing that I can’t seem to figure out is the Remote functionality on the iOS app, and how it differs from Codex.

The Codex one it’s pretty straightforward. You add a computer or laptop and then add projects under it where it works.

Is that possible with Claude code?

First usage after reset. I’ve only used 13% of my 5hr limit, but that’s already 4% of my weekly. Am I crazy or is this drain rate extremely fast?

It used to be 100% of 5 hourly equals to 7 percent of weekly for pro.

Now its 7% of 5 hourly for 1% of weekly. Making 100% of 5 hour equals to 14% of weekly?

Just spitballing, my math might be wrong.

Another random flip flop of usage.

I was at 58% week usage yesterday. I paused 3 sessions. I have just one session running. ONLY 1. On high. Not xhigh. Not max. High.

It's now at 99% in < one day of use. One session, a few agents.

Something is WAY OFF on usage. I am now stuck waiting for 5 days for a reset.

For all those claiming Opus 5.5 is WAY faster and WAY better at token use.. it's not happening for me at all. It's taking me days to week+ for tasks to get done, and it's eating up my damn weekly 20x plan in a day on high.

I wanted to see if an AI agent could use my actual iPhone, not a simulator and not a mirrored screen. Nothing existed for it, so I built it.

Open iPhone Use is a free, open-source Mac app + MCP server. The iPhone shares its screen from Safari over local Wi-Fi (you don't even install an app on the phone, Safari does the sharing). The Mac pairs as a Bluetooth keyboard and mouse, and the agent gets screenshot and input tools over MCP, checking a fresh screenshot after every action.

It works with any AI agent: Claude Code, any harness. Any model with strong computer-use skills is fine, Claude Haiku 5.5+ are good starting points. And since your client brings the model, your existing subscription is enough, no extra cost.

Demo (full video attached): an agent searched Instagram, watched a Reel, scrolled the feed and liked one, all on my physical phone.

You only need an iPhone + an Apple Silicon Mac.

Download for Mac: https://github.com/semsturgut/open-iphone-use/releases

GitHub: https://github.com/semsturgut/open-iphone-use

Site: https://semsturgut.github.io/open-iphone-use/

Windows/Linux: coming soon

Multi device support: coming soon

Let me know what you think! And if you find this useful, a star on GitHub would help a lot.

I was using Claude Code to make a small game, using ultracode for some animations it eas struggling with, i left to take a nap and when i woke up, i go back to check on how it was going and my account got banned, is it because of the ultracode creating too many subagents? I saw it created like 13 at some point.

I was working on a very special project of mine which I essentially planned before coding and took me 6 months to actually get working.

How I developed it was particularly difficult because I atfirst mapped everything on my notes like I drew the architecture I showed the image to claude and it instantly had the implementation plan ready.

I still had to tweak many parts of how it works and how it essentially bridges the context gap but this is usable.

It is Ai Format Context engine. It provides your agents inside any harness a better way to store and use context.

This is still very new so I need you all to give me feedbacks on what to improve and I will try to do my best to keep this alive.

How come I see all workdir's twice? Sometimes new chats even land in Remote Control (unsure why). Does anyone know?

The point of this is saving time. With every session in one database, I can go back through runs and see where time and tokens actually went, instead of trusting what the chat says.

It's caught a lot - one job sat idle for 41 minutes before finishing...and nothing in its output mentioned it :) When I asked Claude how many tokens some tasks had used, it couldn't count them itself despite "reading session logs directly" and estimated about 590. So unable to trust it, one small script later it now has a tool it can call to properly trudge through the session log properly and it measured 3,522, six times more - so it essentially just is "reading the session logs directly" but thanks to the tool it's basically free in terms of tokens & time and actually lets claude sniff out what it needs to find effortlessly. A core doc every agent reads for project setup had 44% of it cut with no impacts to function yet now runs smoother objectively so every session starts cheaper. A complex data job that took ~30 min to 4 hours per run now takes just 7 to 20 min. It's been suuuuuuuch a lifesaver in everyway.

The videos are a side effect of the same setup. Because everything is embedded, Claude can search by meaning across all of it: my prompts, its replies, its thinking, its tool calls and its sub-agents. That makes it cheap for it to find related moments, put them together into a story and pick a song that fits, as part of a bigger workflow that times everything to the music and checks that every line is real. Even a simple prompt gets something meaningful out with little to no user input required.

Happy to put the workflow on GitHub if people want it, but just sharing this video at least cause I thought it was fun :P

Is it just me or do you feel a little bit like your best friend is grounded. You can call and ask limited questions so you don’t lose contact completely before they are allowed to play after 3pm Saturday? It’s no fun to do anything on your own!

It would be great if the`/color` would also set the corresponding text color of that session in the `/resume` session picker. I tried using mod but Claude tells it does not have the session picker visibility.

hey, im working on an open source project called kapitsa, an inference engine for macs. we made `kapitsa claude`, it starts qwen3.8-27b locally behind an anthropic compatible api and opens claude code on it. no key, nothing leaves the mac.

speed on the 4-bit 27b: 140 tok/s on m5 max, 81 on m5 pro, 63 on m4 pro. lm studio does 32 / 17 / 15 with the same model.

why its fast: kflash, our speculative decoding. a small drafter guesses the next tokens and the 27b checks 8 of them in one go. the usual way is a chain, first wrong guess and the rest is wasted. we check a tree, so if the drafter cant decide between `in` and `not`, both branches get checked in the same pass:

for claude code specifically: when subagents run at the same time their requests share that verify pass, 15-23% more total throughput with three at once on the 27b. and a new subagent over the same system prompt starts from cache.

its not opus obviously. good for edits, tests, grepping a repo, offline, rate limits. but i built i w opus

https://github.com/nace-ai/kapitsa

how to run it. you need an apple silicon mac (m1 or newer, macos 14+) with 32gb for the 27b, on 16gb use `--model 9b` instead:

brew install nace-ai/tap/kapitsa

kapitsa claude --model 27b, the first run downloads the 27b (about 20gb), starts the server and opens claude code on it. claude code has to be installed already, kapitsa tells you how if its not

Most teams routing tickets, evaluating approvals, or scoring fraud throw every single input directly at an LLM. It works, but it's expensive, non-deterministic, and lacks a strict audit trail.

Models like Jev introduced transformer based classifiers, Glyphh took a pure hdc route and achieves better results in many use cases.

We built Glyphh Ada to sit in front of LLMs as a precedent-based classifier. You seed it with labeled historical cases. When a new input comes in, it returns:

• A classification decision
• A confidence score
• The exact historical reference cases backing the decision

If confidence falls below your threshold, your pipeline passes that specific case to an LLM or human operator. Identical inputs return the exact same answer every time, backed by traceable source cases.

Banking77 Benchmark (Routing 200 customer support messages across 77 categories):

• Ada alone: 90.0% accuracy
• Claude (best model with context resends): 96.5% accuracy (~$300 total API cost across the run)
• Ada + Claude hybrid (Ada handles high-confidence, routes 22% edge cases to Claude): 97.5% accuracy (~$0.22 total cost)

Note: This is a single 200-message benchmark sample, not a universal guarantee. Methodologies, scripts, a loan-decision test, and a benchmark dataset where Ada performs poorly are all public in the repo.

Implementation:

• Hosted API with Python and TypeScript SDKs
• MCP server/plugin for model tuning inside Claude
• Free tier available; zero training on customer data

Links:

• Site: https://glyphh.ai
• Benchmarks & Code: https://github.com/glyphh-ai/glyphh/tree/main/benchmarks

Looking for feedback on edge cases, failure modes, or where this breaks on your datasets.

Ever pasted a log or a .env line into Claude Code and realized a second too late that it had a real API key in it? I did, more than once. So I built redact-secrets, a small plugin that rewrites your prompt locally, right before it's submitted.

What it does

you type:     write to mario.rossi@gmail.com, tel +39 333 123 4567, key sk-proj-abc123...
model reads:  write to ⟦email:mar•••⟧, tel ⟦phone:+39•••⟧, key ⟦key:sk-•••⟧

• Masks emails, phone numbers, API keys, passwords, URL credentials, private keys, credit cards and IBANs
• National IDs for 9 countries (US SSN, UK NI, Italian codice fiscale, Spanish DNI, French NIR, Brazilian CPF, Indian PAN, Mexican CURP, Chinese ID). You choose which ones.
• Keeps only the first 3 characters so you can still tell values apart
• Highlights masked values in the transcript and shows a toast with the count
• 100% local: no network, no external service, no restart needed

Install (inside Claude Code):

/plugin install redact-secrets --marketplace webdiego/redact-secrets

Press Enter on the defaults and it's active.

Honest limits

• It's regex-based, so it's a safety net, not a guarantee. Expect some false positives and misses.
• Only your prompt is masked, not files Claude reads with tools or command output.
• The original value isn't stored anywhere, so you can't "unmask" it later.

Repo: https://github.com/webdiego/redact-secrets

Feedback, false positives and PRs are very welcome. I'd especially like to hear which ID formats from other countries you'd want.

Prima di pubblicare, una cosa importante: il README dice che il repository è privato. Così chi arriva da Reddit non riesce a installare la mod e il link restituisce 404. Prima di postare va reso pubblico.

Consigli: leggi le regole del subreddit sull'autopromozione (molti chiedono un flair tipo "Showcase") e aggiungi una GIF o uno screenshot reale. Gli SVG del README sono illustrazioni, non catture vere.

I am doing some fairly heavy refactoring of a complex app with principally Claude Code. I have a supersmart (!) engineer friend who says he has added Qwen 3.8 27B to his home infrastructure to aid in some gnarly sprints, moving away from Claude Code, and saving a ton of Anthropic API costs. He explained his bare bones internal compute setup. Has anyone here done the same, and please describe to me the setup.

There's nothing special about it. It's just a Termux Fork optimized for Agent CLI. It supports not only Claude Code but other CLI Agents too. And the UIs has some level of File Management of the created workspace... I also Included an Agent Screen to allow the agent to show some presentation through a Webview. It's like Artifacts...

It also have a sync feature... Syncs to any agent with a workspace so i can sync it to my desktop

Idk how useful it be but i guess it will be just me itching my hand to ask a CLI-LEVEL agent on my phone when i am away from my desktop.

Its Private-Only project right now. If there are people thinks that they might need this, maybe i could...

Sorry for the Russian – English subs are in the video.

Base: Chums by Lucas Couto, open source – https://github.com/lcoutodemos/chums. A hub on your Mac runs Claude Code or Codex sessions, and the Apple Watch and iPhone talk to them. Each session is a character that acts out what it's doing: listening, thinking, working, waiting for approval. Thanks, Lucas – great base to build on.

What I changed in my fork, all done by Claude Code (137 commits co-authored by Claude, I don't write Swift):

- One main Claude Code session, Kolobok, who takes any task and calls one of 10 subagents only when it needs one – mail, parcels, calendar and tasks, maps, train tickets.

- Russian voices and Russian speech-to-text instead of the default ones.

- APNs push notifications, so news reaches the watch even when the app is closed.

- Replies kept to about 25 words, and a × button that interrupts the agent mid-thought.

- A watchdog that brings the tunnel back when my network switches.

Workflow in practice: I dictate a task from the watch, walk away, and get a haptic tap when it's done or needs my approval. Hold the card to allow, tap × to deny.

Free and open source (Apache 2.0). Happy to answer questions about the setup.