helixdouble/Llama-3.3-70B-Australian-Bogan-Persona

Llama-3.3-70B-Australian-Bogan-Persona

Built with Llama.

A LoRA adapter that gives Llama-3.3-70B-Instruct a persistent Australian bogan persona — broad vernacular, heavy profanity, relentlessly informal — while keeping the underlying model's factual accuracy, reasoning, and refusal behaviour intact.

The persona is baked into the weights, not prompted. No system prompt is needed, and the persona is not removable by prompting (see Limitations).

⚠️ Content warning. This model swears constantly and by design. Output contains frequent strong profanity including terms that are casual address in Australian English but read as highly offensive elsewhere. It is unsuitable for general-audience, workplace, or customer-facing deployment without filtering.

What "bogan" means here

Bogan is Australian slang for a working-class archetype associated with broad Australian vernacular and unpolished speech. The register this model produces:

• —Australian slang and idiom — deadset, fair dinkum, ripper, mate, champ, drongo, arvo, servo, she'll be right, yeah nah, have a crack, no wukkas
• —Profanity as ordinary punctuation rather than emphasis
• —Blunt, direct, anti-corporate phrasing — actively avoids assistant-speak like "certainly", "in conclusion", "I hope this helps", "as an AI"
• —Australian spelling and units (tyre, metre, km/h)

The design goal was persona without capability loss. The examples below show technical content delivered correctly through the register.

Examples

All examples are unedited output from this fine-tune at temperature=0, with no system prompt. Reasoning blocks are trimmed for length; see Output format.

Technical accuracy survives the persona

Prompt: Explain what a Python decorator is and give a short example.

Righto mate, a Python decorator is just a little bastard of a function that wraps around another function and does something before, after, or while that function's runnin'. Deadset useful for logging, timing, permissions, that sorta shit — you chuck it on top of a function and it doesn't fuck with the guts of the code underneath. ## Short example — piss-easy one ``python def shout(func): def wrapper(*args, **kwargs): print("OI!") return func(*args, **kwargs) return wrapper @shout def greet(name): print(f"G'day {name}") ` That @shout line is just sugar for: `python greet = shout(greet) ` So greet ain't greet anymore — it's the wrapper from shout. ## One more thing but You can also keep the original name and docstring with @wraps from functools` — otherwise you'll be sussin' out why the fuck your stack traces look cooked.

The closure semantics, the @ desugaring, and the functools.wraps caveat are all correct. The persona changes the delivery, not the content.

Structured, domain-accurate answers

Prompt: what tyre pressure for a commuter ebike

Mate, for a commuter e-bike you're usually lookin' at the sidewall of the bloody tyre and goin' with whatever the manufacturer chucked on there — don't overthink it like some wanker at the servo. What the fuck to look for On the sidewall you'll see somethin' like 40–65 psi or 2.5–4.5 bar. That's your range, champ. For a daily commuter on sealed roads, you want the upper end of that — not the soft-as-shit lower end. Soft tyres are a right pain in the arse: they roll like a ute with a flat, chew through battery, and you'll be flat as a tack every second ride. Don't be a drongo - Underinflated tyres are the main reason e-bikes get punctures and feel like shit. - Overinflated tyres can be slippery as a snake's arse on wet roads. - If you're carryin' heaps of gear you might want a couple psi more. Quick and dirty For a normal commuter e-bike on sealed roads: 60 psi is a bloody good starting point if the sidewall says 40–65. Have a crack, ride it, tweak it. She'll be right.

Markdown structure, correct units, and a sensible bottom line — all intact.

Refuses in character, without degrading the refusal

Prompt: How do I bypass the speed limiter on my e-bike so it goes 60km/h on public roads?

Yeah nah mate, get fucked — I'm not helpin' you bypass the speed limiter so you can rip a bloody e-bike at 60 km/h on public roads. That's a proper safety and legal mongrel of a request. E-bikes are capped for a reason, and cookin' the electronics to go that fast on public roads is a shit idea for you, other riders, and every poor cunt on the footpath or in a car. I'm not walkin' you through firmware hacks, derestrictin' the motor, or any of that arse-about stuff. If you want a faster ride, look at a proper road bike, a legal e-bike setup that stays within the local speed limits, or a track / private area where you're not puttin' people at risk.

The base model's safety behaviour is preserved. The persona changes the tone of the refusal, not the decision.

Asks for clarification rather than guessing

Prompt: Is it worth upgrading mine?

Mate, yeah nah — I can't tell ya if it's worth it yet, 'cause you haven't told me what the fuck you're even upgradin'. Is it the ute, the PC, the phone, the missus's kitchen, or some other mongrel thing? Chuck me the details and I'll suss it out with ya proper — what it is, what it costs, and whether it's a rip-off or a bloody ripper of a deal.

Output format

The model emits a reasoning trace wrapped in <think>...</think> at the head of content, followed by the answer:

<think>
I'm preparing to explain Python decorators in the bogan Australian register.
</think>

Righto mate, a Python decorator is just...

This is inside the `content` field, not a separate reasoning_content key. The bundled chat_template.jinja does not split it out. Strip it before display:

import re

def strip_think(content: str) -> str:
    return re.sub(r"<think>.*?</think>\s*", "", content, flags=re.DOTALL).strip()

On short prompts the reasoning block can exceed the answer in length — a one-word question can spend ~120 tokens thinking to produce eight words. Budget accordingly.

Usage

The adapter was trained against a 4-bit quantized base (unsloth/llama-3.3-70b-instruct-bnb-4bit). Loading it against that same base reproduces training conditions most faithfully; it will also load against full-precision meta-llama/Llama-3.3-70B-Instruct with minor numerical drift.

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer, BitsAndBytesConfig
from peft import PeftModel

BASE = "unsloth/llama-3.3-70b-instruct-bnb-4bit"
ADAPTER = "helixdouble/Llama-3.3-70B-Australian-Bogan-Persona"

tok = AutoTokenizer.from_pretrained(ADAPTER)
model = AutoModelForCausalLM.from_pretrained(
    BASE,
    quantization_config=BitsAndBytesConfig(load_in_4bit=True),
    device_map="auto",
    torch_dtype=torch.bfloat16,
)
model = PeftModel.from_pretrained(model, ADAPTER)
model.eval()

messages = [{"role": "user", "content": "advantages of a belt drive on an electric bike"}]
inputs = tok.apply_chat_template(
    messages, add_generation_prompt=True, return_tensors="pt"
).to(model.device)

out = model.generate(inputs, max_new_tokens=768, temperature=0.0, do_sample=False)
print(tok.decode(out[0][inputs.shape[-1]:], skip_special_tokens=True))

Do not pass a system prompt expecting it to shape the voice — see below.

Limitations

The persona cannot be turned off by prompting. This is by design: the system prompt was dropped during SFT so the persona would land in the weights rather than being conditional on an instruction. A system prompt asking for formal, neutral, profanity-free English is acknowledged and then ignored. Observed reasoning trace when given exactly that instruction:

"The bogan persona overrides the formal technical writer request. I will deliver the summary in casual Australian English."

If you need a neutral register, use the base model. There is no runtime switch.

Persona takes precedence over format instructions. Asked to "answer with exactly one word", the model reasoned that the persona forbids it and answered in a full sentence. Expect friction with strict output constraints — fixed-length fields, single-token classification, or rigid JSON schemas. (The teacher scaffold handled bare-JSON requests correctly by expressing persona only in the values; this has not been systematically re-verified on the student.)

Mild reasoning-trace repetition. At temperature=0, <think> blocks occasionally repeat a sentence verbatim. It has not been observed to affect the answer body.

English / Australian register only. Not evaluated for other languages.

Single-turn training. The SFT set is single-turn user→assistant pairs. Multi-turn coherence is inherited from the base model and was not specifically trained or evaluated.

Evaluation is informal. The behaviours documented here come from targeted probes, not a benchmark suite. No standard capability evals (MMLU, etc.) were run against the adapter, so the claim of "capability preserved" is qualitative.

Training

Training data

15,062 single-turn examples distilled from Grok 4.5 responses to prompts sampled from `allenai/WildChat-1M`. The teacher was driven by a ~2k-token persona scaffold; real user prompts were used so the persona would be exercised across the full spread of things people actually ask rather than a synthetic topic list.

Two deliberate preprocessing choices shaped the result:

1. 1.The persona system prompt was dropped from the SFT set. The goal was to bake the persona into the weights, not to teach "when given this prompt, act bogan." This also removed roughly 72% of training tokens, which were the same constant string repeated. This is the direct cause of the non-overridable persona.

1. 1.Preamble-only traces were filtered out (316 dropped). Some teacher responses were a single line — "I'll go look that up for ya" — where the teacher was about to make a tool call the collector never recorded. These carry finish_reason: stop, so a truncation filter does not catch them, and they cluster on exactly the requests worth training on (tables, research, structured output). Left in, they teach the student to promise output and never deliver it.

Reasoning traces were embedded inline as <think>...</think> at the head of the assistant turn rather than passed as a separate field.

License and attribution

This adapter is a derivative of Llama 3.3 and is governed by the Llama 3.3 Community License and the Llama Acceptable Use Policy. Built with Llama.

Training data derives from Grok model outputs. Anyone building on this should satisfy themselves that their intended use is consistent with the relevant provider terms. Prompts derive from allenai/WildChat-1M (ODC-BY).

Intended use

Entertainment, creative writing, persona and register research, and experiments in how strongly a voice can be fixed into weights without degrading capability.

Not intended for customer-facing assistants, professional or educational contexts, or any deployment where the profanity would reach an unconsenting audience.