{"slug": "why-id-put-lynkr-between-goose-and-my-model-stack", "title": "Why I’d Put Lynkr Between Goose and My Model Stack", "summary": "A developer advocates for using Goose, an open-source AI coding agent, with Lynkr, an LLM gateway, to manage model routing and fallbacks. The architecture places Lynkr between Goose and model providers like OpenAI, Anthropic, or local Ollama, enabling flexible and cost-effective multi-step agent workflows.", "body_md": "Open-source coding agents are getting a lot more useful, and **Goose** is one of the clearest examples of that shift.\n\nGoose is an open-source AI agent that goes beyond autocomplete. It can inspect code, execute tasks, edit files, and work through real development loops that look much closer to *install → execute → edit → test* than traditional code assistance.\n\nThat also means Goose creates the exact kind of workload where the model layer starts to matter a lot.\n\nOnce an agent is reading files, retrying commands, generating code, reasoning across context, and iterating through multi-step tasks, the cost and reliability of your model setup stops being a background detail. It becomes part of the product experience.\n\nThat’s why I think the cleaner architecture is:\n\n```\nGoose\n  ↓\nLynkr\n  ↓\nOpenAI / Anthropic / Ollama / OpenRouter / Bedrock / Azure\n```\n\nIn other words: **use Goose as the coding agent, and use Lynkr as the LLM gateway underneath it.**\n\nIf you haven’t looked at it yet, [Goose](https://github.com/aaif-goose/goose) is an open-source, extensible AI agent built for more than just code suggestions. The project describes it as an agent that can *install, execute, edit, and test with any LLM*, which is exactly why it’s interesting.\n\nThat framing matters.\n\nA lot of developer AI tooling still assumes the model is mostly there to answer questions or generate snippets. Goose is part of the newer wave where the model is expected to participate in a real workflow. That means the token pattern changes too:\n\nThat’s where a gateway helps.\n\n[Lynkr](https://github.com/Fast-Editor/Lynkr) is an open-source **LLM gateway**. Instead of wiring Goose directly to a single provider, you point Goose at Lynkr and let Lynkr handle the model layer underneath.\n\nThat gives you one control point for:\n\nGoose stays focused on the agent workflow. Lynkr stays focused on how requests should reach the right model.\n\nIf you only make occasional direct API calls, model choice is simple.\n\nIf you use an agent heavily, it isn’t.\n\nA Goose session can easily include:\n\nThat is not one request. It is a chain of requests with different complexity levels.\n\nSome of those steps can run on a cheaper or local model. Some need a stronger cloud model. Some repeat enough context that caching matters. Some need a fallback path because a provider slows down or fails mid-session.\n\nWithout a gateway, that logic ends up scattered or simply ignored.\n\nWith a gateway, you can manage it in one place.\n\nThe exact Goose setup may vary depending on how you run it, but the architecture is straightforward:\n\nA typical environment setup looks like this:\n\n```\nexport OPENAI_API_BASE=http://localhost:3000/v1\nexport OPENAI_API_KEY=dummy\n```\n\nThen run Goose normally:\n\n```\ngoose\n```\n\nOr for a direct task:\n\n```\ngoose run \"Review this repo and suggest 3 refactors\"\n```\n\nIn this flow, Goose thinks it’s talking to its configured LLM endpoint. Lynkr handles what happens next.\n\nLet’s say you want Goose to use a local coding model first.\n\nA simple Lynkr config might look like this:\n\n```\nproviders:\n  - name: local-coder\n    type: ollama\n    model: qwen2.5-coder:14b\n\nrouting:\n  default: local-coder\n```\n\nThen:\n\n```\nexport OPENAI_API_BASE=http://localhost:3000/v1\nexport OPENAI_API_KEY=dummy\n\ngoose run \"Explain this repository structure and identify dead code\"\n```\n\nWhy do this instead of connecting Goose directly to Ollama?\n\nBecause once Goose is pointed at Lynkr, you can change the backend later without changing the Goose-side integration.\n\nThat means you can start local, then later:\n\nA more realistic setup is usually local-first with a stronger cloud fallback.\n\n```\nproviders:\n  - name: local-fast\n    type: ollama\n    model: qwen2.5-coder:14b\n\n  - name: cloud-strong\n    type: anthropic\n    model: claude-sonnet-4\n\nrouting:\n  default: local-fast\n  fallback: cloud-strong\n```\n\nThen configure Goose to talk to Lynkr:\n\n```\nexport ANTHROPIC_BASE_URL=http://localhost:3000\nexport ANTHROPIC_API_KEY=dummy\n\ngoose run \"Debug why the integration tests are failing and propose a patch\"\n```\n\nThis gives you a much nicer operating model:\n\nOne of the biggest advantages of putting a gateway under a coding agent is that your model preferences change all the time.\n\nSometimes you want:\n\nWith Lynkr, you don’t need to keep reworking Goose every time you change that strategy.\n\nExample:\n\n```\nproviders:\n  - name: fast\n    type: openrouter\n    model: openai/gpt-4o-mini\n\n  - name: coder\n    type: anthropic\n    model: claude-sonnet-4\n\n  - name: local\n    type: ollama\n    model: qwen2.5-coder:14b\n\nrouting:\n  default: coder\n  fallback: fast\n```\n\nGoose still uses the same top-level environment variables:\n\n```\nexport OPENAI_API_BASE=http://localhost:3000/v1\nexport OPENAI_API_KEY=dummy\n```\n\nThat’s the part I like most about the gateway pattern: **the agent stays stable while the model layer evolves underneath it.**\n\nThere are a few situations where this setup becomes much more valuable than direct provider wiring.\n\nIf Goose is wired straight to one provider, every change becomes a reconfiguration problem.\n\nIf Goose is wired to Lynkr, provider changes happen underneath the same gateway layer.\n\nA lot of developers want a local-first workflow but still need access to stronger cloud models when tasks get harder.\n\nThat’s much cleaner when Goose talks to one gateway instead of multiple provider-specific setups.\n\nAgent workflows can burn tokens in places that don’t need premium models.\n\nA gateway gives you a place to route easier work more cheaply.\n\nCoding agents are changing fast. Model providers are changing fast too.\n\nA stable gateway layer gives you a cleaner architecture than coupling every tool directly to every provider.\n\nThe easiest way to think about this is:\n\nGoose decides *what work to do*.\n\nLynkr decides *where that work should go*.\n\nThat separation gets more useful as your workflows get more agentic.\n\nGoose is part of a bigger shift in developer tools. We’re moving from AI assistants that mostly answer questions to coding agents that can actually work through tasks.\n\nAs that shift happens, the model layer matters more.\n\nIf you connect Goose directly to a provider, it works.\n\nIf you connect Goose to **Lynkr**, you get a cleaner long-term setup:\n\nThat’s why I’d rather put Goose on top of an LLM gateway than wire it straight to a raw provider.\n\nIf you’re already experimenting with Goose, this is one of the simplest ways to make the setup more flexible without changing the agent workflow itself.\n\n**GitHub**", "url": "https://wpnews.pro/news/why-id-put-lynkr-between-goose-and-my-model-stack", "canonical_source": "https://dev.to/lynkr/why-id-put-lynkr-between-goose-and-my-model-stack-1jpi", "published_at": "2026-06-17 07:15:15+00:00", "updated_at": "2026-06-17 07:21:20.842412+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "large-language-models"], "entities": ["Goose", "Lynkr", "OpenAI", "Anthropic", "Ollama", "OpenRouter", "Bedrock", "Azure"], "alternates": {"html": "https://wpnews.pro/news/why-id-put-lynkr-between-goose-and-my-model-stack", "markdown": "https://wpnews.pro/news/why-id-put-lynkr-between-goose-and-my-model-stack.md", "text": "https://wpnews.pro/news/why-id-put-lynkr-between-goose-and-my-model-stack.txt", "jsonld": "https://wpnews.pro/news/why-id-put-lynkr-between-goose-and-my-model-stack.jsonld"}}