I gave my local LLM an escape hatch to Fable 5, and it solved the problems I couldn't

Published Jul 21, 2026, 6:00 AM EDT Anurag is an experienced journalist and author who’s been covering tech for the past 5 years, with a focus on Windows, Android, and Apple. He’s written for sites like Android Police, Neowin, Dexerto, and MakeTechEasier. Anurag’s always pumped about tech and loves getting his hands on the latest gadgets. When he's not procrastinating, you’ll probably find him catching the newest movies in theaters or scrolling through Twitter from his bed. Local LLMs are great. They’re very efficient, and at a time when API costs are increasing and AI tools are becoming more expensive to use, local LLMs are the way to go. I’ve been using Ollama to run Qwen 2.5 coder, and it’s quite good. The model is able to build things, fix bugs, and understand my requests almost as well as a Claude model, but of course, it has its limitations. It’s constrained by my hardware and its parameter count. It’s a 7-billion-parameter model, and the context window I can run locally is also smaller. It’s not very good at complex tasks, and it sometimes gets stuck and keeps trying the same thing again and again without ever finding an answer. So I recently decided to give the little fellow some help. Now, whenever my local LLM gets stuck, it can call the most capable model out there, Claude Fable 5, and that has allowed it to solve problems that it couldn't even with my intervention. Giving Qwen an escape hatch Fable 5 did wonders to my local setup I could have simply replaced Qwen with Fable 5, but that would defeat the purpose of running a local model. Qwen 2.5 Coder handles most of my regular coding work without requiring an API call, and I still want those tasks to remain local. Calling Fable for every request would increase my costs, send more of my code to a cloud service, and leave most of my local hardware unused. Instead, I kept Qwen as the primary model and gave it access to Fable 5 as a tool. Qwen still receives the original request, examines the project, edits files, and runs any required commands. Fable only enters the process when Qwen has tried solving a problem and cannot make further progress. This gives the smaller model somewhere to turn without transferring the entire task to Claude from the beginning. The handoff is also more focused than starting a separate conversation with Fable. When Qwen needs help, it prepares a short report containing the problem, relevant code, approaches it has already tried, and the current error output. Fable examines that information and returns a possible diagnosis or solution. Its response then goes back into the same Ollama session, allowing Qwen to apply the recommendation and continue working with the context it already has. Building the connection between Ollama and Fable 5 Ollama already supports tool calling Connecting both models was much simpler than I initially expected because Ollama already supports tool calling. I only needed to create a small Python function that sends a request to Fable 5 through Anthropic’s API, then make that function available to Qwen as a tool. This does require an Anthropic API key. I started by installing the Ollama and Anthropic Python libraries. The actual function accepts four pieces of information from Qwen — the problem it’s trying to solve, the approaches it has already attempted, the current error output, and any relevant code or project context. It combines everything into a focused prompt and sends it to Fable 5 using Anthropic’s Messages API. import os from anthropic import Anthropic claude = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"]) def ask_fable( problem: str, attempts: str, error_output: str, relevant_context: str, ) -> str: """Ask Fable 5 for help with an unresolved coding problem.""" prompt = f""" Problem: {problem} Attempts already made: {attempts} Current error: {error_output} Relevant context: {relevant_context} Identify the cause and suggest a concrete solution. Do not repeat approaches that have already failed. """ response = claude.messages.create( model="claude-fable-5", max_tokens=4000, messages=[{"role": "user", "content": prompt}], ) return "\n".join( block.text for block in response.content if block.type == "text" ) The last step was passing this function to Qwen through Ollama’s tools parameter. Ollama converts the function and its arguments into a tool definition that the model can understand. from ollama import chatresponse = chat( model="qwen2.5-coder:7b", messages=messages, tools=[ask_fable],) Whenever Qwen calls the tool, the Python script executes the function, sends the supplied context to Fable, and adds its response to the ongoing Ollama conversation. Qwen can then use that response while continuing the original task locally. At this point, the connection is working, but Qwen still needs clear rules for deciding when a problem actually deserves an API call. Knowing when to call Fable is the difficult part I added clear conditions to the system prompt Giving Qwen access to Fable was easy, but deciding when it should use that access required more work. A smaller model doesn’t always recognize that it’s stuck. It can continue changing the same function, rerunning the same test, and producing slightly different versions of an approach that has already failed. If I simply tell it to ask Fable whenever it needs help, it can also escalate ordinary problems that it could have solved locally. I added clear conditions to the system prompt instead of leaving the decision entirely to Qwen. It must attempt the task locally first, and it can only call Fable after two materially different approaches have failed. A repeated test failure alone isn’t enough if Qwen hasn’t actually changed its approach. The tool should only become an option when the model cannot explain the error, identify another reasonable solution, or make measurable progress. Call ask_fable only when:1. Two materially different solutions have failed.2. The same error remains after both attempts.3. You cannot identify another reasonable approach.Before calling the tool, collect the exact error, relevant code,failed approaches, and expected behaviour. The information sent during escalation matters just as much as the timing. Sending the entire project would consume more tokens, increase the cost of the API call, and expose files that Fable doesn’t need. Qwen instead sends the relevant functions, the exact error output, a short description of the expected result, and a summary of what it has already attempted. This gives Fable enough context to diagnose the blocker without uploading the complete repository. Fable 5 is really something Anthropic recently made Fable 5 available globally again after considerable controversy, during which the US government asked the company to restrict access for non-US users. The new model is one of the best available, if not the best. OpenAI’s new Sol models come close, and Moonshot AI’s latest model, Kimi 3, is also quite good, but Fable 5 remains the best model out there, especially for technical use cases.