Configuration — Where Do My Args Go?

There are three places to put extra launch arguments in Pitchfork, and the difference between them is the most common source of confusion. Here's the rule of thumb, then the details with screenshots.

TL;DR

Agent vs Client Instance — what's the difference?

• An Agent is the binary running on a physical machine. It might launch many clients of different types.
• A Client Instance is a configuration template (a name, a client type, a memory limit, custom args). The same Client Instance can be used by multiple agents.

When a script launches:

final_command = [JRE]
              + Agent.CustomJvmArguments        # all clients this agent runs
              + ClientInstance.CustomJvmArguments  # this specific config
              + [client-specific flags]
              + ClientInstance.CustomClientArguments  # passed to the client

So if you want a setting on just one agent (your home PC), put it on the Agent. If you want it on every machine using a particular client config, put it on the Client Instance.

Agent: Custom JVM Arguments

Open Agents → click your agent → settings panel. The Custom JVM Arguments field looks like this when empty:

Filled with example values (a sensible default for a US-based agent that runs Java clients):

The two flags shown — -Dfile.encoding=UTF-8 and -Duser.timezone=America/Los_Angeles — apply to every client this agent ever launches. Common things people put here:

• Timezone — -Duser.timezone=America/New_York
• Encoding — -Dfile.encoding=UTF-8
• Memory caps — -Xmx4096m (most clients also have a Memory field; only set this if you're overriding)
• Locale — -Duser.language=en

Client Instance: Custom JVM vs Custom Client Arguments

Open Clients → click any supported tile's Create Instance button. The form has two distinct fields under Advanced Configuration:

Custom JVM Arguments are passed to the JVM. They start with -D or -X. Example: -Xmx2048m -Duser.language=en.

Custom Client Arguments are passed to the client binary itself, after JVM args. The placeholder text is client-specific:

• DreamBot: -share-cache -layout fixed
• RuneLite-based: --script {{script}} --args {{script_params}}

That {{...}} syntax is real — Pitchfork substitutes template variables at launch time. Click Available template variables to see the full list (account name, script name, script params, world, etc.).

JAR Path — only for RuneLite and Custom

For DreamBot, Prohibition, InuBot, and TRiBot, the agent already knows where the client lives (the wrapper handles it). For RuneLite, StormClient (which uses the RuneLite client type), and Custom, you have to tell Pitchfork where the JAR is. The field shows up in Advanced Configuration only for those types:

Notable RuneLite-only fields visible above:

• Plugin Directory Path — where the wrapper drops downloaded plugins. Default examples are shown for RuneLite/Storm and Microbot.
• JAR Path (required) — absolute path to your runelite.jar on the agent machine. Must be readable by the agent process.
• Java Home (optional) — point at a specific JRE if the system default isn't compatible. RuneLite-based clients typically need Java 11.

Common mistakes

• Putting -share-cache in Custom JVM Arguments. It's a DreamBot client flag, not a JVM flag — goes in Custom Client Arguments.
• Setting heap on the Agent for one heavy script. Put -Xmx on the Client Instance instead, so other clients on the same agent aren't bloated.
• Forgetting JAR Path on RuneLite. If the field is empty for a RuneLite-based client, the launch will fail with a "JAR not found" error. The default placeholder shows the expected format.
• Setting JAR Path for DreamBot. The field doesn't appear for DreamBot (or Prohibition/InuBot/TRiBot) because the JAR is bundled. If you want a non-standard install location, talk to support.