Most of the open-weight versus managed debate gets framed as a single, once-a-year decision: pick one approach and run the whole business on it. That framing does not match how the businesses actually getting value from this are operating. Analysts covering the shift note that organisations are increasingly running hybrid architectures, using open-weight models for practical, high-volume, lower-stakes work while keeping a managed platform for anything judgment-heavy or client-facing.
For an Australian small or mid-sized business, hybrid is usually less about ideology than arithmetic. A small self-hosted model handling a high-volume, low-risk task can genuinely cost less per unit than an API call. The same self-hosted model handling a client-facing task with real consequences is a false economy once you count governance, monitoring and incident response.
Where the split usually lands
High-volume, low-risk internal tasks go to a cheap self-hosted model: bulk document classification, first-pass data extraction, routine reformatting, internal summarisation.
Client-facing communication, anything touching compliance or financial reporting, and any task where a wrong answer has real cost goes to Claude, where safety testing, monitoring and support already exist.
The mistake we see most often is businesses starting the hybrid conversation from the wrong end. They ask what can be moved to open source to save money, then treat everything not explicitly ruled out as fair game. The better question is the reverse: what actually needs the governance a managed platform provides. Answer that first and the rest of the list sorts itself.
What this costs in practice
A Sydney business we worked with recently ran the numbers on a genuine hybrid stack. A self-hosted open-weight model handled roughly 70% of their document processing volume at a fully loaded cost, including infrastructure and oversight, of around $1,800 a month. Claude handled the remaining 30% of client-facing and compliance-adjacent work at comparable spend.
The combined bill came in lower than an all-Claude approach would have, and meaningfully safer than an all-open-weight approach would have been. Both halves of that sentence matter. A hybrid stack that only saves money is a cost exercise; one that also contains risk where risk is expensive is an architecture.
Three questions before you build one
Can you draw a clean line between internal and low-risk versus client-facing or compliance-relevant for every task on your list? Or does the line blur in ways that need a human decision anyway, in which case the split is doing less work than it appears to.
Do you have the engineering capacity to maintain two systems rather than deploy them? A hybrid stack roughly doubles your operational surface area, and maintenance is the cost that gets forgotten.
Is the saving on the open-weight side large enough to justify the complexity, or does it evaporate once maintenance time is counted at real rates?
If the answer to the third question is that the saving is marginal, the right hybrid stack is no hybrid stack. Complexity you cannot justify is just complexity, and a single well-run platform beats two poorly maintained ones every time.
The failure mode worth naming
The version of this that goes wrong is not usually a dramatic incident. It is drift. A task starts on the cheap side of the line because it was internal, then someone starts pasting the output into client emails because it was there and it was good enough. Nobody made a decision. The line moved because nobody was watching it.
Two things prevent that, and both are cheap. Write the line down, in plain language, in a document someone owns. And review it quarterly against what people are actually doing rather than what the architecture diagram says, because the gap between those two is where the risk accumulates.
How to start without committing to the whole thing
You do not need to architect a hybrid stack to find out whether one is worth having. Pick the single highest-volume internal task on your list, the one nobody would describe as sensitive, and run it on a cheap model in parallel with your current setup for a month. Compare cost per completed task and error rate, and count the hours someone spent keeping it running.
Choose a task where the output is already reviewed by a person, so a bad month costs attention rather than a client.
Track maintenance hours honestly from day one. This is the number that decides whether the second system is sustainable, and it is the easiest one to under-record.
Set a threshold in advance for what saving would justify keeping it, so the trial produces a decision rather than an ongoing science project.
Worth adding one caveat for smaller businesses. If your total inference spend is under a few hundred dollars a month, a hybrid stack is almost certainly not worth building. The saving is small, the operational overhead is not, and your engineering attention is better spent on the workflow itself. Hybrid earns its keep at volume, and below that volume the honest advice is to run one platform well.
The hybrid stack is not complexity for its own sake. Done properly it cuts cost on the workloads where cost matters while keeping the expensive-to-get-wrong work somewhere accountable. If you want help working out where the line should sit in your business, book a session and we will map your tasks against it.
