# Use Vaultfire with local AI

A local AI model runs on your computer rather than a cloud inference service. Vaultfire does not require a particular model vendor. A model needs a tool-capable application to connect it to Vaultfire; downloading model weights alone does not create that connection.

## The simplest starting point: LM Studio

LM Studio supports local models and remote MCP servers. MCP is the connection that lets an AI application discover a tool, ask it a specific question and read the result. Follow [LM Studio's MCP instructions](https://lmstudio.ai/docs/app/mcp) for its current interface and supported versions.

1. Install LM Studio from its official website and load a local model that supports tool use. Model downloads, hardware requirements and tool-use quality vary. Select a local model, not a cloud-backed model.
2. Open **Program**, then **Install > Edit mcp.json**. Merge the server entry from the [Vaultfire configuration](/local-ai/lm-studio.mcp.json) into your existing `mcpServers` object. Do not replace unrelated server entries.
3. Save the file. Enable the Vaultfire tools in the conversation if the application asks. Review each tool request before allowing it.
4. Ask: “Use vaultfire_list_operations to list the available Vaultfire operations. Then use vaultfire_get_operation for /api/x402/trust/contracts. Explain whether it is read-only, whether payment would be required to execute it, and what is still disabled. Do not pay, sign or submit a transaction.”
5. Inspect the tool results, not just the model's summary. Discovery should report 76 operations, including two free operations. Getting an operation's description is free even when executing the described operation would require payment.

The configuration adds only a remote HTTP URL. It does not execute an installer, open a shell, configure a wallet, provide a payment credential or grant filesystem access. It exposes five read-only Vaultfire tools; it does not authorize writes or spending.

## Local does not necessarily mean offline

With the configuration above, model inference can stay on your computer, but tool requests go to `https://theloopbreaker.com/api/mcp`. That server receives the tool name and arguments and normal request metadata. Your application's privacy settings and behavior also matter. Never include passwords, wallet seeds, private keys or confidential conversation text in tool arguments.

To keep discovery requests on your own machine, advanced builders can run the verified website source locally and change the URL to `http://127.0.0.1:3000/api/mcp`. Use the documented development prerequisites and `pnpm run dev` in `repos/theloopbreaker-site`. Do not expose the development server to the public internet. Local operation discovery and operation-description tools use packaged data; live service or oracle status can require external network access. Release-identity checks can fail closed without genuine publisher evidence. Do not invent that evidence to make a local check turn green.

Running a local model is not the same as running a local blockchain. Public-chain execution still needs a network connection, supported software, explicit authorization and any applicable fees. V3 activation and production funds remain disabled.

## Ollama and other local runtimes

Ollama supports [tool calling](https://docs.ollama.com/capabilities/tool-calling) and a [local API](https://docs.ollama.com/api/introduction). Use a tool-capable agent application that connects both to your local runtime and to a Streamable HTTP MCP server. The MCP server is `https://theloopbreaker.com/api/mcp`; Ollama's local inference URL is a different endpoint. Do not enter the MCP URL as a model-provider API URL.

You do not need to send model prompts to a cloud inference provider to use this design. However, this release's MCP transport and tool tests are not an end-to-end certification of every model, LM Studio version or Ollama runner. Confirm the visible tool call on your actual setup before relying on a generated answer.

## Troubleshooting and safe recovery

- **No tools appear:** check the application's MCP support, the saved configuration and the exact `/api/mcp` URL. A JSON-RPC MCP endpoint is not a normal chat webpage.
- **The model only describes a tool:** verify the model supports tool use and that the conversation has the tools enabled. A plausible answer without a visible tool result is not execution evidence.
- **A request is rejected:** inspect the error and the current operation contract. Keep origin protections, argument validation and rate limits enabled; do not bypass them with wildcard settings.
- **A status is degraded or unavailable:** preserve that result. A retry is not permission to pay or change networks.
- **You no longer want the connection:** disable the Vaultfire tools or remove only the `vaultfire-read-only` entry. No Vaultfire wallet permission was granted by this configuration.

## Direction: the whole Vaultfire stack should be self-hostable

The long-term target is not merely a local model connected to a cloud service. It is an operator-controlled stack: website, API and MCP services, agents, model inference, storage, receipts, local development chains and verification tooling. This is an architectural direction, not a declaration that every shipped integration already works offline.

- **Available local building blocks:** inspect the source, run the developer website, use packaged operation discovery, execute the supported Anvil consent example and local HTTP/SQLite receipt example, and run the documented native/program-test and SDK checks with their pinned prerequisites. These are development and review environments, not a funded production installation.
- **Work still required for a complete distribution:** one supported installer/container composition, service configuration without mandatory cloud vendors, local durable-store adapters for every supported path, protected operator keys, backups and restore tests, upgrade/rollback procedures, resource budgets and a full first-contact acceptance run. No such all-in-one installation is claimed in this release.
- **Provider-independent release identity:** a future self-hosted publisher needs its own authenticated source-and-artifact receipt. It must not invent Vercel metadata or impersonate the canonical website's publisher to bypass a gate.
- **Network and evidence boundaries:** a local chain can support isolated tests or a separately operated network, but it is not the existing public Base or Solana network. Public settlement needs connectivity and consensus. External prices, attestations, delivery networks and cross-chain observations remain explicit dependencies; unavailable evidence must not be replaced with fabricated “verified” values.
- **Control stays with the operator:** local operation must not quietly add telemetry, cloud model fallback, automatic payments or expanded signing authority. Preserve explicit consent, bounded permissions, meaningful exit and the distinction between protected principal and separately funded reserves or rewards.

The governing rule remains: morals over metrics, privacy over surveillance, and freedom over control. A metric or local AI prediction is not proof of human wellbeing or permission to seize principal.

Start with [the browser check and builder Quickstart](/v3/get-started). Use the separate [local HTTP evaluation](/docs/x402-local-evaluation.md) for explicitly simulated payment transports and real local receipt recovery; it is not funded public-chain execution.