TinyFish Cookbook: Sample Apps for a Hosted Web Agent
A collection of sample apps and recipes built with the TinyFish web agent. Open-source examples for you to learn & build!
At a glance
- What is it?
- The TinyFish Cookbook is a TypeScript collection of recipes, demos and integrations around TinyFish's Search, Fetch, Agent and Browser endpoints. It is useful as a reference for wiring a hosted web agent into an app, but it is documentation by example, not a library you install.
- Who is it for?
- Adopt the cookbook if you already pay for or plan to evaluate TinyFish and want working TypeScript starting points for Search, Fetch or the Agent endpoint; the viet-bike-scout and openbox-deals recipes show the multi-agent fan-out pattern more concretely than the endpoint table does.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 15 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What the Cookbook Is Actually For
The repository describes itself as a growing collection of recipes, demos and automations built on TinyFish, which it calls the web layer for AI agents. That framing is accurate to the contents: every folder is a standalone project that calls one or more TinyFish HTTP endpoints, and none of them implement retrieval, rendering or browser control themselves. The problem it addresses is not a missing library but a missing starting point. If you have an agent that needs to search the live web, read a page as clean text, or drive a multi-step browser flow on a site with no API, the cookbook gives you a working call shape rather than a blank file. The intended reader is a TypeScript developer who has already decided to use a hosted agent service and wants to see how the pieces fit before writing their own client. It is a poor fit for anyone evaluating whether hosted agents are the right architecture at all, since the repository takes that decision as given.
Four Endpoints, Two Free, Two Metered
The README lays out a four-layer model. Search at api.search.tinyfish.ai returns structured JSON results and is described as rank-stable across calls, with a stated latency under 0.5s. Fetch at api.fetch.tinyfish.ai takes URLs and returns clean markdown, JSON or HTML, and the README claims real full-browser rendering plus free failed URLs. Agent takes a URL and a natural-language goal, navigates, acts, and returns JSON, with the README quoting roughly 10 seconds to minutes. Browser rents a managed cloud browser you connect your own Playwright or Selenium scripts to. Search and Fetch are marked free; Agent and Browser are metered. That split matters more than the feature list. The free tier covers retrieval, which is the part most agents need on every turn, while the expensive part is the multi-step automation. The README also claims built-in stealth with rotating proxies and stealth profiles at no extra cost, and a Vault for credentials and session memory that mentions 1Password JIT and encrypted session reuse. Those claims are the vendor's, and the cookbook does not include a benchmark or a test that would let you confirm them independently.
How the Recipes Are Organized
Recipes are grouped by what they do rather than by underlying technique. The Featured category holds five projects with live Vercel demos: viet-bike-scout for motorbike rental price comparison across Vietnamese cities using parallel browser agents, tutor-finder for exam tutor discovery across platforms, openbox-deals which aggregates open-box and refurbished listings across eight retailers, silicon-signal for semiconductor supply chain signals, and summer-school-finder, whose entry is cut off in the supplied README. The parallel-browser phrasing in viet-bike-scout is the most informative detail available, because it implies the pattern the cookbook is really teaching: fan out one goal per site, then merge the JSON. Beyond Featured, the README lists a scripts directory containing a Raycast extension for search, and an Agent Skill installed with a single npx command. The Skill is the more interesting artifact for coding-agent users, since the README says it teaches an agent when to reach for Search versus Fetch versus Agent. That is a routing decision, and it is the kind of thing that is usually left undocumented.
Getting a Recipe Running
The README gives three invocation paths and they are not interchangeable. The REST examples use curl against the three hosts, with the key passed as X-API-Key: $TINYFISH_API_KEY. Search is a GET with a query parameter, Fetch is a POST with a JSON body containing a urls array, and the Agent call is a streaming POST to https://agent.tinyfish.ai/v1/automation/run-sse with a body of url and goal, run with curl -N so the stream is not buffered. For the MCP route you add a server entry pointing at https://mcp.tinyfish.ai to your client config, which the README shows for Claude Code, Cursor, Codex, ChatGPT desktop and other MCP-aware clients. The CLI route is npm install -g @tiny-fish/cli followed by tinyfish auth login, then tinyfish search query and tinyfish fetch content get. The README makes a specific argument for the CLI over piping results through a model: it writes to the filesystem so tokens stay out of the context window. SDKs exist for both languages, pip install tinyfish and npm install @tiny-fish/sdk, and the README states they have full parity across Search, Fetch, Browser, Agent and Vault. Individual recipe folders presumably carry their own setup steps, but the supplied README does not reproduce them, so treat the endpoint examples as the reliable part.
Where the Sample-App Format Breaks Down
The clearest limitation is structural. There are no retrieved releases for this repository, so there is no versioned artifact to pin and no changelog to read when a recipe stops working. Each folder is a standalone project, which means dependency drift is per-folder and nothing in the repository tells you which recipes track the current SDK. The Agent endpoint's own latency profile is the second constraint: the README quotes roughly 10 seconds to minutes, which rules it out for request paths that need a sub-second response, and the streaming SSE endpoint exists precisely because the call is long. Cost is the third. Search and Fetch being free today is a pricing decision, not a protocol guarantee, and the README itself frames it as a current state. If your architecture depends on free retrieval, that dependency sits on a vendor's pricing page rather than on anything in this repository. Finally, the repository is TypeScript-first, and the recipes are demos. A demo that fans out parallel browser agents across cities is a good illustration and a poor template for concurrency limits, retries or partial-failure handling, none of which the README addresses.
Compared With Running Your Own Playwright and Crawler
The obvious alternative is the stack the README positions against: hand-rolled Playwright for rendering plus a self-hosted crawler for retrieval. The difference is where the operational burden sits. Self-hosted Playwright gives you full control over browser version, proxy rotation and session storage, and it costs nothing per call beyond your own compute. What it does not give you is the proxy pool, the stealth profiles or the credential vault, and the README explicitly lists rotating proxies and stealth profiles as included with TinyFish rather than as add-ons. The Fetch endpoint is also pitched as a drop-in replacement for Firecrawl or a native LLM fetch, which is a narrower and more honest comparison than the general agent framing: for the specific job of turning a URL into clean markdown, the trade is a per-call hosted dependency against maintaining your own extraction pipeline and paying tokens on navigation, scripts and cookie banners. The Agent endpoint has no clean self-hosted equivalent in this comparison, because the value is the managed browser fleet plus the natural-language goal interface, and reproducing that is a project rather than a script.
Licence, Upkeep and What the Repository Does Not Say
The repository is MIT-licensed according to its metadata, and the README's badge links to a LICENSE file rather than restating terms. That distinction matters here because the code in the folders is sample code calling a hosted service; the MIT grant covers the samples, not the service, and nothing in the supplied material describes terms for the API itself. Upkeep cost is the more practical question. With no releases and a last push of 2026-08-31, the repository is active but unversioned, so you should expect to read the diff rather than a changelog when something breaks. The recipes that depend on the latest SDK are the ones most likely to need attention. The Agent Skill is the cheapest thing to keep current, since npx skills add github.com/tinyfish-io/tinyfish-cookbook --skill use-tinyfish pulls the current version at install time. This is not legal advice; read the LICENSE file and the TinyFish service terms yourself before shipping anything built from these samples.
Editorial conclusion
Adopt the cookbook if you already pay for or plan to evaluate TinyFish and want working TypeScript starting points for Search, Fetch or the Agent endpoint; the viet-bike-scout and openbox-deals recipes show the multi-agent fan-out pattern more concretely than the endpoint table does. Skip it if you need a self-hosted crawler, a stable versioned SDK surface, or anything you can run without a TinyFish API key, because every recipe here is a thin client over a metered hosted service. Before committing, verify the current pricing and rate limits for Search and Fetch on the TinyFish dashboard, confirm which recipes still build against the latest @tiny-fish/sdk, and check the LICENSE file, since the README links to it rather than stating the MIT terms inline.
Community notes