When two Ollama models behave differently, inspect their metadata before changing your prompt or hardware. The native Show API returns information about a specific model, including details that can help you understand its quantization, configured parameters and prompt template. Run the inspection against the exact tag your app uses. Save the result alongside one representative request, then compare the two together. The model’s stored configuration explains part of what happened, while the actual request and runtime determine the rest.
Find the exact model to inspect
Start Ollama on your computer and use ollama list to see the models installed locally. Copy the full name and tag your application sends. A short name and a longer tag can refer to different choices in an environment where several variants are available. If you use a development app, look in its settings or its outgoing request log for the exact model field. Compare it with the local list before assuming an error comes from the model itself.
The native API accepts a POST request to http://localhost:11434/api/show. Send a JSON body such as {"model":"YOUR_EXACT_TAG"} with the JSON content type. Replace the placeholder with the installed name you copied. For a command-line check, ollama show YOUR_EXACT_TAG can also provide an overview. See the Ollama API reference for the response fields and optional settings. Use the API form when you want to capture the result from a script or save it beside a test case.
Read the details before comparing behavior
Start with the details the response actually provides for the selected model. Look for its family, parameter size and quantization level where available. These attributes help explain why two downloaded variants can have different memory requirements or generation characteristics. The metadata describes the model variant. To see how the machine currently runs it, check the loaded model information and measure a real task. Our Ollama quantization guide explains questions to ask when choosing which variant to try.
If your test compares a smaller and a larger variant, note the exact identifiers in the results. Use equivalent context settings and the same prompt and output criteria if the comparison calls for it. A reply that finishes early can look fast even if it omitted the information you requested. Check the contents as well as timing. See our guide to measuring Ollama tokens per second and load time for a way to record generation speed separately from startup.
Inspect the template and configured defaults
The template can help explain how the model wraps instructions and messages before generation. Inspect it if a model returns unexpected separators, refuses to treat a message as an instruction or behaves differently in two clients. Compare the message roles and data each client actually sends. Keep a simple prompt and a minimal message history so differences are easier to see. If one client uses a native chat request and another uses a differently formatted prompt, the stored template is one part of the comparison.
Look at any configured parameters returned by the model. You may find settings that influence generation, such as stop sequences or defaults created with a Modelfile. Your app may also supply request options. Record those values separately. If a model ends an answer at a predictable point, compare the default stop sequences and the options on the specific request before changing the prompt. Test a minimal case where you can tell whether the response stopped in the same place twice.
For a model you created locally, compare the stored configuration with the Modelfile you expected to use. Check the stored template and other fields for a deliberate small edit. If the intended change is absent, confirm which model name your client selected and whether you recreated that model under that tag. Our Ollama Modelfile guide covers creating a model with custom instructions. Saving the inspected metadata after each meaningful change can help you trace which variant produced a given evaluation result later.
Build a small diagnostic comparison
For example, suppose a short support summary works in a terminal but comes back with an unexpected prefix in a local app. Record the model and prompt from both requests. Inspect the model’s template and any stop parameters once for each exact tag. Then make a minimal test with one user message and no application-added history. If the simple test works in both places, reintroduce the app’s instructions and history one piece at a time. Find the first change that reproduces the behavior before editing the model or its template.
If the issue is missing information instead, check whether the input was truncated or sent with different context settings. Compare the exact text and message roles provided to both clients. Model metadata can expose capabilities and architectural details where returned. It cannot substitute for checking which inputs reached the server. Keep a short summary of the effective request options beside the inspection output so someone else can repeat the comparison without guessing which UI settings were active.
Before sharing the inspection with colleagues, look through the returned text. A model you built yourself may contain custom system instructions or other configuration you do not want to circulate. Share the specific fields needed to explain the issue. If you ask for help reproducing a problem, include the local model tag, Ollama version, the smallest safe sample prompt and the fields you compared. Remove unrelated examples that contain private material or make the test harder to understand.
Keep a versioned snapshot when you are testing a model used by an application other people depend on. A compact snapshot can include the installed tag, relevant details, template and configured parameters. Put those beside the application’s model selection and the request options for your representative task. Compare the earlier snapshot after refreshing a model or changing configuration. If the template differs, rerun a few small prompts designed to expose the change, then check a real workflow. If nothing relevant differs, move on to app settings, prompt changes or runtime behavior. Preserving that starting point is useful when several changes happened close together and you need to work out which one matters.
Frequently asked questions
Does the Show API run inference?
The endpoint returns model information. Use an inference endpoint such as native chat or generate when the task is to check an actual output. Keep the response and configuration together when you need to compare behavior.
What if a model field is missing?
Check the API documentation and inspect another model to see whether the information is available for either one. Different models can expose different metadata. Leave a field blank in your notes when it was absent.
Why does the application behave differently with the same tag?
Compare the precise request body, history, client integration and runtime options. The same model can receive different instructions or generation settings from different clients. Reproduce the discrepancy with the smallest inputs you can.
Can I use the endpoint to check whether the model is currently loaded?
Use the loaded-model view, such as ollama ps, for runtime status. Inspecting metadata and listing loaded models answer different questions. When diagnosing latency, record both the exact model configuration and whether the system had already loaded it.
