ShareAI
AIRun open-source language models through the ShareAI decentralized GPU network. Agents reach open-weight models without provisioning hardware or signing a per-model contract.
What This Integration Enables
ShareAI is among the narrowest connectors in this category and the most opinionated about why it exists. There is one action. It runs a prompt against an open-weight model hosted on a decentralized GPU network and returns the completed response. No image generation, no embeddings, no catalog. What you get instead is a way to run open-weight models without buying hardware and without signing a hosting contract per model, which is the actual obstacle for most teams that say they want open weights.
The connector is honest about the constraints that come with that, and you should design around them rather than discover them. ShareAI documents exactly one endpoint and two request fields, model and messages, so no sampling parameters are exposed here. None are documented, and inventing them would be worse than omitting them. Model is a free-text field, deliberately: ShareAI publishes no models endpoint, so a picker would have to be backed by a list nobody can verify. Tags use a name:variant form such as deepseek-r1:32b, and the current roster lives on ShareAI's own models page because it changes as providers join and leave the network. Requests route to whichever provider is available, so response time varies with model size and network conditions.
Read together, those constraints tell you where this belongs in a multi-model estate. It is the right connector for high-volume internal work where an open-weight model is good enough and the cost profile matters: classification, tagging, extraction, first-pass drafting. It is the wrong connector for a step with a hard latency budget or one that needs fine sampling control. FlowRunner's BYOK model applies here as everywhere: the ShareAI key is yours, and so is the decision about which work is allowed to leave on it.
Without FlowRunner
With FlowRunner
Use Case Scenarios
Bulk classification that would be expensive on a frontier model
Thousands of internal support notes need topic tags before they are useful for reporting. The agent sends each one to a mid-size open-weight model through Create Chat Completion, parses the returned tag, and writes it back to the record in Airtable. This is exactly the shape of work where a smaller open-weight model pays for itself: high volume, low ambiguity, and a wrong tag is a correction rather than an incident.
A cheap first pass in front of an expensive second one
An inbound message flow uses an open-weight model to decide whether a message needs a real answer at all. Most do not. The share that does gets escalated to a stronger model on a different connector, and only that share carries the higher cost. The routing decision is a step in the flow, so the split is visible and adjustable rather than buried in a vendor's routing logic.
Keeping open-weight options live during a vendor review
A team evaluating whether to commit to a single proprietary vendor keeps a parallel branch running the same prompts against an open-weight model, writing both outputs to a comparison table in Notion. When the vendor conversation happens, the team is arguing from its own side-by-side output rather than from a benchmark chart, and it has a working fallback if the negotiation goes badly.
Human-in-Loop Highlight
The gate here comes straight out of the free-text model field. Because ShareAI publishes no models endpoint, there is nothing for an agent to enumerate when a tag stops resolving, and tags do stop resolving when the provider hosting that model leaves the network. An agent that reacts by trying the nearest similar tag has just put an unreviewed open-weight model into a path whose output someone downstream will act on. So it does not guess. The agent holds the batch, keeps the already-completed results, and asks the flow owner in Slack: "The tag deepseek-r1:32b returned no completion on 40 of 500 documents and appears to have left the network. I will not substitute a model on my own. Name a replacement tag and I will re-run only the 40 that failed, or I can hold the batch as is." A person picks the model. The agent does the other 500 things. That division of labor is the whole idea behind Orchestration as a Service: the platform runs the work, and the human keeps the decisions that carry consequences.
Agent Capabilities
1 actionsText Generation
1- Create Chat Completion Runs a prompt against any open-source model hosted on the ShareAI decentralized GPU network and returns the completed response. Supply a Prompt for single-turn work or a full Messages array to preserve multi-turn context. Requests route to an available provider on the network, so latency varies with model size and network availability, and responses come back complete rather than streamed. Model is a free-text tag in `name:variant` form, since ShareAI publishes no catalog endpoint to back a picker.
Frequently Asked Questions
What can FlowRunner do with ShareAI?
FlowRunner agents can run Create Chat Completion in ShareAI.
Does connecting ShareAI to FlowRunner require OAuth?
No. ShareAI connects to FlowRunner with an API key, no OAuth flow required.
Can ShareAI trigger a FlowRunner workflow automatically?
ShareAI doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with ShareAI
$100 in credits. No card required. Connect in minutes.