@Christoph-Hart said:

I would add the Pi agent as a viable harness option

I've tried a handful of other harnesses but ended up feeling most comfortable in Claude Code.

The beauty for CC for me is the subscription. The amount of token usage I get compared to paying API pricing in other harnesses is substantial.

I do want to try some of the cheaper models in another harness though, to check what the quality is like compared to Fable. I'll check out Pi, looks cool.

Rewind a couple of years ago and I had no idea what I was doing with any of this. I was pasting HISE scripts into a ChatGPT window, getting back something 80% right, pasting it into HISE, pasting the error back, and so on. It worked, sort of, but it was slow and the model never really knew what my project looked like. Later I moved to Cursor, so the model could at least see all my code. But since then I've moved to doing everything in the terminal instead of a full IDE.

This post is the setup I've ended up with for building Sublime, the plugin I released this month. And it's the setup I use for all other coding tasks too - building static websites, writing Ruby on Rails web applications, making Mac apps, etc.

This post is based on Claude Code because that is what I use, but pretty much everything here has an equivalent in the other tools. If you already run an agent locally you won't learn much here. If you're very new to AI, or still in a Claude/Codex/Gemini browser tab, read on.

As with all setup posts like this, your mileage may (very likely will) vary.

1. The layers, because the names are confusing

The single most confusing thing when you start is that "AI" is at least four separate things stacked on top of each other, and people use the names interchangeably.

The models and their overlords

The model is the thing that actually thinks. Each overlord company makes their own model(s). Anthropic (company) makes Claude models (Opus, Sonnet, Haiku, and now the Fable/Mythos tier), OpenAI (company) makes GPT (model), Google makes Gemini. The model is just text generator, lovingly known in some circles as a 'bullshit generator' . It takes text in and gives text out - that's it.

Christoph's rule of thumb in the agentic thread was that Opus 4.6 or an equivalent was the floor for HISE work, and anything smaller is a false economy. I agree, but that was a while ago, so adjust your baseline accordingly. For my work, I only ever use the best model available from the provider I use. Right now, that's Anthropic's Fable 5.1.

The harness

The harness (also called the agent, or the CLI) makes the model feel conversational and personal. It reads your files, runs shell commands, edits code, calls tools, and loops until the job is done. It's really only passing text to and from the model but it's also adding all the context needed for a continual, useful conversation.

Claude Code is Anthropic's agent/harness. Codex is OpenAI's. opencode is the open-source one Christoph uses. Cursor, Zed, VS Code with Copilot, and Google's Antigravity are editors with a harness built in. The harness is a choice independent of the model: opencode and Cursor can run Claude and other models, Claude Code can only run Claude.

I've been very happy with Claude Code in the terminal for many months now, only tweaking the actual terminal app that I use - currently using herdr.

The context files

These files are plain markdown you leave in your folders for the harness to read at the start of every session. Claude Code reads CLAUDE.md; most of the others read AGENTS.md, and the two are converging (Christoph said his hise-cli templates will be agents.md). This is the layer that turns a clever generalist into something that knows YOUR project. Most of this post is about these.

The tools

The things the agent/harness can call out to beyond the shell: MCP servers (a protocol for plugging a tool into any harness), language servers, and plain command-line programs. For HISE this means Christoph's HISE MCP server, hise-cli, and the HISE REST server inside the editor.

Show me the money!

A subscription (Claude Pro or Max, ChatGPT Plus, a Cursor plan) gives you a monthly allowance with rate limits. An API key is pay per token, no ceiling, but it's usually more expensive for a comparable amount of access. Beginners should start with a subscription so a runaway loop just means you run out of tokens rather than facing a massive API bill at the end of the month.

I'm currently on the Claude Max plan at £90/mo I was on the Pro plan at £20/mo for quite a while, but when I stepped up production I started running out of tokens too early. I do get close to the token limit now, on £90/mo, so the next step up for me is £180/mo. But in terms of productivity gains, and compared to how much human help you could hire for £180/mo, the cost is tiny.

Usage on Claude is rate-limited by 5-hour and weekly windows. Supposedly so the overlords can manage bandwidth of their mega-cloud-thinking-machines, but the relaity is usually fine for regular work.

The highest-end Claude Fable model has its own rate limit because it uses a lot more resources than the lower Opus/Sonnet models. As I write this on a Saturday afternoon, I'm at 95% Fable usage for the week, which resets on Tuesday, so I'll definitely hit the limit before then.

2. Why local beats the browser

The browser chat is the model with limited abilites and environment.

In a regular AI chat session, you play the agent. You copy files in, copy answers out, run the code and report back. Every round trip loses detail, and the model only ever sees the fragments you chose to paste.

In a Claude Code browser session at least you can connect to your project repo on GitHub. But you're still working in an isolated environment. The model can only see your repo code. You migth think that's all you need, but the real power in agentic coding comes from all the things and actions around the project repo.

Running the agent in the project folder changes the job completely:

• It reads the full project. The whole script tree, the UI XML, the presets, project_info.xml, samples, untracked files, everything.
• It reads the HISE source. ~/Code/HISE is on the same local disk. When the docs are vague about a LookAndFeel obj field or what setIntensity expects, the agent opens the .cpp and reads the implementation. This is the single biggest quality jump I've had. The majority of the "HiseScript hallucination" problem goes away when the model can check the HISE source.
• It runs things. Shell scripts, git, node checkers, sox for audio analysis, the build. It can write a script to migrate 125 presets and then run it, instead of giving me a script to run.
• It compiles and test the UI for real. With the HISE running and the REST server on, it can recompile the project and take a screenshot of the interface, and iterate until it's right.
• The conversation is attached to the files. Decisions get written into the repo (more on the ai/ folder below) instead of staying isolated in a chat tab.

One correction to something I wrote in Christoph's thread back in March: I said terminal agents lose the chat history when you close the window. I since learned that Claude Code keeps every session and the /resume command lets you pick an old one up with its full context. Cursor's tabbed history is still friendlier, but the capability is there. And at the end of the day, this is all just text files on your machine. They're shuffled away in hidden Claude folders, but they're there. You can back them up, make a searchable archive of all your agent sessions from day one (I just did that), and move them between machines.

3. The context files, and why there are three of them

This is the heart of the setup. The harness reads context files from several places and stacks them, so each file can hold the rules that belong at that level. I have three, plus one import.

NOTE: If you don't use Claude, your file name and location will be different, for example ~/.codex/AGENTS.md for Codex. Also, any paths mentioned are Mac - adjust for Windows/Linux.

3a. The global file: ~/.claude/CLAUDE.md

Rules about ME and this MACHINE, which apply to every project. Nothing about HISE lives here, and nothing about inidividual projects. Examples from mine:

• Never commit unless I say "commit" in the current message. Finishing a task is not permission to commit.
• Never run a build unless I asked for one in this message. A build overwrites the plugin I may be auditioning.
• Never touch files outside the repo.
• Never give me a multi-line terminal command. When I paste them they often break.
• No em-dashes or en-dashes, anywhere, ever. Hyphens only. (I only use characters I can type.)
• Assume I know nothing about Windows. Give every Windows step click by click.
• Audio analysis is pure Python, after sox.

Notice these are mostly "never do X without asking". Each one was added the day the agent did X. That is how the file grows, not by sitting down and writing all the rules at the start, but by writing one line each time something bites.

Take the MERGE_HEAD issue I had recently. When that was resolved I asked Claude to add a note to ~/.claude/CLAUDE.md so that every new coding session is aware of the problem and the solution.

3b. The plugin repo: my-project/CLAUDE.md and my-project/HISE.md

This is a separate CLAUDE.md file with specific context for this project.

The HISE knowledge lives in a second file, HISE.md, pulled in with one line at the top of CLAUDE.md:

@HISE.md

HISE.md is about HOW TO WORK ON A HISE-BASED PROJECT in general (not how to work on the HISE source code itself - that's below). What the MCP server is for and when to use it, where the HISE source is and which directories answer which questions, the audio-thread timer pattern, the HiseScript gotchas I've hit (inline locals shadowing namespace members, getModulator being onInit-only, scriptnode Smoothing being in seconds whatever the display says). Nothing in it names the plugin, so I can copy it into the next plugin repo unchanged.

CLAUDE.md itself is about THIS plugin and the decisions that are not derivable from the code: the naming convention for component ids and plugin parameters, why the top-bar panel is declared after the main sections (VST3 parameter order), which switches are fronts for hidden sliders, which features are hidden for 1.0 and how to ship them later, the pre-release checklist, how the two XML files stay in sync. It is long (7500 words) and every paragraph has a date and a reason, because "why" is what the agent cannot reconstruct from the code.

The split matters. If you mix the HISE mechanics in with the project decisions you cannot reuse them. Keeping them in their own file means the next plugin starts with everything I've learned so far.

3c. The HISE source clone: ~/Code/HISE/CLAUDE.md

A third file, for when I am working ON the HISE source rather than WITH it in a project. It says which branch is mine, which tracks upstream, that builds are mine to run, that the agent may commit only when asked. Then the C++ conventions (unity builds, tabs, Allman braces, the USE_BACKEND / USE_FRONTEND split, the lock-free threading rules), and a pointer to the guidelines/ folder Christoph added for exactly this purpose.

The reason this is a separate file and not a section of the plugin repo's file is that a session started in the plugin repo reads the plugin rules and a session started in the HISE clone reads the HISE rules. Each one gets its own proper set of rules.

4. Giving the agent reach beyond the project folder

By default the agent/harness works in the folder you started it in and asks before reading outside it. For HISE work you want it to reach:

• The HISE source (~/Code/HISE). The agent greps hi_scripting/scripting/api/ for the real signature of a scripting call, hi_core/.../floating_layout/ for the FloatingTile content types, and so on. My repo file tells it which directory answers which question so it doesn't repeatedly search the whole thing.
• The HISE MCP server (Christoph's hise_mcp_server, cloned and built with npm run build). Registered in the repo's .mcp.json so any harness that opens the folder gets it. The docs tools are always available and are much cheaper in tokens than fetching the HISE docs website; the runtime tools (recompile, screenshot, read/set component properties) work when HISE is open with Tools > Enable REST Server.
• hise-cli, which is absorbing the MCP server's runtime side. Compile over REST works from the CLI since 0.8.6 / HISE 4.9.3.
• The installed plugin's AppData folder, read-only, for checking what the shipped plugin actually wrote.

In Claude Code the permission for an outside path goes in the project's .claude/settings.local.json (or claude --add-dir ~/Code/HISE at launch). Mine has the AppData folder and the MCP tools allow-listed; the HISE clone itself I just approve when asked, which in practice is once per session. Other harnesses have the same idea under a different name.

Two habits worth adopting:

1. Tell it which world it is in. The HISE editor and the exported plugin are different binaries with different preprocessor flags. A define you turned on in the editor's jucer does nothing in the export unless project_info.xml says it too. I shipped three months of linear filter modulation that was logarithmic in the editor before I learned this. My repo file now has a paragraph on it, and the agent catches it for me.
2. Decide who edits what. The CLI and MCP edit the project in HISE's memory; disk edits need a reload. Mixing both in one session loses work. I do script edits on disk and let HISE reload, and use the runtime tools for UI inspection and screenshots.

5. The project "brain" in an ai/ folder

This is just a folder of markdown files in the repo, committed like code.

ai/ holds durable write-ups of things that took real digging. Why plugin parameters appear in the order they do across five DAWs, what the 1.0 preset format froze and how to add controls after it, experiments that were tried and dropped (with the reasons), extensive guides for setting up and using test machines. Each file is one topic, dated, with the decision AND the mechanical reason. ai/README.md indexes them in one line each.

The HISE clone has the same folder with its own conventions: specs/ for how a subsystem works anchored to file:line, discovery/ for things found out that are not in the docs, todo/ for diagnosed bugs with a proposed diff that has not landed yet.

The agent reads these when a question touches the topic, and it writes them when we finish an investigation. Two rules I enforce: the notes are the agent's wording, not my feelings, so they are quoted as "the note says", never as "you decided"; and when a note contradicts what I say now, I win and the note gets fixed.

Claude Code also has a per-project memory of its own (short files it writes for itself about how I like to work: "never commit unasked", "flag anything that breaks saved DAW sessions"). That's a harness feature and the files live outside the repo. Don't allow the agent to rely too much on this 'memory'. It's useful day to day, but the repo ai/ folder is the one that survives switching tools.

6. The pipeline

Everything between "the project is done" and "there is a working installer" is scripts I had the agent write and I never have to think about. A pre-release checker (version bumped in all three required places, no TEMP code left, UI XML and project XML in sync, factory preset count matches the user guide, etc.), the export via HISE's batch compile, pluginval with strictness setting, codesign and notarise the exported plugin, build the pkg, render the user guide PDF, upload it to file storage. One command. The Windows build has a twin script that runs the same checks.

None of that is HISE knowledge. It is the kind of tedious shell work the models are genuinely excellent at, and it is a good first project if you are nervous about letting an agent near your script code - let it automate your build first.

7. Random stuff

Planning. When chatting with the agent, I use phrasing like "Let's discuss how to ..." or "Let's plan a new feature called XYZ". This not only prevents the agent from writing code right away, it also frames the task as discovery/discussion rather than unplanned action.

Code IDE. You may notice I haven't mentioned using an IDE. That's because I don't use one anymore. I read the code written by Claude right in the terminal, either with git diff or in the chat output. On the rare occassion that I want to hand edit code I open that single file in CotEditor, a basic free code editor on Mac. I do regularly edit the plan files and feature specs - they're plain Markdown and form the contracts between me and the agent. But editing code, hardly ever these days.

8. If you are starting today

1. Pick a harness and a subscription. Claude Code with a Claude plan if you want the path of least setup; opencode if you want to swap models; Cursor or Zed if you want to stay in an IDE.
2. Clone HISE next to your project - you should have it anyway for building HISE.
3. Clone and build the HISE MCP server, add it to the project's .mcp.json.
4. Write a ten-line CLAUDE.md (or AGENTS.md) in the project. Include what the plugin is, where HISE is, "look up every API call before writing it", and your two or three personal rules. Add a line every time it does something you did not want.
5. Keep the global rules (about you, your machine) in the global file and the project rules in the project. Don't mix them and don't repeat details in both files - that drifts real fast and starts to contradict.
6. Start with the pipeline or a simple function change, not the DSP.
7. Commit often. The diff is your safety net. And if you're like me, insist that the commit command comes only from you.

Happy to answer questions, and I would love to hear how other people have arranged theirs, especially the opencode and Zed crowd. @iamlamprey's custom harness setup sound cool too.

@David-Healey Excellent title edit. Shame the title formatter doesn't do strikethrough.

Try these:
W̶h̶e̶r̶e̶'̶s̶ ̶C̶h̶r̶i̶s̶t̶o̶p̶h̶?̶
W̷h̷e̷r̷e̷'̷s̷ ̷C̷h̷r̷i̷s̷t̷o̷p̷h̷?̷

Seems like Godwin's Law needs updating to AI instead of Hitler

@iamlamprey said in Where's Christoph? We found him and now we talk about AI:

getting it to form coherent sentences for the first time was cool to see :D

Yeah, I bet!

Have you tried headroom with your setup? Might make it even cheaper. Or have you got that kind of functionality built in?

@David-Healey Given how it sounds like you use Claude, might not be too different.

If you only use Claude to propose/write/update code that you then read and edit, doing it in the browser works fine.

But working in a browser means your agent is running just in the repo, on an isolated cloud instance.

Using the desktop app (or the CLI as I prefer) is all local, so Claude can:

• launch HISE itself, run the hise-cli, Projucer, pluginval, auval, even launch a DAW
• run the local MCP for API lookups
• run the edit/recompile/screenshot loop with the HISE REST server for UI tweaks
• work in any folder on your machine, not just the project repo: the samples, AppData folder, etc.
• use your existing local credentials so you don't have to put duplicates in the browser

@Lindon said in Where's Christoph?:

yeah thats what everyone says..so we all end up with nothing. Which is WORSE than out of date

Well, since you asked so nicely I'll write something up to post later.

@iamlamprey said in Where's Christoph?:

Caveat in case someone thinks I'm stealing their .ch1 files with my "ch1 extractor" - I'm building out an MVP to see if I can convert my existing sample libraries into a synth and I can't be bothered downloading the original sample files lol

Don't worry - code and digital asset privacy is a thing of the past too.

It's always been possible to do all the reverse engineering that's all the rage now - the decompile libraries have been around for years. It's just that now LLMs bring us two things we didn't have before: speed and accuracy, and both at a much lower cost than hiring a human.

@iamlamprey said in Where's Christoph?:

I use Deepseek Flash and the combination works as well or better than any standard Claude / Codex setups at 1/100th the price.

Is that a subscription or API calls?

You can't really compare DeepSeek API costs with the token usage you get bundled in a Claude or Codex subscription, especially if you're driving it hard.

Comparing directly to Claude/Codex API isn't fair either, since the vast majority of heavy Claude/Codex users are on a subscription and wouldn't dream of paying API prices for those models/harnesses.

@Lindon said in Where's Christoph?:

I recall there was some stuff mentioned a few months back but Im pretty sure its out of date now...

That's why I'm hesitant to post anything along the lines of guide or instructions.

Things are moving so fast that anyone reading after a few weeks will be out of date.

But yes, a high-level config/setup would be good. Things like CLAUDE.md files, memory, etc. have always been around and will likely remain in place until the next big shift.

@David-Healey said in Where's Christoph?:

I find that the more examples I give it by editing its output the more it "learns" what I consider good code.

100% and a massively important aspect of the whole experience. AI seems like magic but it very much needs our input.

But left to a none-developer I wouldn't expect the final code quality to be acceptable.

Agreed. It believe it still takes a developer-brain to write a good spec and monitor the output.

Your CLAUDE.md files are crucial too. Don't let your model keep too much stuff in memory. Project/session memory is transient and I find it can rot. Hardcode behaviour into your CLAUDE.md files - one per repo and one high-level one in your Claude profile (~/.claude/CLAUDE.md on Mac, you'll know where to find it on Windows). And read/edit those files, don't let Claude be the only one who knows the content.

Regarding your iterations to get it understanding your repeat/don't repeat needs - just imagine describing it to a complete non-developer. Do it like that, by defining a lot context, and it might go better. And like I said above, READ the rules it writes for itself. Any failings are right int here, in plain text that you can change.

Finally, make sure you're using the best model you can. Even if that means you run out of tokens early. Fable is better than Opus for code, and I wouldn't consider ever letting Sonnet or lower models loose on code. Not even tests or docs.

Going from £20/mo Pro to £90/mo Max gives you a huge amount of headroom. Saying that, I've approached my weekly limit on Max several times lately. But there's a setting in your Usage page that occasionally allows you to reset your limit before the end of the week. When the Anthropic gods deign to offer it.

@Christoph-Hart said in Where's Christoph?:

Could this be a "skill issue" in the sense that I would have to use a better prompt / harness / multi-agent orchestrator, whatever?

Definitely a "skill issue" but not in an insulting way. Detailed prompts and interview sessions can pin down specs much better than 'shoot and hope' prompts. Not that I'm saying that's what you did.

Also, multi/sub-agent stuff has come on leaps and bounds in the last weeks/months.

Maybe, but I find it much more enjoyable working out the code myself.

I love that people feel this way, and will continue to for a long time. I'm just not one of them.

I would think of myself more of a product person than a developer. Coding is a means to an end for me, not the main enjoyable activity in itself. When coding becomes faster and more accessible I'm all for it. But I salute those who still want to hand write code line by line.

the hise-cli app is fully vibecoded and I haven't looked at the code a single time

Wow, I'm shocked! But also not surprised, given the circumstances.

@Christoph-Hart said in Where's Christoph?:

it's a 8B model which is basically useless for anything more than asking basic questions

Again, time. And at a rate we're still not really used to for technological innovation.

I'm looking back at the technology of my 80s/90s youth the same way I would've then looked back at the Victorians.

@Christoph-Hart said in Where's Christoph?:

trash code that I vibeslopped into HISE

Out of interest, what's your definition of 'vibeslopped' here?

@Christoph-Hart said in Where's Christoph?:

at least I've "died doing the thing I loved"

I also fully intend to continue doing what I love, I just won't die doing it. I'll adapt and move on.

@Christoph-Hart said in Where's Christoph?:

which is considered the pinnacle of local AI

And how long ago was it that you, and most others in this forum, said the frontier models were useless for writing code? All it takes is time.

Not only is model quality improving, but speed too. Look at ChatJimmy. It's a model hardcoded into the silicon, bypassing all the bandwidth overhead of moving to/from memory. It responds almost immediately at 15,000 tokens per second. Right now it's a simpler model compared to frontier, but try out how fast it is in conversation: chatjimmy.ai

@resonant said in Where's Christoph?:

When that moment arrives—when the AI ​​"tap" is turned off—the true value of skilled coders will become apparent, and HISE will stand out as an essential piece of software that must always remain available.

That's incredibly wishful thinking.

@resonant Local is the future.

We'll all look back with humour at the time we had to subscribe monthly to get access to LLMs and System One models.

@griffinboy I appreciate your viewpoint, but I think HISE is quite hostile to beginners.

Don't get me wrong - I'm glad it exists, and it certainly beats tackling bare JUCE. But just look at a handful of posts in this forum from beginners to see how much everyone struggles.

And yeah, you're definitely in the minority. The depths that you dive is quite amazing!

@David-Healey Sample libraries are indeed notably absent from the current deluge of vibe-coded plugins.

It's another current differentiator - our willingness and ability to accurately sample acoustic instruments or vintage/esoteric hardware.

But I think that'll go away quite soon too. The moat is shrinking every day.

@resonant HISE's pitch is 'build plugins without writing C++'. LLMs do that part easily now.

The things that will allow human-made plugins to stand out from casual vibe-coded competitors are a curated aesthetic, quality UI design, high profile collaborations, good customer support and relationships, future updates, etc. HISE helps with none of that.

@SampleScience You were the person who inspired me to start!

I've used your plugins from way back. I built my first Maize plugin around 2016 but didn't follow up on it.

Then I saw you included in a Gumroad article about creators who had made over $100,000 selling digital products on the platform. That really inspired me to start properly with plugins and now Meat Beats has been my living for 3 years now.

I'm very concerned about the future. I don't think AI is going away.