How to Ground SambaNova LLMs with Real-Time Web Search Using Linkup

TL;DR

• SambaCloud runs open-source models like Llama and DeepSeek at industry-leading inference speed on SambaNova's RDU architecture but speed doesn't fix what the model doesn't know.
• Linkup connects any SambaCloud model to live web data through a single API call, so answers are grounded in current sources instead of frozen training data.
• Setup takes is straightforward: Create a virtual environment ans install the Linkup and SambaNova SDKs
• The example notebook uses standard function calling: the model decides when a query needs a search, Linkup runs it, and the sourced results get fed back for a grounded final answer.
• Linkup's SimpleQA accuracy benchmark and free query tier make it a low-friction way to test grounding before committing to a provider.
• The example uses sourcedAnswer output, but Linkup also supports raw searchResults and schema-driven structured output — the latter matters for legal and finance workflows that need extracted fields, not prose.

Fast inference still needs to be right

SambaNova has spent the last year making a strong case that inference, not training, is where AI infrastructure decisions actually get made, and its RDU architecture backs that up with real throughput numbers on models like Llama 70B and DeepSeek 671B.

That's the right problem to solve. A model that generates tokens quickly but from a training cutoff months or years old will still confidently hallucinate a stock price, a policy change, or a product spec it will just do it faster.

That's the gap Linkup is built to close. Native web search built into an LLM can cite a source and still misrepresent what that source says; grounding means the model's answer is constrained by retrieved, verifiable content, not just informed by it. Pairing SambaCloud's inference speed with Linkup's retrieval layer means the model is both fast and current, which is the actual bar for production use.

SambaNova has published an official integration for exactly this pairing. Here's how to set it up.

Prerequisites

Before you start, you'll need a SambaCloud account and API key, a Linkup account and API key (sign up at app.linkup.so/sign-up), and Python 3.9 or later.

Setting up the integration

Clone SambaNova's integrations repository and move into the Linkup directory:

git clone https://github.com/sambanova/integrations.git
cd integrations/linkup

Create and activate a virtual environment so the dependencies stay isolated from the rest of your system:

python -m venv .venv
source .venv/bin/activate

Install the two SDKs that do the actual work — Linkup for retrieval, SambaNova for inference:

pip install linkup-sdk==0.9.0
pip install sambanova==1.2.0

Or, if you'd rather install everything the repo needs in one pass:

pip install -r requirements.txt

Finally, set both API keys as environment variables. A .env file in the project directory keeps them out of your shell history:

LINKUP_API_KEY="your-linkup-api-key"
SAMBANOVA_API_KEY="your-sambanova-api-key"

How the integration actually works

The example notebook doesn't just fire a search and stuff results into a prompt, it wires Linkup in as a tool the model can call on its own, using standard OpenAI-style function calling. That distinction matters: the model decides when a query needs grounding, rather than every request paying the latency cost of a search it might not need.

First, initialize both clients:

import os
from linkup import LinkupClient
from sambanova import SambaNova
import json

os.environ["LINKUP_API_KEY"] = "your-api-key"
os.environ["SAMBANOVA_API_KEY"] = "your-api-key"

linkup_client = LinkupClient()
sambanova_client = SambaNova(api_key=os.environ["SAMBANOVA_API_KEY"])

Then define search_web as a tool the model can invoke, and send it a question alongside that tool definition:

tools = [{
    "type": "function",
    "function": {
        "name": "search_web",
        "description": "Search the web in real time. Use this tool whenever the user needs trusted facts, news, or source-backed information.",
        "parameters": {
            "type": "object",
            "properties": {
                "query": {"type": "string", "description": "The search query"}
            },
            "required": ["query"]
        }
    }
}]


messages = [{"role": "user", "content": "Tell me about SambaNova RDU chips"}]

response = sambanova_client.chat.completions.create(
    model="gpt-oss-120b",
    messages=messages,
    tools=tools
)

If the model decides it needs current information, it returns a tool call instead of a direct answer. The final step catches that, runs the actual Linkup search, and feeds the sourced results back in for a grounded response:

if response.choices[0].message.tool_calls:
    tool_call = response.choices[0].message.tool_calls[0]
    args = json.loads(tool_call.function.arguments)

    linkup_response = linkup_client.search(
        query=args["query"],
        depth="standard",
        output_type="sourcedAnswer",
        structured_output_schema=None
    )
    search_results = json.dumps(linkup_response.model_dump())

    messages.append(response.choices[0].message)
    messages.append({
        "role": "tool",
        "name": "search_web",
        "content": search_results,
        "tool_call_id": tool_call.id
    })

    final_response = sambanova_client.chat.completions.create(
        model="gpt-oss-120b",
        messages=messages
    )
    print(final_response.choices[0].message.content)
else:
    print(response.choices[0].message.content)

This example defaults to output_type="sourcedAnswer", which fits a conversational use case: the model asks a question, gets a synthesized answer with sources attached, and responds. But Linkup's /search endpoint actually supports three output types, and which one belongs in your pipeline depends on what happens after the search, not just on wanting "grounding" in the abstract.

sourcedAnswer is the right default for exactly the notebook's use case — a chat-style agent that needs to answer a question directly, with citations riding along for verification.

searchResults skips the synthesis step and hands back the raw ranked documents instead, which matters if you want to control how context gets assembled yourself — feeding specific chunks into a SambaCloud model with your own prompt template, rather than trusting Linkup's summarization.

structured is the one that doesn't get enough attention in most integration writeups: instead of prose, it returns a JSON object shaped to a schema you define, so a query like "what's the latest 10-K filing date for this company" comes back as {"filing_date": "2026-03-15"} rather than a sentence you'd have to parse yourself. That's the output type worth reaching for in legal and finance workflows, where the downstream system wants a field, not a paragraph.

Independent of output type, there's also a depth parameter — fast, standard, or deep — that trades search thoroughness for latency. standard is what the notebook uses and is the reasonable default; deep runs a more exhaustive search when accuracy matters more than shaving off a second, which is often the case for the same legal and finance queries that call for structured output.

When to use Linkup + SambaNova

This combination earns its place in a stack for a specific set of reasons, not as a default choice for every project:

• High speed. SambaCloud's RDU-based inference is already tuned for low latency; pairing it with Linkup's fast or standard depth keeps the retrieval step from becoming the bottleneck in latency-sensitive agents.
• High accuracy. When a wrong answer is costly. We’ve explained how expansive could be a low accurate web search tools (TL;DR, long context → too many tokens. Short context → requires several calls)
• Legal and finance. Regulated, high-stakes domains are where structured output type does its best work — pulling a specific filing date, clause, or figure into a defined schema instead of leaving the model to describe it in prose. It's also where sourcing the claim matters as much as getting it right.
• High QPS. Agentic workloads that spawn many parallel calls — sub-agents each pulling live context mid-task — need a retrieval layer built for concurrency, not just for occasional lookups. That's a production concern SambaCloud users running multi-agent systems will recognize as soon as they scale past a demo.

What you're actually testing

Run this with a genuinely current question — a recent release, a current price, an event from the last few weeks — and compare the tool-call path against a plain completion with no tools argument at all. The difference is usually the clearest way to see what grounding buys you, because the failure mode of an ungrounded model is rarely an obvious error. It's a fluent, confident answer that's simply wrong, delivered at whatever inference speed the underlying chip provides.

FAQs

What does grounding actually improve if the model already has web access? Many LLMs already have some form of built-in web search, but "has web access" and "is grounded" aren't the same thing — a model can retrieve a page and still misstate or misattribute what's on it. Grounding constrains the output to what the retrieved content actually supports, which is a narrower and more verifiable claim.

Do I have control over cost? Mostly through the parameters you're already setting in the code above. Linkup runs prepaid, pay-as-you-go rather than subscription-based, so you're never billed for more than you've topped up and depth and output_type directly set the cost per call and no surprises, whatever the amount of tokens you’ll need. Linkup cost is predictible and design for scale.

Does this integration work with any model on SambaCloud? The example notebook uses gpt-oss-120b, but the pattern isn't model-specific — it's standard OpenAI-style function calling, so swapping in any other tool-calling-capable model on SambaCloud is a one-line change to the model parameter.