5. TungstenTool -- Ant-only tmux virtual terminal giving Claude direct keystroke/screen-capture control. Singleton, blocked from async agents.
6. Magic Docs -- Ant-only auto-documentation. Files starting with "# MAGIC DOC:" are tracked and updated by a Sonnet sub-agent after each conversation turn.
7. Undercover Mode -- Prevents Anthropic employees from leaking internal info (codenames, model versions) into public repo commits. No force-OFF; dead-code-eliminated from external builds.
ANTI-COMPETITIVE & SECURITY DEFENSES
8. Anti-Distillation -- Injects anti_distillation: ['fake_tools'] into every 1P API request to poison model training from scraped traffic. Gated by tengu_anti_distill_fake_tool_injection.
UNRELEASED MODELS & CODENAMES
9. opus-4-7, sonnet-4-8 -- Confirmed as planned future versions (referenced in undercover mode instructions).
10. "Capybara" / "capy v8" -- Internal codename for the model behind Opus 4.6. Hex-encoded in the BUDDY system to avoid build canary detection.
11. "Fennec" -- Predecessor model alias. Migration: fennec-latest -> opus, fennec-fast-latest -> opus[1m] + fast mode.
UNDOCUMENTED BETA API HEADERS
12. afk-mode-2026-01-31 -- Sticky-latched when auto mode activates
15. fast-mode-2026-02-01 -- Opus 4.6 fast output
16. task-budgets-2026-03-13 -- Per-task token budgets
17. redact-thinking-2026-02-12 -- Thinking block redaction
18. token-efficient-tools-2026-03-28 -- JSON tool format (~4.5% token saving)
19. advisor-tool-2026-03-01 -- Advisor tool
20. cli-internal-2026-02-09 -- Ant-only internal features
YOLO CLASSIFIER INTERNALS (previously only high-level known)
36. Two-stage system: Stage 1 at max_tokens=64 with "Err on the side of blocking"; Stage 2 at max_tokens=4096 with <thinking>
37. Three classifier modes: both (default), fast, thinking
38. Assistant text stripped from classifier input to prevent prompt injection
39. Denial limits: 3 consecutive or 20 total -> fallback to interactive prompting
40. Older classify_result tool schema variant still in codebase
COORDINATOR MODE & FORK SUBAGENT INTERNALS
41. Exact coordinator prompt: "Every message you send is to the user. Worker results are internal signals -- never thank or acknowledge them."
42. Anti-pattern enforcement: "Based on your findings, fix the auth bug" explicitly called out as wrong
43. Fork subagent cache sharing: Byte-identical API prefixes via placeholder "Fork started -- processing in background" tool results
44. <fork-boilerplate> tag prevents recursive forking
45. 10 non-negotiable rules for fork children including "commit before reporting"
DUAL MEMORY ARCHITECTURE
46. Session Memory -- Structured scratchpad for surviving compaction. 12K token cap, fixed sections, fires every 5K tokens + 3 tool calls.
47. Auto Memory -- Durable cross-session facts. Individual topic files with YAML frontmatter. 5-turn hard cap. Skips if main agent already wrote to memory.
48. Prompt cache scope "global" -- Cross-org caching for the static system prompt prefix
> This is the most expensive failure mode with AI-assisted coding, and it’s not wrong syntax or bad logic. It’s implementations that work in isolation but break the surrounding system.
This is spot on. Zooming out, a perfectly written implementation that follows all the conventions but misses the mark on its business goal is as, if not more, expensive. I think adding a brief.md artifact to the beginning of the flow (where you store the problem, desired change, primary metric, feature-kill criteria) can go a long way.
There's a great video from "Technology Connections" covering one-pedal driving here [1]. The gist of it is that one-pedal breaking doesn't have a great way to control the break lights, making it difficult for the cars behind you to recognize that you're slowing down, which can cause accidents.
Thank you for putting the list together! If I may make a suggestion, what you wrote above would be an excellent first paragraph in the readme, as it explains the intent well and the criteria for how you add books to the list.
If you'd like to use something like this in your own APIs to let your clients filter requests or on the CLI (as is the intention with gron), consider giving "json-mask" a try (you'll need Node.js installed):
If you've ever used Google APIs' `fields=` query param you already know how to use json-mask; it's super simple:
a,b,c - comma-separated list will select multiple fields
a/b/c - path will select a field from its parent
a(b,c) - sub-selection will select many fields from a parent
a/*/c - the star * wildcard will select all items in a field
> Start by running the migration helper on a current project. We’ve carefully minified and compressed a senior Vue dev into a simple command line interface. Whenever they recognize an obsolete feature, they’ll let you know, offer suggestions, and provide links to more info.
Vue's docs are a masterclass in docs-writing, imho. Clear. Concise. Empathetic. Written for humans.
I think the difference is that the browser already contains the shadow dom needed to render the video tag. But for a custom tag it would need to fetch, parse and execute your component code before it can begin to render.
I’m excited about this. There’s usually a ton unnecessary CPU usage with the current techniques, not to mention the human time waste of re-implementing them in JS. There’s feature detection for this too, so we can gracefully degrade “loading” to existing solutions and take advantage of it right away.
Great news for PWAs buried in the release notes: “Updated the behavior of websites saved to the home screen on iOS to pause in the background instead of relaunching each time.”
> Toshi is a three year old Shiba Inu. He is a very good boy and is the official mascot of this project. Toshi personally reviews all code before it is commited to this repository and is dedicated to only accepting the highest quality contributions from his human. He will though accept treats for easier code reviews.
There are two requirements that I personally don’t feel very comfortable with: the first one is uploading a picture of my ID (How is it stored / backed up. Who has access: third party validator or your team?) and the other is adding logmein to let a proctor control my machine prior to the exam. I saw that one may take the exam in person. I don’t know if it’s allowed by your rules, but I suppose I can set up a VM for this, but either way that just makes it more difficult for me to justify finding the time to do it.
- nuxt (or next if you prefer react)
- tailwind (atomic css)
- node
- express
- passport (Use cookie based auth keeping the session in your storage. I wouldn’t waste time on JWT. There’s a decent amount of complexity if you want both the security of being able to revoke access to a bad actor and the convenience of long lived sessions, and at the end the auth server will most likely need to access storage and use cookies for that anyway (eliminating the benefits of JWT). So I’d start with cookie based auth and build up complexity as needed.)
- postgres
- On the Node side, I don’t recommend adding the complexity of an ORM at first (or ever). The node pg driver will give you arrays of objects back for rows. It’s convenient enough not to need the extra overhead of an ORM.
- As a side note, Postgres has modules for you to implement a decent first version of a lot of things, such as search for example, before you need to reach for a dedicated solution. This makes it amazing for startups in my opinion, as you can explore ideas very quickly.
- statsd / grafana (to monitor your app and learn from the behavior of your users)
- docker-colpose.yml to make spinning up your dev environment with node / db / stats as simple as “docker-compose up”
- DigitalOcean for hosting
- Use their dokku image
- Set up daily backups to Spaces since your DB will be hosted here at first too
- dokku for deployment with the Postgres, letsencrypt and grafana modules
- deployments are as easy as “git push master dokku”
No surprises here this year: es6 & typescript, react & vue. I think I’d put redux and graphql in different categories as they’re not mutually exclusive. Nevertheless, I’m happy to see excitement for the latter.
I follow the check-in model from Adobe [1]. It isn’t a hard set of requirements, but is more of a set of topics that help guide the conversation. It’s especially helpful as a starting point for people new to management, like myself.
A check-in meeting is made up of three parts: (1) setting expectations, (2) providing feedback, (3) having a development conversation.
Status reports are explicitly not a part of this conversation. Those are easy to talk about, but have little value for your employee, and if you’re already doing daily stand-ups, they have little value for you too.
The first two topics are fairly self-explanatory, yet take time to learn to do well. The expectations must be clear, finite and actionable. Much has been written about the art and science of giving good feedback. I use a model where we talk about the Specific thing that happened, followed by Asking questions to understand their perspective, talking about the Impact of their actions on themselves and the people they have affected, and finally talking about what I expect them to Do now or in the future. (aka SAID)
The development conversation is the time for you to listen. This is where you learn about the professional skills they are working on growing (whether it’s public speaking, a particular career path or, say, a machine learning course, to name a few) and finding ways to help and facilitate those. If done right, you learn a lot about the person, their goals, aspirations, and will be in a better position to make a positive meaningful impact on their life.
The check-in is most effective if it’s guided by the employee. This encourages people to come with topics they care about and gives them the ability to focus more time on a particular aspect of the meeting which may be more important at that time.
I think it's a beautiful, thought out, polished and well built set of UI components. If that's what I needed for my next project, I wouldn't hesitate to use it. The docs are excellent too. There's so much attention to detail here. There's an immense amount of love poured into this project, even the code snippets are interactive.
The title of this submission is a bit misleading. This script parses the .vue file and extracts the three sections into x-template script, Vue.component script and a style. These are not standalone in the sense that they cannot exist without vue and vue-template on the page (the later is large and unnecessary when compiling with webpack). Essentially this does what the vue webpack plugin does naïvely and without many of the features like support for different template / JS / style language compilation (e.g. Babel and sass).