Introducing FRAMES-F1: a model that can pay for premium data

Today, we're releasing FRAMES-F1, our first composite model.

You can use it like any other, in the chat interface or through an OpenAI-compatible API with model: "frames-f1". But it can do something other models can't: pay for licensed, machine-accessible data when the task requires it.

Give FRAMES-F1 a task. It discovers the right paid tools and data sources from a catalog of roughly 37,000 endpoints, pays for them on your behalf, verifies the provider actually delivered, and returns a clean result with source verification and a confidence score.

In this post, we're sharing a look at the composite architecture behind FRAMES-F1 and why we built it this way.

Why does FRAMES-F1 need to exist?

Frontier models have gotten remarkably good at reasoning.

Most real-world agent tasks don't fail on reasoning. They fail on access.

Of all the data online, what's publicly reachable through search engines is only the tip of the iceberg. In every field, quality data sits behind a paywall.

Machine-payable tools are improving access to paid endpoints. Protocols like x402 and MPP let any API charge per call, settled in stablecoins, with no signup required. Supply is growing fast, and that supply is where our catalog comes from. But raw supply creates new problems:

1. Discovery. Which of 37,000 tools actually solves this task?
2. Execution. Paying cents per call means handling agentic wallets, stablecoins, and settlement across different networks.
3. Trust. A payment protocol guarantees the payment, not the delivery. Plenty of tools happily take your money and return an empty 200 OK.
4. Accounting. An agent that pays twelve providers across three chains produces a billing mess nobody wants to reconcile.

Earlier this year we launched Frames AgentWallet, a skill.md based crypto wallet that works in any agent client. The onboarding was just pasting a prompt (agents could onboard themselves), and we also provided a registry of useful tools for agents to consume.

It was novel and grew fast, processing over half a million transactions to date.

This data was fundamental for pivoting into FRAMES-F1, and made fine-tuning the composite model possible. Of all the transactions, over 90% were data related, which indicated the main use case for micropayments today.

Additionally, each transaction became a record of whether the endpoint actually delivered. That record became the data FRAMES-F1 was optimized on, and it taught us two things: the hard problem isn't paying for tools, it's finding the correct tool for each task and validating that the outcome is satisfactory. And none of that complexity should ever reach the user.

So what actually is it, and what do I use it for?

FRAMES-F1 is a composite model optimized for fetching proprietary data.

Ask a normal model a question and it answers from its training data (usually 3 to 12 months stale on release) plus whatever a search engine can reach. FRAMES-F1 has a third source: the paid layer of the internet.

If you do any research online, you could be getting better results by accessing this data. In practice, that looks like:

• Deep research. Get one verified answer from primary sources instead of twenty stale blog posts. "Compare Portugal's, Spain's and Italy's digital nomad visas from official government sources: income thresholds, fees, processing times, first-year tax. One table, a link behind every cell."
• Finance and investing. Run the screens and cross-references analysts spend days building by hand. "Screen every US-listed company for the fundamentals I care about, then show me where insiders are buying at the same time institutions are adding." Each filing is public. The join is an analysis product nobody publishes.
• Sales and GTM. Turn live buying signals into a lead list you can contact (verified work emails). "Find B2B companies that posted their first sales hire in the last 30 days, and get me the founder or VP of Sales with a verified email and LinkedIn profile." Hiring signals, org charts, and deliverable contact data only exist in paid databases.
• E-commerce. Know your competitive position right now, not last month. "Check my competitors' current price and stock across Amazon, Walmart and Home Depot, and tell me if I should reprice." A cross-retailer snapshot of this minute exists nowhere on the open web.
• Marketing. Hear what people say about your product when they're not talking to you. "Search Reddit and X for what people actually say about my product, full comment threads included, and tell me if sentiment shifted after the last release." The signal is buried in hundreds of comments no search engine will surface.

You never pick a provider, hold an API key, or touch a wallet. You describe what you need. FRAMES-F1 knows where to get the data, and whether the outcome is good.

How does FRAMES-F1 work?

FRAMES-F1 is not a single base model. It is a composite system of specialized models and a deterministic execution layer. This allows us to optimize each step of the process.

Every request moves through three phases.

Plan. Determines, based on the request, which tools are needed and retrieves memories of similar past runs.

Execute. It receives the suggested tools, health-checks the candidates, and invokes the paid calls. That keeps its context small and fast, and it draws a hard line between deciding and spending: the model picks the tool, our execution layer approves the payment.

Payment protocols verify payments. FRAMES-F1 verifies delivery.

Verify. It checks every paid response for hollow results, empty bodies, and errors dressed up as success, then scores the run on how much of the task was actually covered. If coverage comes back low, it replans and takes one corrective pass before returning. Every outcome has to be > 80% confidence for the user to be charged.

Tool Reliability System

Every paid call FRAMES-F1 makes records whether the provider actually delivered, and that verdict feeds the Tool Reliability System: a living reliability score for every tool in the catalog, built entirely from real, settled executions.

The effect compounds. Tools that reliably deliver rise in the catalog ranking and get picked first. Verified-good runs become memories that future planning passes retrieve, so the system gets better at a task every time it completes one.

This is the part of FRAMES-F1 we couldn't have bought or scraped. Anyone can assemble a list of 37,000 providers; almost nobody knows which paid tools actually deliver after payment. FRAMES-F1 learns that from every run it executes, on top of the half a million settled transactions that came before it.

Blockchain & Stablecoins

Blockchains are the right design for machine-executed micropayments: fast settlement, on-chain verification, and internet-native payment protocols. But none of that feels natural to a human user, so we take the whole layer out of the equation.

We meter everything into a single unit (credits) and take care of all the execution: to support all the existing tools, under the hood we route calls through x402 and MPP using USDC and CASH across Solana (via pay.sh), Base, and Tempo.

Pricing

FRAMES-F1 is available today on four plans. Every plan runs the same model and the entire tool catalog is accessible on every plan; the only difference between tiers is how many credits you get and the price per credit.

Full details on the pricing page.

Getting started

FRAMES-F1 is available today.

• In the browser, by asking it directly on frames.ag/chat.
• On most clients (like ChatGPT or Claude), via MCP. Full details on frames.ag/docs/mcp.
• Via API, as direct inference (via the Vercel AI SDK or any OpenAI-compatible client). Full details on frames.ag/docs/api.

Models learned to think. Then they learned to use tools. FRAMES-F1 is the next step: a model that can transact.

It discovers what a task needs, pays for it, proves it was delivered, and hands you one receipt.

We are super excited about the evolution of FRAMES-F1 and are looking forward to what you will use it for. If anything arises, feel free to contact us on Telegram.