TL;DR

OpenRouter Workspaces (GA 22/04/2026) là một primitive mới cho phép bạn chia một OpenRouter organization thành nhiều môi trường độc lập. Mỗi workspace có API key riêng, routing defaults riêng, guardrails riêng, observability riêng. Giải pháp chính thức cho vấn đề cũ: dev/staging/prod bị trộn chung, experimental usage ăn ngân sách production, một key rò rỉ ảnh hưởng toàn org.

Chỉ khả dụng trên tier Pay-as-you-goEnterprise vì cần Management API key. Python SDK endpoints đã live (beta).

Có gì mới

Trước đây, cách duy nhất để cô lập môi trường trên OpenRouter là tạo nhiều API key rồi tự gắn nhãn — spending cap, activity log, routing rule đều phải config riêng ở từng key, rất dễ trôi. Workspaces biến cái pattern ad-hoc đó thành một primitive có quản trị trung tâm.

Một workspace gom đủ 4 trụ:

  • API keys — mỗi workspace có pool key riêng, cô lập hoàn toàn credential và usage.
  • Routing defaults — set sẵn default_text_model, default_image_model, và default_provider_sort (price | throughput | latency | exacto) cho workspace đó. Request không override sẽ dùng defaults này.
  • Guardrails — spending cap reset theo ngày/tuần/tháng, model/provider allowlist, enforce Zero Data Retention. Khi nhiều guardrail cùng apply, rule chặt hơn thắng.
  • Observability — bật/tắt broadcast traces sang external platform, điều chỉnh I/O logging sampling rate từ 0.0001 đến 1, filter logging theo API key ID.

Vì sao đáng quan tâm

Nếu bạn đang dùng OpenRouter cho nhiều product, nhiều client, hoặc nhiều stage, thì trước đây bạn phải tự xây "fake workspaces" bằng naming convention trên API key. Cái đó fail theo đúng 3 cách quen thuộc:

  1. Một dev test prompt mới trên key production → cháy budget tháng.
  2. Client A thấy log của client B vì chung org feed.
  3. Muốn đổi provider sort sang latency cho realtime agent → phải pass query param ở từng request thay vì set default.

Workspaces đóng 3 lỗ đó ở layer hạ tầng, không cần code thêm ở app.

Thông số kỹ thuật

SDK Python (beta) expose namespace open_router.workspaces với các method sau — tất cả yêu cầu Management API key:

MethodMục đíchGhi chú
listLiệt kê workspaces của user
createTạo workspace mớiCần name + slug (lowercase, alphanumeric, hyphens)
getLấy workspace theo ID hoặc slug
updateCập nhật name / slug / defaults / observability
deleteXoá workspaceKhông xoá được default workspace; không xoá được nếu còn active API key
bulk_add_membersThêm user vào workspaceRole inherit từ organization
bulk_remove_membersXoá user khỏi workspaceKhông xoá được nếu user còn active API key

Create request hỗ trợ các trường: default_text_model, default_image_model, default_provider_sort, io_logging_sampling_rate, io_logging_api_key_ids, is_observability_broadcast_enabled, is_observability_io_logging_enabled, is_data_discount_logging_enabled, description.

Error surface: 400 / 401 / 403 / 404 / 500 — không có rate limit đặc biệt cho Workspaces API ngoài giới hạn chung của account.

So sánh với pattern cũ và đối thủ

Khía cạnhTrước WorkspacesVới Workspaces
Cô lập môi trườngThủ công qua naming keyFirst-class primitive, có key/budget/routing/telemetry riêng
Routing configPer-request hoặc per-keyWorkspace-level defaults
GuardrailsOrg-wide hoặc per-keyPer-workspace baseline, stricter wins
ObservabilityMột pipeline chungSampling & broadcast độc lập
Cost trackingTự chia theo tag keyNative split theo workspace

So với OpenAI Projects (ra 2024), Workspaces đi xa hơn một bước: cover cả routing preferenceprovider-level guardrails — thứ OpenAI Projects không có vì OpenAI chỉ phục vụ model của mình. Gần nhất với AWS organization/account-per-env, nhưng gọn hơn nhiều cho bài toán LLM routing.

Use cases thực tế

  • Dev / staging / prod — mỗi env có spending cap + allowlist riêng. Staging cháy budget không đụng prod.
  • Agency nhiều client — một workspace/client, tách hoá đơn, tách log, tách guardrail theo yêu cầu compliance của từng client.
  • Multi-product team — attribute LLM spend về từng product P&L rõ ràng, không còn mò.
  • Research org — share credit đắt tiền cho nhiều team, xuất report riêng cho từng grant.
  • Realtime vs batch — workspace realtime set default_provider_sort=latency, workspace batch set price. Code app không đổi.
  • Regulated workload — bật ZDR + allowlist provider cho pipeline HIPAA/finance, vẫn để workspace khác free-form cho experiment.

Hạn chế & pricing

Hạn chế cần biết:

  • Workspace mặc định không xoá được. Workspace còn active key không xoá được.
  • Member còn active key trong workspace không remove được.
  • Một organization cap cứng 10 members, muốn nâng phải email support.
  • Activity feed vẫn để usage metadata (model, cost, timing) visible cho tất cả org members — không private per-workspace. Prompt/response thì không bao giờ được OpenRouter lưu.
  • Python SDK đang ở trạng thái beta, endpoint có thể thay đổi trước GA stable.
  • Mọi thao tác Workspaces SDK đều đòi Management API key.

Pricing:

TierWorkspaces?Platform feeRate limit
Free❌ (thiếu Management API key)N/A50 req/ngày
Pay-as-you-go5.5% trên giá providerHigh global limits
Enterprise✅ (có bulk discount)Thương lượngOptional dedicated

Giá token của từng model vẫn là pass-through từ provider — Workspaces không đội thêm cost per model.

Kết luận & next

Workspaces là bước trưởng thành bắt buộc của một LLM gateway. OpenRouter đã có routing, guardrails, observability từ trước — Workspaces chỉ là cái container gom các layer đó lại cho đúng pattern "một tổ chức, nhiều môi trường" mà mọi team lớn đều cần. Ai đang chạy LLM ở scale mà chưa dùng workspace/project concept thì trước sau cũng phải tự build — tiết kiệm được một chiếc hệ thống nội bộ.

Việc cần làm nếu bạn đang dùng OpenRouter cho team:

  1. Upgrade lên Pay-as-you-go nếu còn ở Free.
  2. Issue Management API key.
  3. Tạo 3 workspace — dev, staging, production — set guardrails và routing defaults khác nhau.
  4. Migrate API key hiện tại vào workspace tương ứng.
  5. Bật broadcast observability sang Datadog/Axiom/whatever cho workspace production.

Nguồn: OpenRouter announcement, Workspaces Python SDK reference, Organization Management docs, Guardrails docs, Pricing.