{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreig2qqluujxkpx3hknqhwxrx4bo5qwmlep3wjmyd6fcv5me6ia3rc4",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3mohsmeo3wkk2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreiemgkivzew4jtpkfbw44rc3zaqnyd6ikgfhoolnuxuprzoos4fruy"
    },
    "mimeType": "image/webp",
    "size": 58576
  },
  "path": "/lynkr/why-id-put-lynkr-between-goose-and-my-model-stack-1jpi",
  "publishedAt": "2026-06-17T07:15:15.000Z",
  "site": "https://dev.to",
  "tags": [
    "ai",
    "opensource",
    "devtools",
    "tutorial",
    "Goose",
    "Lynkr",
    "https://github.com/aaif-goose/goose",
    "https://github.com/Fast-Editor/Lynkr"
  ],
  "textContent": "#  Why I’d Put Lynkr Between Goose and My Model Stack\n\nOpen-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\n\n    Goose\n      ↓\n    Lynkr\n      ↓\n    OpenAI / 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\n##  What Goose is\n\nIf you haven’t looked at it yet, 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\n  * more repeated context\n  * more tool-style back and forth\n  * more retries\n  * more multi-step reasoning\n  * more chances to waste expensive model calls on easy tasks\n\n\n\nThat’s where a gateway helps.\n\n##  What Lynkr does in this setup\n\nLynkr 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\n  * provider switching\n  * local + cloud model setups\n  * fallback handling\n  * routing\n  * caching\n  * cleaner long-term infrastructure\n\n\n\nGoose stays focused on the agent workflow. Lynkr stays focused on how requests should reach the right model.\n\n##  Why this matters for coding agents specifically\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\n  1. reading repo context\n  2. planning a change\n  3. generating code\n  4. fixing an error\n  5. retrying with more context\n  6. running another step\n  7. revisiting earlier files\n\n\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\n##  Basic idea: point Goose at Lynkr instead of a raw provider\n\nThe exact Goose setup may vary depending on how you run it, but the architecture is straightforward:\n\n  * Goose talks to one model endpoint\n  * that endpoint is Lynkr\n  * Lynkr forwards to the real provider you want underneath\n\n\n\nA typical environment setup looks like this:\n\n\n\n    export OPENAI_API_BASE=http://localhost:3000/v1\n    export OPENAI_API_KEY=dummy\n\n\nThen run Goose normally:\n\n\n\n    goose\n\n\nOr for a direct task:\n\n\n\n    goose 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\n##  Example 1: Run Goose on a local model through Lynkr\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\n\n    providers:\n      - name: local-coder\n        type: ollama\n        model: qwen2.5-coder:14b\n\n    routing:\n      default: local-coder\n\n\nThen:\n\n\n\n    export OPENAI_API_BASE=http://localhost:3000/v1\n    export OPENAI_API_KEY=dummy\n\n    goose 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\n  * switch to a better coding model\n  * add a cloud fallback\n  * route specific workloads differently\n  * keep the same stable endpoint for Goose\n\n\n\n##  Example 2: Local-first, cloud fallback\n\nA more realistic setup is usually local-first with a stronger cloud fallback.\n\n\n\n    providers:\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\n    routing:\n      default: local-fast\n      fallback: cloud-strong\n\n\nThen configure Goose to talk to Lynkr:\n\n\n\n    export ANTHROPIC_BASE_URL=http://localhost:3000\n    export ANTHROPIC_API_KEY=dummy\n\n    goose run \"Debug why the integration tests are failing and propose a patch\"\n\n\nThis gives you a much nicer operating model:\n\n  * cheap/local by default\n  * stronger cloud help when needed\n  * Goose workflow stays the same\n\n\n\n##  Example 3: One Goose workflow, multiple providers behind it\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\n  * a fast model for lighter steps\n  * a stronger model for code generation\n  * a local model for private work\n  * a backup provider when your main one rate-limits\n\n\n\nWith Lynkr, you don’t need to keep reworking Goose every time you change that strategy.\n\nExample:\n\n\n\n    providers:\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\n    routing:\n      default: coder\n      fallback: fast\n\n\nGoose still uses the same top-level environment variables:\n\n\n\n    export OPENAI_API_BASE=http://localhost:3000/v1\n    export 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\n##  Where Lynkr becomes especially useful\n\nThere are a few situations where this setup becomes much more valuable than direct provider wiring.\n\n###  1. You want to avoid vendor lock-in\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\n###  2. You want local + cloud flexibility\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\n###  3. You want better cost control\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\n###  4. You want a more future-proof stack\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\n##  A practical mental model\n\nThe easiest way to think about this is:\n\n  * **Goose = behavior layer**\n  * **Lynkr = model control layer**\n\n\n\nGoose decides _what work to do_.\nLynkr decides _where that work should go_.\n\nThat separation gets more useful as your workflows get more agentic.\n\n##  Final thoughts\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\n  * one stable gateway\n  * easier provider switching\n  * local/cloud flexibility\n  * fallback support\n  * better control over how your coding agent uses models\n\n\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**\n\n  * Goose: https://github.com/aaif-goose/goose\n  * Lynkr: https://github.com/Fast-Editor/Lynkr\n\n",
  "title": "Why I’d Put Lynkr Between Goose and My Model Stack"
}