TinyFish concurrency by plan: pay-as-you-go vs Starter vs Pro — how do I increase parallel runs?

Quick Answer: Concurrency in TinyFish is controlled by your plan. Pay-as-you-go gives you low baseline parallelism, Starter bumps that up for steady workflows, and Pro unlocks high-throughput runs; you increase parallel runs by upgrading plans or talking to sales for Enterprise-level concurrency.

Frequently Asked Questions

How does TinyFish concurrency work across pay-as-you-go, Starter, and Pro plans?

Short Answer: Pay-as-you-go gives you baseline concurrency for testing and light workflows, Starter adds more parallel agents for small production use, and Pro is designed for high-volume teams that need significantly higher concurrency out of the box.

Expanded Explanation:
Concurrency in TinyFish is about how many Web Agents you can run at the same time without queuing. Each “agent” is a live browser-backed workflow: navigate, authenticate, fill forms, handle anti-bot, extract or transact, then return structured results via API. When you run 20, 50, or 1,000 agents in parallel, you’re effectively compressing a 3–5 day manual process into minutes.

Plans gate this concurrency so you can match throughput to your stage:

• Pay-as-you-go is ideal for initial integration, low-frequency workflows, or bursty experiments. You get all the platform capabilities, but concurrency is intentionally conservative so you don’t accidentally overrun a site or your budget.
• Starter gives you more headroom for recurring workflows—think a few portals or competitor checks you run daily.
• Pro is tuned for engineering teams who care about throughput as a KPI, with significantly higher concurrent agents (e.g., 50 parallel agents and 25x throughput vs Starter in the current lineup) and longer run history.

If you hit concurrency limits frequently, that’s a signal to step up to a plan built for sustained parallel execution or talk to sales about Enterprise.

Key Takeaways:

• Concurrency = how many TinyFish agents you can run at the same time.
• Pay-as-you-go, Starter, and Pro each set different ceilings so you can align throughput with your workload and budget.

---

How do I increase the number of parallel runs my team can execute?

Short Answer: To increase parallel runs, you either upgrade your TinyFish plan (e.g., Starter → Pro) or work with TinyFish to size an Enterprise deployment with custom concurrency.

Expanded Explanation:
When you see runs queued or delayed, it usually isn’t a “bug”—you’re just at your concurrent agent limit. Increasing concurrency is about moving to a plan that matches your true workload: how many sites, how many workflows, how often, and how quickly you need data back.

The platform is serverless from your perspective: you don’t provision browsers, proxies, or LLM capacity. You simply pick a plan with the concurrency and monthly step budget you need. As your volume and concurrency requirements grow, TinyFish’s all-inclusive pricing (steps, browsers, residential proxy, anti-bot, LLM) makes it predictable to scale without juggling multiple vendors.

Steps:

1. Check your current plan limits in the TinyFish dashboard (Plan / Billing section) and note current concurrency and monthly steps.
2. Map your workload: how many agents you want running in parallel during peak (e.g., 5 carriers, 20 cities, 200 competitor SKUs).
3. Upgrade or talk to sales: move from pay-as-you-go/Starter to Pro directly in-app, or contact sales for Enterprise-level concurrency and dedicated infrastructure.

---

How do pay-as-you-go, Starter, and Pro compare for concurrent agents and throughput?

Short Answer: Pay-as-you-go is suitable for light, sporadic use; Starter supports regular workflows with modest parallelism; Pro is built for high-volume teams with up to 50 concurrent agents and much higher throughput.

Expanded Explanation:
The core difference between plans isn’t just monthly steps; it’s how fast you can turn those steps into decisions. Concurrency is the speed lever: 10k steps at low concurrency might take hours; the same 10k steps at higher concurrency can finish in minutes.

Here’s how to think about it in practice:

• Pay-as-you-go: Use this when you’re validating workflows, building your first integration, or running infrequent jobs. It keeps cost and concurrency conservative so you can experiment safely.
• Starter: Once you have repeatable workflows (e.g., daily portal checks, weekly competitor sampling), Starter’s included step budget and improved throughput make it viable for small production loads.
• Pro: This is where “web operations” starts to look like an internal service. Pro includes 16,500 steps/month, 50 concurrent agents (25x throughput vs Starter), extended 180-day run history, and priority support—built for teams that want to compress multi-portal, multi-country tasks into sub-minute cycles.

Comparison Snapshot:

• Option A: Pay-as-you-go
  • Best for: experiments, prototypes, low-frequency tasks.
  • Concurrency: baseline, conservative.
• Option B: Starter
  • Best for: small, recurring production workflows.
  • Concurrency: higher than pay-as-you-go, adequate for a handful of simultaneous processes.
• Option C: Pro
  • Best for: engineering teams with high-volume, time-sensitive workflows that need up to 50 concurrent agents and long run history.
• Best for: Any team that cares about “minutes, not days” should aim for Pro or higher; pay-as-you-go and Starter are stepping stones, not end states.

---

How do I actually implement higher concurrency in my TinyFish workflows?

Short Answer: Once you’re on a plan with higher concurrency, you implement it by structuring your workloads into many parallel agent runs instead of one huge sequential run.

Expanded Explanation:
Concurrency isn’t automatic just because your plan allows it—you need to design your jobs to exploit it. TinyFish’s Web Agents are stateless, serverless workers; you get scale by fanning out dozens or hundreds of independent runs that share the same workflow definition but target different sites, regions, or accounts.

From a systems perspective, you’re moving from “big nightly batch job” thinking to “many small, parallel jobs”:

• Break your universe into shards (by site, region, portal, or customer cohort).
• Launch one agent per shard concurrently via the API.
• Let TinyFish handle browsers, proxies, anti-bot, and LLM inference behind the scenes.

What You Need:

• A plan with sufficient concurrency and steps (e.g., Pro or Enterprise for 50+ concurrent agents or higher).
• A calling pattern in your code (loop/fan-out in your app, task queue, or orchestrator) that triggers multiple TinyFish runs in parallel instead of serially.

---

How should I choose a concurrency level strategically for my use case?

Short Answer: Align concurrency with your operational risk and freshness requirements: if stale or delayed data is expensive (pricing, availability, eligibility), choose higher concurrency so you can recompute ground truth in minutes.

Expanded Explanation:
Most teams underestimate how much concurrency they need until something breaks—prices drift, carriers change underwriting rules, or a competitor launches a promotion over a weekend. If your system is still “catching up” on yesterday’s runs, you’re making decisions off stale truth.

A practical way to size concurrency:

• Back into it from SLAs: If you need fresh quotes or prices every hour across 20+ sites, you can’t afford serial execution. You need enough concurrent agents to hit all targets inside that window with margin for retries and anti-bot friction.
• Consider failure modes: Anti-bot, login friction, or long forms can stretch runtimes. Higher concurrency lets you over-provision parallelism so that failures and retries don’t blow your schedule.
• Remember cost dynamics: With TinyFish’s per-step pricing and all-inclusive unit economics (remote browser, residential proxy, anti-bot, LLM included), the cost of higher concurrency is mostly about plan tier, not chasing extra infrastructure line items.

Why It Matters:

• Impact on decision quality: Higher concurrency lets you run “everywhere at once,” so pricing, routing, or eligibility decisions depend on live reality, not yesterday’s cache.
• Impact on operations: Well-sized concurrency lets you replace fragile in-house Playwright/Selenium stacks and 3–5 day manual ops with predictable, sub-minute workflows that run unattended in the cloud.

---

Quick Recap

Concurrency in TinyFish is the throttle on how fast you can turn web workflows into structured, decision-ready outputs. Pay-as-you-go is for light use and validation, Starter is for modest recurring workflows, and Pro is tuned for high-volume teams with up to 50 concurrent agents and 25x throughput vs Starter. To increase parallel runs, upgrade to a plan that matches your real workload, design your jobs to fan out into many independent agent runs, and, if you’re operating at true enterprise scale or need custom SLAs, talk to sales about an Enterprise deployment with dedicated infrastructure and concurrency tailored to your targets.

Next Step

Get Started