# Concepts > How the plugin opens pages in different LLMs — strategies, prompts, and the markdown route. To make “Open in ChatGPT” actually feel like opening *this page* in ChatGPT, the plugin uses a different strategy per provider, picked to match what each service supports today. ## Strategies Three strategies cover every supported provider: ### `url-prompt` The provider supports a query-string parameter that prefills the chat input. The plugin builds a URL like: ```plaintext https://chatgpt.com/?q= ``` …and opens it in a new tab. The user lands directly in a session with a prefilled message they can submit. **Used by:** ChatGPT, Perplexity, GitHub Copilot, T3 Chat, Cursor (when under the byte cap), Grok, DuckDuckGo AI Chat, Kagi Assistant, Google AI Studio, You.com. ### `clipboard-open` The provider has no reliable URL prefill, so the plugin: 1. Copies the resolved prompt (with the page URL substituted) to the clipboard. 2. Opens the provider’s app/web entry point in a new tab. The user pastes once. This is more friction than `url-prompt`, but it’s the only honest path for providers without URL prefill — anything else would silently drop the page context. **Used by:** Claude, Gemini, DeepSeek, Mistral Le Chat, HuggingChat, Phind. ### `inline-content` The provider accepts the *full markdown body* in the URL, not just a prompt. The plugin builds a URL using the special `{prompt_with_markdown}` placeholder: ```plaintext https://cursor.com/link/prompt?text= ``` This is the ideal experience — the LLM sees the actual content, not a URL it has to fetch — but URLs have hard length limits. **The `maxBytes` budget.** When the assembled URL would exceed `maxBytes` (default 8000 for Cursor), the plugin falls back to the provider’s `fallbackStrategy`. For Cursor, the fallback is `url-prompt`, so long pages still open Cursor with a prompt referencing the page URL. **Used by:** Cursor. ## The markdown route Every strategy that mentions “the page” needs a stable URL where the page’s markdown body lives. The plugin injects a route at `/[slug].md` (configurable via [`markdownUrl`](/starlight-llm-actions/configuration/reference/#markdownurl)) that serves Content Collection entries as `text/markdown`. So if your page is at `/guides/install/`, the markdown route is at `/guides/install.md`. The dropdown’s **View as Markdown** action navigates there directly; **Copy as Markdown** fetches it client-side. The home page is the one place where the two spellings diverge. Its URL is `/`, so its Markdown lands at `/index.md`. By default that route serves each page’s raw markdown source, MDX and all. Set [`renderMarkdown: 'simple'`](/starlight-llm-actions/configuration/reference/#rendermarkdown) to serve flattened Markdown instead — components and JSX resolved down to plain prose — or point it at your own module for full control over the pipeline. [Markdown rendering](/starlight-llm-actions/guides/markdown-rendering/) compares what each mode produces. If your site already publishes per-page markdown somewhere else, set [`injectRoute: false`](/starlight-llm-actions/configuration/reference/#injectroute) to disable the built-in route, and point `markdownUrl` at your existing one. ### Which pages get one Starlight’s own `docs` collection, and nothing else, until you say otherwise. That covers most sites in full. If every page is a Markdown or MDX file under `src/content/docs/`, every page already has a route. A page can also live outside that collection. A changelog in its own collection with its own route file, or anything rendered through ``. Those are invisible to the plugin until you name their collection in [`collections`](/starlight-llm-actions/configuration/reference/#collections), which also tells it the URL template the collection is served at, since an entry id and a site path only coincide for `docs`. Until then such a page is left alone: no `.md` route, no entry in `llms.txt`, and no `rel="alternate"` link. The dropdown still renders, minus the two items that need a Markdown file. **Open in…** falls back to the page’s own URL, so a reader never meets a broken link. That is the whole failure mode, and it is why forgetting to list a collection costs you coverage rather than correctness. ## The prompt template Every “Open in…” strategy starts from a prompt template. The default is: > Read `{md_url}`. I want to ask questions about it. `{md_url}` is substituted with the absolute URL of the current page’s `.md` route — LLMs that fetch URLs get clean markdown instead of rendered HTML. Use `{url}` instead if you need the rendered page URL. You can customise the prompt globally via the [`prompt`](/starlight-llm-actions/configuration/reference/#prompt) option, or per provider via [`providers..prompt`](/starlight-llm-actions/configuration/reference/#providers). The customised prompt is what gets URL-encoded into the `url-prompt` and `inline-content` URL templates, or copied to the clipboard for `clipboard-open` providers. ## Why not a single strategy? Strategy choice is shaped by what each provider currently supports — not by what would make our integration code simpler. As of late 2025 / early 2026: * **ChatGPT, Perplexity, T3 Chat, GitHub Copilot, Grok, DuckDuckGo, Kagi, Google AI Studio, You.com** all expose query-string prefills (`?q=`, `?prompt=`, etc.) that auto-populate the input box. `url-prompt` is the cleanest experience here. GitHub Copilot’s `?prompt=` parameter was officially documented in December 2025. * **Claude.ai’s** `?q=` parameter broke in October 2025. **Gemini, DeepSeek, Mistral, HuggingChat, Phind** have no documented prefill. For these, `clipboard-open` is the only path that always preserves context. * **Cursor** uniquely supports `inline-content` via its [official deeplinks API](https://docs.cursor.com/en/get-started/deeplinks), with an 8 KB cap. When provider URL schemes change, the plugin adapts in a point release; you do not need to update your config. If you want to override a provider’s strategy yourself, see [`providers..strategy`](/starlight-llm-actions/configuration/reference/#providers).