Skip to content

Add comprehensive comparison guide for Cycles vs alternatives#6

Merged
amavashev merged 2 commits into
mainfrom
claude/add-cycles-comparison-post-IfLon
Mar 11, 2026
Merged

Add comprehensive comparison guide for Cycles vs alternatives#6
amavashev merged 2 commits into
mainfrom
claude/add-cycles-comparison-post-IfLon

Conversation

@amavashev
Copy link
Copy Markdown
Contributor

Summary

Added a new conceptual documentation page that compares Cycles to existing tools and approaches teams use for managing autonomous system execution and costs.

Changes

  • New document: concepts/how-cycles-compares-to-rate-limiters-observability-provider-caps-in-app-counters-and-job-schedulers.md

    • Comprehensive comparison of Cycles against five common alternatives: rate limiters, observability platforms, provider budget caps, in-app counters, and job schedulers
    • For each alternative, explains what it does well, where it falls short, and how Cycles differs
    • Includes detailed comparison tables showing feature and capability differences
    • Clarifies that Cycles is complementary to these tools, not a replacement
    • Provides guidance on building well-governed autonomous systems with layered controls
  • Updated navigation: Modified .vitepress/config.ts to add the new guide to the concepts section sidebar

Key Content

The guide establishes that while each alternative solves real problems, none address the core problem Cycles solves: pre-execution, budget-aware governance for autonomous systems. It emphasizes that Cycles fills a gap in the existing tooling landscape and works best as part of a comprehensive control strategy alongside rate limiters, observability, provider caps, and job schedulers.

https://claude.ai/code/session_013CqpHwfkjrnoXKBsZNDcWE

claude added 2 commits March 11, 2026 18:55
Covers five comparisons with structured analysis and tables:
- Rate limiting vs Cycles
- Observability vs Cycles
- Provider budget caps vs Cycles
- In-app counters vs Cycles
- Job schedulers/retries vs Cycles

https://claude.ai/code/session_013CqpHwfkjrnoXKBsZNDcWE
Replaces the plain summary table with a detailed capability matrix
using checkmark/partial/missing indicators across all six approaches.
Adds honest notes about partial ratings and where Cycles has gaps.

https://claude.ai/code/session_013CqpHwfkjrnoXKBsZNDcWE
@amavashev amavashev merged commit b65149c into main Mar 11, 2026
@amavashev amavashev deleted the claude/add-cycles-comparison-post-IfLon branch March 17, 2026 18:30
amavashev added a commit that referenced this pull request May 16, 2026
Apply/skip tally: 6 applied, 0 pushed back.

Applied:

- `ChatCompletionStreamOptions` fields are `Option<bool>` in async-openai
  0.38.x, not raw `bool`. Updated to
  `{ include_usage: Some(true), include_obfuscation: None }` with a
  comment explaining the `None` default.

- Cargo.toml block was missing `thiserror = "2"` even though the
  error-aware example uses `#[derive(thiserror::Error)]`. Added.

- Streaming zero-cap path used `guard.release(...).await?` — if release
  itself errored, the caller would see the release error instead of
  the original zero-cap error. Switched to
  `let _ = guard.release(...).await;` so the typed zero-cap error wins.

- Streaming end-of-stream had an "empty content, but has usage" hole —
  the example would commit on a stream that produced no text. Added an
  empty-`full_text` release-and-bail check before the usage check, so
  the loud-failure stance applies consistently.

- "Other Rust LLM clients" section still showed the old
  `response.usage.map(|u| u.total_tokens as i64)` pattern in the
  adaptation guidance for non-OpenAI providers. Updated to the
  `ok_or(...)?` + `i64::from(...)` shape that matches the rest of the
  doc.

- The `estimate_tokens()` function was referenced in the streaming
  example but only existed as a comment. Made it a real, copy-pasteable
  helper (uses `tiktoken-rs::o200k_base`) and moved the fallback into
  an explicit "Optional: tokenizer fallback for missing-usage chunks"
  subsection, framed as an alternative to the loud-failure default.

Also caught during the same pass:

- The tiktoken-rs stub itself used `as i64` casts on `usize` values —
  exactly the pattern the new gotcha #6 warns against. Switched to
  `i64::try_from(...)?` and changed the function signature to return
  `Result<i64, Box<dyn Error>>` so the conversion error has somewhere
  to go.

Codex verified the runcycles + async-openai 0.38.2 API surface, the
tiktoken-rs API names, and confirmed the shipped
cycles-client-rust/examples/async_openai_completion.rs on main matches
the doc's loud-failure stance.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants