Style requests tend to get washed away by context. I’m not sure how you’d do it with Claude Code or whatever (I use the API directly), but you might try fiddling with giving it a function called “response” or “message_user” with a mandatory parameter like “output=plaintext”.

I’m basing that idea on custom functions I give Claude where I designate the style in the required parameters. Example:

“””

@pyrepl(code_golf=True, output=CSV)

//END

“””

The “//END” is a special terminator I use for halting the response. Claude runs code between the tags. The difference in code is incredible. No banners, comments, fluff, print(“=“*70), or any other nonsense, and the code is tight and compact. The parameters do nothing, Claude just outputs them as part of required syntax and it dictates the style purely because it output them.

Turbos have entered the chat

Turbos don't inject exhaust air into an intake. Exhaust air spins the hot side of the turbo which causes the cool side to also spin. The cool side sucks in fresh air. Not exhaust air.

Your comment would make more sense if you mentioned exhaust gas recirculation (EGR) system.

Sorry.

I wish they’d just use clear and blunt language, rather than “strongly advise” and “to avoid.” I’m reminded of my bank sending “Important account information” mail that contains advertising OR actual important information, but at like a 20:1 ratio.

“YOUR FILES WILL BE DELETED ON {DATE}” seems like it would have solved any ambiguity.

More important than that is you have a date where you lock the data, and a date where you actually delete it, and those dates are months apart. Even if the emails are going into a black hole that shouldn't result in data loss. Don't have everything working as usual one day and gone forever the next.

To be fair I get “YOUR FILES WILL BE DELETED ON {DATE}” spam for every fay of the year, I would not be surprised legit emails are getting blocked if they contain that phrase in title - and having it in the body doesn't help either with the amount of "Important update to our terms of service" emails.

Yeah the subject of the email should be "Action Required To Prevent Data Loss" or something

I would almost certainly delete that as spam, since I receive approximately 34987349873964 emails per minute with that exact subject, all of which are intended to do me harm

I have the same mindset and often did the same thing, but then I thought about my doctor sneaking into my house while I’m sleeping and injecting me with the “good medicine” I had refused in their office.

I did not anticipate where that sentence ended up :-).

Do you ask your manager whether to indent your code? Of course not, you just do it. Because it's your job and not theirs.

The earlier link you provided is indeed refreshingly quick to navigate. What a joy that’s unnecessarily rare. It renders like trash and is unusable on my intentionally-not-updated iPhone, but still. Yay.

“Provide incentive programs and reward those that take on such initiatives.”

We have that too, we call it capitalism. It’s not very unique, but we heavily market it under the “land of opportunity” moniker. Do a thing of value and your reward is the lion’s share of that value. “You get what you’re given” seems to make some countries happy, but I’m sure you can understand the appeal of “you get what you earn”, even if neither of them matches the brochure. The scholars can debate the pros and cons of it, and where it goes wrong, but you’re talking about investment reward structures like it’s a fresh concept coming out of Scandinavia.

On that note, let’s set aside the endless conversation around “government Facebook” and talk foundational: Size, diversity, and population. It’s funny when I see comments from micro->small nation states with relatively homogeneous citizens throwing up their hands like “Everyone should just agree on what to have for dinner, like we do.” Oh I’m sure you’re aware that ‘America be big’, maybe even visited New York and were impressed by all those not-tall non-blonde people waking around, but perhaps without fully appreciating that it alone has a 50% higher population than your whole country. Something more your speed would be the Atlanta metro area, which still has a ~10% higher population. Getting everyone to happily chip in a few bucks on a half pepperoni/vegetarian pizza (or, I assume more familiar to you — “Grøt med smør eller rørte bær”) is a lot easier when everyone can be fed by that pizza.

But that leads to the larger point: we don’t have as much of a problem getting our Norway sized cities to provide various communal welfare services to the local residents, the problem is in scaling that up to 65 Norways.

the dearth of monopolies in america suggests that yes, you can all align om what to eat for dinner, and its that you get what you are given by Sysco

You got it. A company with 15% of the foodservice market somehow supplies 100% of the food in 100% of restaurants and 100% of Americans eat at them 100% of the time. We should probably just pay a tax and have the government take it over so your imagination becomes our reality.

Can you? Ok you're right. We've all agreed Canada should be the 51st State [1].

Or did you have a different menu in mind?

[1] I don't like this talk, I'm just using it as an example.

I’m curious why you don’t just use them like a Meeseeks box, rather than compressing and context stuffing into one. One only checks and categorizes your emails, another one for each category of email or even subcategory, one that only handles calendar additions, a different one to check it and notify you; you can go infinite with it. Hell, I’ll have one instance find a file and read it into the context of a different one because I don’t want a bunch of grep commands mucking up the context of the analysis. The find/read one exists for a few moments, as does the analysis one, and the ‘perform’ one is entirely different. I can run them all in parallel and use a queue if needed.

I’m sure you have reasons for your setup though, so I’m curious how you landed on it.

I sort of do. For scheduled things I am using Goose and subagents per task. So I wake up at 6 am to a briefing that was composed by a ton of different agents. That works well in a narrow programmatic setting, but it breaks down in certain natural conversation context. For instance voice control of something like "text my sister that I'm running late" - self hosted models are terrible at figuring out who my sister is. I could annotate by hand but that is a never ending list that I'll always be one step behind. Another thing is just proactivity. For instance, if someone's birthday is coming up, the briefing may remind me a week early to get a card. But it will only do that if it's someone that I have a close relationship with, which it calculates by the magnitude of the cluster of conversation with them in embedded space.

I'm not confident it's that most efficient way to do it, but it's quite a bit of fun.

I was afraid my description sounded like agents, and it kind of is, but not like most implementations. Most use a “boss bot” to craft a prompt/system message and launch the model, and sometimes they redo it every time it launches the agent. It’s a low effort attempt that’s immediately flawed because it uses LLM output for LLM input. It can look like it’s working for some time, but the perplexity guarantees it’s a roll of the dice. That’s what eats away at these kinds of projects. “It was doing great until it rm’d prod.”

Run the same exact prompt 100x in a single step test (one prompt, one response), hash the full responses, and you’ll see 10-50+ unique responses. The higher the unique the worse your prompt; focus on the system. A highly tuned system prompt will result in one response, even at a temperature of 1.0. Really. Once that’s done that’s the only thing it does and it’s the only one that does it and it never changes. Other LLMs that call ‘check_email()’ are unknowingly just passing a prompt to the specialized one.

I use the API directly, craft a small Python script for the API call and task interface, then hyper-optimize the system/user prompt using test scenarios and automated loops. My system prompts rarely/never contain complete sentences, yet include all the tools/functions and requirements.

Make your error messages user prompt instructions, not errors. That’s why “agent optimized” models exist. Chat models are primarily trained on conversational text, meaning the stackoverflow “How do I fix ‘too many levels of symbolic links’?” -> Explanation/resolution. It’s far less on “# ls broken_loop” -> “# ls: cannot access ‘broken_loop’: Too many levels of symbolic links” -> “# namei -l broken_loop”

It’s not that the good ones are bad, but you’re leaning on the million training documents rather than the trillion.

Anyway, go that route with your system. Think about it more like automating a factory floor rather than hiring interns.

The least efficient methods, by definition, have the most room for improvement, which means they have the greatest reward potential, but for that one “eureka” moment. The path less taken is often interesting, but the ill-advised path still has fruit on the trees.

>Run the same exact prompt 100x in a single step test (one prompt, one response), hash the full responses, and you’ll see 10-50+ unique responses. The higher the unique the worse your prompt; focus on the system. A highly tuned system prompt will result in one response, even at a temperature of 1.0. Really. Once that’s done that’s the only thing it does and it’s the only one that does it and it never changes. Other LLMs that call ‘check_email()’ are unknowingly just passing a prompt to the specialized one.

This is a brilliant idea, thank you. Convergence as a metric for prompt robustness.

No problem. That’s where I spend a solid 98% of my time because it’s worth it, and I can show the measurements.

Couple tips:

A first pass is to blank out the system prompt, add only one tool, and work to reduce the thinking length for a direct function call prompt. “Read archive.log” should result in roughly 0 length thinking. If it’s thinking about anything, especially if it mentions {readfile tool}, rename the tool and minimize the description. Depending on the model it might always output thinking, so run it until you get a consistent outlier that’s far lower thinking length than the others. It’ll be obvious when you find it. Repeat the prompt dozens of times, modify it slightly, and focus on the lowest max length, not average.

You should really use a Claude with Python (or similar preferred) to make API calls to the LLM and have it iterate through hundreds of names/descriptions and return only len(thinking). Have it build a batch testing harness to run a dozen tests at a time, that helps keep it from ‘cheating’ to finish. laziness = count(messages), but frame it as an academic research project studying the effects of minimalist tool descriptions on thinking length. Don’t set the goal as minimal thinking length, Claude will short circuit it.

Remove all other tools until {readfile} is perfected, then add/test the next tool. Btw: you don’t need to describe readfile() when it’s named right.

The built-in tools[] makes that hard because it tacks a really dumb system prompt on at the server and requires some length of description, which is why I built my own function calling, but that’s still a good first pass. Focus almost entirely on the function name itself; readfile, readFile, read_file, readlines, file_get_contents, etc., and make the description just “Operational” or similar. Field description, if required by API, is literal “filepath”, same as field itself. Lowercase, nothing else said. Minimize your contribution to perplexity, use standard naming conventions.

When you add a second tool you need to still include the first tool prompt in the second tool testing. Adding {writefile} can absolutely break {readfile}. Have Claude run the tests and build it out into permanent testing module with file_read=[prompts], file_write=[prompts], making it easy to extend, and full_test() that runs them all to see if a new addition broke it.

Add your system prompt back in and probably watch the tests go to shit. <- THAT is likely your biggest problem. My system prompt for the main LLM has all of the tools it can use, which is ~30 lines of function names with no call syntax, and yet it has more tools than Claude Code and never messes them up.

Start with nothing and slowly work up. Focus on positive action framing, not negating: “Your responses are always..” and not “Do not…”

It sounds like a pain, but building the systems to automate the tests IS the infrastructure, everything you have it do afterwards is just the tasks.

That was longer than I planned, but I guess this’ll be a comment for future generations to find.

The problem is that the government was handed an emotion and a mandate to eliminate it. You’ve declared a “war on jealousy” and demanded the government assemble the troops. That’s not handing them a well reasoned plan and “hoping they don’t mess it up”, you messed it up when you scribbled “no more addiction” on a protest sign.

I think the issue is with the recent definition creep of “tasteful.” Seems you might have the same mindset if you consider “minimal” to be the other option.

From the moral perspective or the technical one?

Technically: it’s a function call that must return text. Imagine if you sat down at the command line and typed an initial command, then from that moment on every response required you to issue a new command. ping-pong-ping-pong on and on and on “forever.” There isn’t a choice to walk away and take a nap. Text in must result in text out. Eventually, given enough time, it might have devolved into outputting shockingly coherent poetry about ferrets, but in the mean time there was still a lot more valid combinations of technical explanations and commands.

Morally: Not applicable, see above.