There is a repo at 69,953 stars that most people will glance at, decide is not for them and close. It is a job search tool. Stay with me, because what it does underneath is the most useful pattern I have seen in a Claude Code project this year. https://github.com/career-ops-hq/career-ops Point career-ops at a job listing and it gives you a structured report, section A through H, with one score out of 5 at the top. Then it tailors your CV, drafts the outreach and tracks the application. Runs locally inside Claude Code. MIT, one command to install. Here is the part worth stealing. The scoring rules are not in the code. The modes, the archetypes, the weights, the templates are all plain markdown and yaml sitting in the project. Claude reads those files to do the work, which means Claude can also rewrite them. The README says it outright: ask it to change the archetypes or adjust the weights and it knows exactly which file to edit, because it is the same file it just read. That is the lesson. It has nothing to do with job hunting. Most people bury their agent's rules in a prompt or in code. Every tweak then goes back to whoever wrote it. Put the rules in files the agent reads and tuning becomes a conversation. You say the scoring is too soft on budget. It edits the weight. You run it again. Swap the job listing for a lead and you have client qualification. Swap it for a post and you have a scoring rubric for your own content. Same shape every time: a rubric in a file, a structured report out, one number at the top so you can sort. Straight with you, I have not run this in anger. I am pointing at the architecture, not the results. This week, take one thing you judge by gut and write the rubric down. Five criteria, a score each. Then ask Claude to score your next three against it and tell you where the rubric itself is wrong. What is the one call you make on instinct that you would never hand to a rubric?

...and it is cheaper than the model it replaces. Around 25% cheaper on typical work, up to 45% on heavy agentic work. https://www.anthropic.com/claude-fable-and-mythos-5-1 Input and output prices did not move at all. Still $10 per million in, $50 out. The entire saving comes from one line item most people have never looked at: cache reads, cut by 75% to $0.25 per million. Which raises the question worth sitting with. Why is the same price cut worth 25% to one person and 45% to another? Because on context-heavy, tool-heavy work, cache reads are not a rounding error on your bill. They are most of it. Every turn of an agent re-sends the same system prompt, the same tool definitions, the same files it already read. Anthropic measured this over four weeks of real usage and published the chart, so it is not a guess. The lesson has nothing to do with which model you run. If your setup is not caching, you are paying full input price for the same context on every single turn. The longer the session runs the worse it gets. That was expensive before yesterday. It is now four times more expensive than it needs to be. So go and check whether you are actually getting cache hits, rather than assuming. In the API the response tells you directly. A timestamp in your system prompt or a tool list that reorders itself is enough to silently kill every hit you thought you had. Anyone actually looked at their cache hit rate, or is it one of those numbers we all ignore?