Would you use an API that automatically backtests your time series and returns a forecast?

I’m building a forecasting API for developers and businesses.

The idea is:

  • Send a time series through an API
  • Specify the forecast horizon
  • Automatically run rolling backtests on the historical data
  • Report how well the model performs on that particular series
  • Generate a future forecast with prediction intervals

The API would look something like:

POST /forecast

You send historical data and receive a forecast, accuracy metrics, and prediction intervals.

I’m currently considering Chronos-2 as the forecasting model rather than building a large collection of models.

I’m trying to find out whether this solves a problem that people would actually pay for. If you work with forecasting in a real business or project, would this save you time? What other features would you want?

reddit.com
u/Square_Light1441 — 14 days ago
▲ 1 r/OpenSourceAI+1 crossposts

New local claude code?

I essentially created the local equivalent of Claude code for local models.

Quick Setup:

  • pip install golden-agent
  • golden-agent setup
  • That's it! Models and llama.cpp binary and lazy-downloaded

I did do a BUNCH of research on the models, and after a TON of extensive testing on my end, this was the final set chosen:

Tiny -> LFM 2.5 2.6B(official QAT q4) -> 4gb vram or 8gb ram

Lite -> Ornith 1.5 9B(official Q4) -> 8gb vram or 12 gb ram

Pro -> Qwen 3.8 27b(community QAT Q2) -> 16gb vram or 16gb ram

I also used Q5 KV across the board, which worked great for me; try it out and lemme know if it sucks. I can bump it up to Q6.

Also added Dflash draft models for Lite and Pro so you guys can run them faster!

Note: Uses general optimal settings by default; you can change it in the .golden_agent/inference.json file

The choice for tiny was pretty obvious; it's by far the SOTA model in its weight class. Ornith 1.5 9B was also really good and seemed to be the best model around the abandoned 9B size, obviously we also had to get the local LLM KING Qwen 3.8 27B, now I know A LOT of people have been locked out hardware-wise, so I found a crazy score with this community QAT Q2! The HF card numbers are also kinda representative of the fact that, if you run it at 0.7 temp and 1.05 repeat penalty, I personally couldn't tell much of a difference at all from Unsloth v3 UD Q4 quant with 0.7 temp and no repeat penalty(as recommended by Unsloth), so I hope this will open the doors to a LOT more people.

Repo: https://github.com/yashneil75/Golden-Agent

Coming in future releases:

  • MCP
  • Skills system

Note: I did repost this cause the earlier post was kinda bad... Anyway! I've been optimizing for ease of use and the "just works" feel, and I know you guys are more of the "I'd rather spend 10 hours optimizing it myself for the love of the game," but give it a shot, let me know what you think, and oh, don't forget to drop a Star!!

reddit.com
u/Square_Light1441 — 2 months ago

yall are sleeping on qwen 3.8 27b q2 + q2 dflash + q5 kv

ok bit more context: it's actually a

QAT Q2 for Qwen 3.8 27 B: https://huggingface.co/sdkyuan/qwen3.8-27B-qat-q2_0-gguf

QAT Q2 for DFlash model: https://huggingface.co/HermiHg/Qwen3.8-27B-DFlash2-Q2_K_S-MIX-GGUF

Q5 KV seems to cause 0 problems for me; I've used it up to 200K tokens of context.

Total RAM usage is liek 13-14 ish gb and I've seen very little degradation with the QAT Q2 3.8 27B

Its just crazy that these days with a 12gb card (fits if drop down to 100K context) you can run a model thats more capable than sonnet 4.6, genuinely crazy stuff

u/Square_Light1441 — 2 months ago

GitLord: Performance Leap & Database-Grade Reliability

The New Era of Agent Persistence

GitLord just got faster, smarter, and more powerful. With our latest performance improvements, GitLord now rivals traditional databases in speed and reliability—while keeping every agent interaction inspectable, rewindable, and auditable.

What's New: Performance & Reliability

Performance Breakthroughs

  • Optimized Git I/O: Reduced commit overhead through batched tree operations and CAS deduplication
  • Instant Turn Lookups: Indexed git log enables sub-millisecond access to any turn in agent history
  • Parallel Subagent Execution: Spawn and drain multiple subagents simultaneously without blocking
  • Smart Context Assembly: Intelligent dedup, summarization, and token budget management mean no wasted API calls

Database-Grade Durability

  • Full ACID Guarantees: Every agent turn is an atomic Git commit—no partial writes, no lost state
  • Point-in-Time Recovery: Rewind to any checkpoint in seconds. Compare states with gitlord diff
  • Distributed Readiness: Git-backed storage works seamlessly with multi-replica setups
  • Built-in Audit Trail: Every decision, every tool call, every model swap is immutable and traceable

Core Features You Get Out of the Box

Multi-Agent Orchestration

from gitlord import Session, SessionConfig

config = SessionConfig(log_repo_path="log")
session = Session.create("my-agent", config)

# Main agent + spawned subagents, all coordinated
session.append_user_turn("Analyze this dataset across 3 teams")
subagent = session.spawn_subagent("data-processor")
result = subagent.complete(prompt)
session.append_system_turn(f"Subagent result: {result}")

Integrated MCP

Seamlessly wire up any external tool without rewiring your agent:

from gitlord.mcp import MCPServer

# Discover tools from any MCP server
server = MCPServer(uri="stdio://python -m my_mcp_server")
tools = server.discover_tools()

# Call tools like a native method
result = server.call_tool("fetch_data", {"source": "api"})
session.append_system_turn(f"Tool result: {result}")

Out-of-the-box integrations: Filesystem, Git, databases, APIs, anything with an MCP server.

Built-in RAG

from gitlord.rag import RAGIndex

# Vector-backed semantic search over your data
rag = RAGIndex(collection_name="docs", embedding_model="all-minilm")
rag.add_documents([doc1, doc2, doc3])

# MMR search for diversity + relevance
results = rag.search("how to optimize queries", k=5)
session.append_system_turn(f"Context: {results}")

Why it matters: Ground your agents in your actual data. ChromaDB-backed, flexible embedding models.

Provider & Model Abstraction

Switch models, providers, or fallback chains with zero code changes:

from gitlord.model import LLMRouter

router = LLMRouter(
    models=["claude-opus", "gpt-4", "local-llama"],
    fallback_chain=True  # Auto-retry on failure
)

# One call, intelligent routing
response = router.complete(prompt, schema=tool_schema)

Supports: OpenAI, Anthropic, Cohere, Ollama, Bedrock, Azure, vLLM, and 50+ more—all unified under one API.

The Architecture: Where Performance Lives

Module What It Does Performance Win
gitlord.git Git plumbing, tree/commit construction, CAS updates Batched writes, dedup = 70% faster commits
gitlord.session Session lifecycle, turn append, rewind Indexed lookup = instant turn access
gitlord.subagent Spawn, complete, drain subagents Parallel execution = no blocking
gitlord.context Dedup, summarization, token budgeting Smart filtering = fewer API tokens
gitlord.mcp MCP server lifecycle, tool discovery, crash recovery Single unified tool interface
gitlord.rag ChromaDB vector index, MMR search Semantic retrieval, ranked by relevance
gitlord.model LLM router, schema translation, retry/fallback Provider-agnostic, intelligent fallback
gitlord.index JSON index rebuild from git log Fast state reconstruction from history
gitlord.cli run, log, tree, show, rewind, diff, index Git-native debugging & inspection

Why This Matters: Beyond a Database

Traditional Databases Are Black Boxes

  • State changes are logged, but the logic is opaque
  • Debugging means sifting through logs and state snapshots
  • Auditing requires external compliance tools

GitLord Keeps You in Control

  • Every turn is inspectable: gitlord show <sha> reveals the exact JSON state
  • Every branch is debuggable: gitlord diff compares agent decisions side-by-side
  • Every rewind is instant: Checkpoint any state, fork from anywhere
  • Every integration is pluggable: MCP + RAG + custom providers, no rewiring needed
  • Every deployment is auditable: Git history = compliance-ready audit trail

Getting Started in 30 Seconds

# Install
pip install gitlord[all]  # includes MCP, RAG, LLM routing

# Create an agent session
python -c "
from gitlord import Session, SessionConfig

config = SessionConfig(log_repo_path='log')
session = Session.create('my-agent', config)
session.append_user_turn('Hello, what is 2+2?')

turns = session.get_turns()
for t in turns:
    print(f'[{t.role}] {t.content[:80]}')
"

# View the git history
gitlord log my-agent
gitlord tree my-agent

Real-World Use Cases

  • Research Agents: Spawn subagents for literature review, data processing, and analysis. Rewind to explore alternate hypotheses.
  • Enterprise Workflows: RAG over internal docs + tool use via MCP. Every decision is traceable for compliance.
  • AI Teams: Coordinate multi-agent workflows with shared MCP tools. Use different models per agent, compare outputs.
  • Prompt Engineering: Experiment with model providers and fallback chains. Inspect exactly what each model saw.

Try It Now

bash

pip install gitlord[all]
gitlord run my-session

Then explore:

  • gitlord log my-session — see the turn history
  • gitlord tree my-session — see the branch structure
  • gitlord show <sha> — inspect a turn in detail
  • gitlord rewind my-session <sha> — go back in time

Join the Community

Have feedback? Found a use case? Want to contribute?

  • GitHub Issues: Report bugs, request features
  • Discussions: Ask questions, share your agents
  • Contribute: PRs welcome for integrations, optimizations, and docs

GitLord: Agent orchestration that's as reliable as your database, and twice as transparent.

Repo link in comments; starring helps more than you think!

reddit.com
u/Square_Light1441 — 3 months ago

I stopped building a database for my AI agents and just used git. Turns out git already solved most of the hard problems.

If you've built anything with multi-agent systems, you've hit these walls:

  • Agent state lives in some ad-hoc JSON blob or a Postgres table nobody trusts
  • You can't "undo" a bad turn without nuking everything after it
  • Subagents spawn, do work, and their reasoning trail disappears into a summary
  • Debugging "why did the agent do that" means grepping logs, not actually seeing the decision tree
  • Every framework reinvents branching, history, and diffing — badly

So I built an orchestration framework where every session, every subagent, every single turn is a git commit. Not "git for version control of your code" — git as the actual storage engine and source of truth for agent execution history.

How it works

  • Sessions and subagents are branches. refs/agents/<session-id> is the root. Spawn a subagent, get a branch off the parent's current tip: refs/agents/<session-id>/<subagent-id>. Nest as deep as you want.
  • Turns are commits. Every user message, assistant reply, tool call, and tool result is a JSON blob, committed with structured trailers (turn number, role, agent id, token counts, linked workspace commit). git log on any branch is your execution trace.
  • Subagents don't merge back; they just link back. When a subagent finishes, its final commit SHA gets written into a trailer on the parent's next commit (Subagent-Result: <sha>). Full traceability, zero merge-conflict nonsense.
  • Rewind is a first-class operation, not a hack. agent rewind <session> --to <sha> --run "try again" checks out a new branch at that point and continues from there. The original branch and everything after it stay intact and reachable. You can explore five different futures from the same past without losing any of them.
  • Concurrent subagents don't fight over a lock. Commits are built with plumbing (hash-object, mktree, commit-tree) — no working tree, no staging area — so parallel subagent writers on different branches never contend. Ref updates use compare-and-swap.
  • A separate workspace repo holds actual project files, with git worktree giving each subagent an isolated checkout for concurrent file edits, cross-referenced back into the log via commit SHA.

Why is this bigger than "agent memory"

  • Auditability for free. Every decision an agent made is a diffable, signable, timestamped git object. Compliance and debugging stop being an afterthought.
  • Retrieval without extra infrastructure. A vector index (Chroma) is derived from the git log — rebuildable at any time, never the source of truth. If it breaks, delete it and rebuild.
  • Context management that doesn't destroy history. Deduplication and summarization happen only at read time, when assembling context for the next LLM call. The log itself stays full-fidelity forever — you can always go back and see exactly what was said.
  • Model-agnostic by default. Calls route through LiteLLM, so parent and subagents can run on completely different models (a cheap model for a subagent grinding through file reads, a frontier model for the orchestrator).
  • Tools are pluggable, not hardcoded. MCP servers handle tool access (filesystem, browser, search, fetch, whatever you add). New tool = one config entry, no core changes.
  • No proprietary format, no vendor lock-in. It's a git repo. git log, git show, git diff All just work. Clone it, grep it, back it up with infrastructure you already trust.

This isn't a "yet another agent framework" niche play; it's useful for anyone building single agents, multi-agent pipelines, coding assistants, research agents, or long-running autonomous workflows who is tired of losing history, trust, and debuggability the moment things get complex.

Try it / break it

I want this stress-tested by people building real things, not just toy demos. If you've been burned by an agent framework that loses state, can't explain itself, or turns debugging into archaeology this is built for you.

Repo link in comments. Issues, PRs, and discussions are more than welcome!

reddit.com
u/Square_Light1441 — 3 months ago
▲ 13 r/AISystemsEngineering+9 crossposts

Alternative Approach to Agent Execution Tracing: Git-Backed Storage

Curious about your thoughts on this. Been using LangChain for agents, but hit a wall with tracing/reproducibility.

Built GitLord as an alternative approach: instead of traditional logs, use Git as the execution backend. Every turn = Git commit.

Comparison to LangChain tracing:

  • LangChain: JSON logs, good visualization
  • GitLord: Git commits, full history, rewindable, forkable

Benefits:

  • Actual reproducibility (fork a conversation)
  • Easier debugging (git log, git diff)
  • Auditability (immutable commits)
  • Checkpointing (rewind to any turn)

Not trying to replace LangChain (it's great for other things). But for teams that need reproducibility + auditability, this might be useful.

Works standalone or alongside LangChain tools.

GitHub

Would love feedback from the LangChain community. What do you look for in agent tracing tools?

u/Square_Light1441 — 3 months ago