How long does the integration take?

Change one base URL in an OpenAI-compatible client, or install the Python or TypeScript SDK; the quickstart routes a first request in a few minutes.

Will this lock us into another vendor?

No. The router is Apache-2.0 open source, your provider keys stay yours, and the API is OpenAI-compatible, so leaving is a change of base URL.

What happens when a provider fails?

The router falls back to the next model your policy allows and records the fallback in the trace, so an outage costs a retry, not an incident.

factory-template - Skill - OpenSmartRoute

Name: factory-template
Author: rightmer-foundry

Imported from rightmer-foundry/factory-template (AGENTS.md). Install upstream with npx skills add rightmer-foundry/factory-template. Copyright stays with the author.

Working in a Foundry project

This repo was created by the Foundry. A human reviews every change from a phone; your job is to make that review quick and safe.

The loop

Work on a branch. Never push to main (it is protected; the push fails).
Push. CI builds, tests, and deploys your branch to this project's preview Worker. The preview is behind Cloudflare Access: only the human can open it, so don't expect to fetch it yourself.
Open a PR. Fill in the template: what changed, how to check it on the preview, risk boxes.
If CI fails, read the check output (or deploy_status from the factory-mcp server), fix it, and push again. Push your own fixes — never ask the human to push to your branch.
The human approves and merges; main deploys to production. To undo a merged change, open a revert PR.

Rules

Never edit .github/ or .factory/. They are protected and the push is rejected. CI changes happen in rightmer-foundry/factory-workflows.
Bindings (D1, KV, R2) come only from the Foundry manifest. Declare them in wrangler.jsonc by name for local dev; the deployer ignores the IDs and binds the real resources. .factory/manifest.json lists what is granted; npm run check-bindings compares the two.
Need a new binding? Call the factory-mcp tool request_bindings and wait until the PR it opens is merged and .factory/manifest.json shows it.
Previews and production have separate databases and buckets. A preview can never touch production data.
Durable Objects work only if the project was created with durable_objects: true (check .factory/manifest.json). They are this Worker's own classes, so you declare them yourself in wrangler.jsonc: bindings under durable_objects.bindings and classes under exports ({ "Room": { "type": "durable-object", "storage": "sqlite" } }), never the legacy migrations array. Rename with a renamed tombstone plus the new entry. Deleting a class ("state": "deleted") destroys its data: previews accept it, production refuses it, so ask the human first. Such projects have one preview URL (<key>--preview), and every push replaces it.
D1 migrations go in migrations/NNNN_name.sql (forward-only, ≤ 1 MB each). They run on the preview database on every branch deploy and on production after merge. A DROP is flagged to the reviewer — avoid it unless asked.
Secrets are set by the human (wrangler secret put), never committed. Read them from env like any binding.

Local development

npm install
npm run dev          # wrangler dev with local D1/KV/R2 simulators
npm test             # vitest in workerd
npm run typecheck
npm run check-bindings

Deploy errors and what to do

`code`	Meaning	Do this
`bad_token`	OIDC token missing, expired or invalid	Re-run the job; if it persists, report it
`wrong_org`	Repo is not in `rightmer-foundry`	Report it; you are in the wrong repo
`untrusted_workflow`	CI did not run through the released workflow	Don't edit `.github/`; report it
`unknown_project`	This repo has no Foundry manifest entry	Check `project_status`; the project may not be provisioned yet
`archived`	The project was archived	Stop; ask the human
`bad_target`	Ref/event/environment don't form a valid preview or production deploy	Push to a branch; only merges deploy production
`stale_run`	An older production run tried to deploy after a newer one	Open a revert PR instead of re-running old runs
`rate_limited`	Too many deploys this hour	Batch your changes; wait and push again
`too_large`	Bundle over 25 MB	Shrink the bundle or assets
`bad_bundle`	Malformed build output or migration file	Fix the build or migration naming (`NNNN_name.sql`)
`flag_not_allowed`	A compatibility flag isn't allowed for this project	Remove it, or ask for it in `projects.yaml`
`migration_failed`	A D1 migration errored; nothing was deployed	Fix the SQL in a new migration and push
`cloudflare_error`	Cloudflare rejected the upload	Read `message`; fix and push, or report it

Install factory-template and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

{ "ocm": "1", "id": "rightmer-foundry-factory-template-factory-template", "kind": "skill", "name": "factory-template", "description": "This repo was created by the Foundry. A human reviews every change from a phone; your job is to make that review quick and safe.", "publisher": "rightmer-foundry", "version": "1.0.0", "capabilities": { "domains": [ "coding" ], "tags": [ "skill-md", "github-agents" ], "languages": [ "en" ] }, "quality_prior": 0.6, "examples": [ "This repo was created by the Foundry. A human reviews every change from a phone; your job is to make that review quick and safe." ], "primary": false, "metadata": { "source": { "provider": "github-agents", "repository": "https://github.com/rightmer-foundry/factory-template", "path": "AGENTS.md", "ref": "12cd9e327c79c78441f3d01f83e472a97f5cf24c", "url": "https://github.com/rightmer-foundry/factory-template/blob/12cd9e327c79c78441f3d01f83e472a97f5cf24c/AGENTS.md", "key": "rightmer-foundry/factory-template/AGENTS.md" } }, "instructions": "# Working in a Foundry project\n\nThis repo was created by the Foundry. A human reviews every change from a\nphone; your job is to make that review quick and safe.\n\n## The loop\n\n1. Work on a branch. Never push to `main` (it is protected; the push fails).\n2. Push. CI builds, tests, and deploys your branch to this project's\n **preview** Worker. The preview is behind Cloudflare Access: only the\n human can open it, so don't expect to fetch it yourself.\n3. Open a PR. Fill in the template: what changed, how to check it on the\n preview, risk boxes.\n4. If CI fails, read the check output (or `deploy", "cost": { "context_tokens": 1046 } }

factory-template

About

Working in a Foundry project

The loop

Rules

Local development

Deploy errors and what to do

Install factory-template and it becomes one more candidate the router can pick - when it fits.

What it costs to adopt - in engineering time.

One base URL

No vendor lock-in

Failover built in

Use it

Manifest

Reviews