syntaqxA workspace runs up to 12 jobs at once on g1t's machines while the pool has room, not 4. Every workspace was held to 4 hosted jobs at once (RUNNING_PER_WORKSPACE), so flagon-io's own CI and Deploy, about 13 jobs between them, waited their turn: 108 to 518 seconds after their runs were made, for 29aba25d, 58def404 and 0a5d1f6d, though the pool of 40 sandboxes (20 standard, 10 g1t-2core, 10 g1t-4core) was mostly idle. A workspace still always has its 4; past them, start_queued starts more, up to 12 (BURST_PER_WORKSPACE), while every workspace's hosted jobs together leave 8 sandboxes free (POOL_HEADROOM), so another workspace's first jobs still start at once (has_room). Deploy's own concurrency group still lands one deploy at a time. The architecture's Compute limits say so. Checked: cargo test -p g1t-actions-service (115 passing), npm run test:deploy (92).36c7309History
- ..
- chat
- folios
- people
- team
- actions-settings.tsx
- ai.tsx
- apps.tsx
- ask.ts
- audit-export.ts
- audit.tsx
- billing.tsx
- chat-settings.tsx
- code-access.tsx
- code-overview.tsx
- emoji.tsx
- guardrails.tsx
- home-seen.ts
- home.tsx
- insights.tsx
- integrations-directory.tsx
- integrations.tsx
- layout.tsx
- member-invitations.tsx
- members.tsx
- moved.ts
- new.tsx
- onboarding.ts
- overview.tsx
- package.tsx
- packages.tsx
- people.tsx
- permissions.tsx
- personal-access-tokens.tsx
- pins.ts
- projects.tsx
- repositories.tsx
- rules.tsx
- ruleset.tsx
- runners.tsx
- secrets.tsx
- security-bypass.tsx
- security-patterns.tsx
- security-settings.tsx
- security.tsx
- settings.tsx
- soon.tsx
- statement-csv.ts
- statement-entries.ts
- team-new.tsx
- teams.tsx
- token-new.tsx
- token.tsx
- tokens.tsx
- usage.tsx
- webhooks.tsx
- workspace-overview.tsx