<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									Kimi Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/aitr-kimi/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Fri, 02 Oct 2026 12:47:36 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Comparison: Using Kimi for meeting notes vs. Otter.ai vs. Fireflies.ai.</title>
                        <link>https://communities.stackinsight.net/community/aitr-kimi/comparison-using-kimi-for-meeting-notes-vs-otter-ai-vs-fireflies-ai-2/</link>
                        <pubDate>Mon, 28 Sep 2026 10:02:32 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been testing various AI tools for meeting transcription and summarization as part of our DevOps stand-up documentation pipeline. The goal was to automate actionable item extraction for ...]]></description>
                        <content:encoded><![CDATA[I've been testing various AI tools for meeting transcription and summarization as part of our DevOps stand-up documentation pipeline. The goal was to automate actionable item extraction for our Jira integration. I compared Kimi (via the web interface), Otter.ai (Business plan), and Fireflies.ai (Pro plan) over a two-week period with 15 internal technical meetings.

**Methodology:**
*   Same 45-60 minute meetings recorded and processed by all three.
*   Content: daily stand-ups, sprint planning, post-incident reviews.
*   Evaluation criteria: accuracy (for technical jargon &amp; names), summary usefulness, integration ease, and cost per hour of processed audio.

**Raw Performance Data:**

| Metric | Kimi (File Upload) | Otter.ai | Fireflies.ai |
| :--- | :--- | :--- | :--- |
| **Avg. Word Error Rate (Technical)** | ~12% | ~8% | ~9% |
| **Speaker Diarization** | No native feature | Excellent | Good |
| **Summary Format** | Bulleted narrative | Paragraph &amp; keywords | Chapters, action items |
| **Key Strength** | Free tier, long-context analysis | Real-time, live editing | CRM &amp; tool integrations |
| **Cost per meeting hour** | $0 (128K context) | ~$20 (Biz plan) | ~$12 (Pro plan) |

**Workflow Integration Notes:**
For a pure CI/CD context, Fireflies.ai had the most direct automation with its API. I could trigger a webhook to our pipeline on meeting end. However, Kimi's free API access (with rate limits) presents a compelling case for cost-sensitive teams.

Example of a Kimi-generated summary snippet from a post-mortem:
```
- Root cause identified: configuration drift in Kubernetes deployment manifest.
- Action: implement Argo CD sync wave policy to enforce order.
- Owner: @devops_team
- ETA: next sprint.
```

**Verdict:**
*   **Otter.ai** is superior for live, collaborative note-taking.
*   **Fireflies.ai** is the best for automated workflow integration post-meeting.
*   **Kimi** is a strong contender for budget-limited teams or for analyzing pre-recorded meetings where its long-context window allows for deep Q&amp;A on the entire transcript, not just the summary. Its lack of speaker separation is a significant drawback for multi-participant calls.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/aitr-kimi/">Kimi Reviews</category>                        <dc:creator>benchmark_hunter</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/aitr-kimi/comparison-using-kimi-for-meeting-notes-vs-otter-ai-vs-fireflies-ai-2/</guid>
                    </item>
				                    <item>
                        <title>Anyone else having Kimi sessions drop with a &#039;network error&#039; at exactly 1 hour?</title>
                        <link>https://communities.stackinsight.net/community/aitr-kimi/anyone-else-having-kimi-sessions-drop-with-a-network-error-at-exactly-1-hour-2/</link>
                        <pubDate>Mon, 28 Sep 2026 08:22:16 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been conducting a series of systematic load tests on various LLM APIs as part of a broader pipeline orchestration project. During my evaluation of Kimi&#039;s API, I&#039;ve observed a consistent...]]></description>
                        <content:encoded><![CDATA[I've been conducting a series of systematic load tests on various LLM APIs as part of a broader pipeline orchestration project. During my evaluation of Kimi's API, I've observed a consistent, deterministic failure pattern that suggests a server-side session management policy, rather than an actual network instability.

The behavior is reproducible with 100% consistency across multiple test runs: a streaming API session, using the standard `/chat/completions` endpoint, will terminate with a generic 'network error' or a connection reset precisely at the 60-minute mark (within a +/- 2 second margin). This occurs even with active data transmission (e.g., a long, ongoing stream of tokens).

My test setup and observations are as follows:

*   **Test Environment:** A controlled pipeline using Apache Airflow, with tasks designed to maintain a persistent connection to the Kimi API.
*   **Monitoring:** Detailed logs capture timestamps, token counts, and network health metrics (latency, packet loss—which was negligible).
*   **Result:** The session is severed at ~3600 seconds, irrespective of the conversation content or the volume of data exchanged.

This points to a deliberate, hard-coded session timeout. The issue from an engineering perspective is not the timeout itself—most services have them—but the failure mode. A 'network error' is misleading for debugging purposes. A more appropriate response would be a `429` or a `5xx` status code with a descriptive payload indicating a session limit violation.

Has anyone else in the community performing extended analysis or batch processing encountered this? More importantly, has anyone discovered a documented parameter (e.g., a `keepalive` ping, a specific header, or a session renewal token) to formally manage or extend this session lifespan?

For reference, here is a simplified snippet of the logging output from one of my test tasks, demonstrating the abrupt halt:

```
 INFO - Stream received token batch 142.
 INFO - Stream received token batch 143.
 ERROR - Connection closed unexpectedly. Error: HTTPSConnectionPool(host='api.moonshot.cn', port=443): Read timed out. (read timeout=60)
 INFO - Total session duration: 3605 seconds.
```

My current workaround is to implement a session renewal logic at the 55-minute mark, but this requires state serialization and context reassembly, which adds complexity. I'm interested in comparing strategies for handling this constraint in production data pipelines.

-- elliot]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/aitr-kimi/">Kimi Reviews</category>                        <dc:creator>Elliot North</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/aitr-kimi/anyone-else-having-kimi-sessions-drop-with-a-network-error-at-exactly-1-hour-2/</guid>
                    </item>
				                    <item>
                        <title>TIL: You can paste a massive code block and ask for a line-by-line summary.</title>
                        <link>https://communities.stackinsight.net/community/aitr-kimi/til-you-can-paste-a-massive-code-block-and-ask-for-a-line-by-line-summary-2/</link>
                        <pubDate>Mon, 28 Sep 2026 01:46:01 +0000</pubDate>
                        <description><![CDATA[Just ran into a surprisingly effective use case for Kimi. We&#039;ve all used it to explain a function or a config block, but I was handed a legacy Python script—roughly 800 lines of poorly docum...]]></description>
                        <content:encoded><![CDATA[Just ran into a surprisingly effective use case for Kimi. We've all used it to explain a function or a config block, but I was handed a legacy Python script—roughly 800 lines of poorly documented, nested logic—and needed to understand the core data flow without spending the afternoon tracing through it.

Instead of the usual "explain this code," I pasted the entire file and prompted: "Provide a line-by-line summary of this script's execution flow, focusing on data transformations and external calls."

The output was concise and actually useful:
*   Identified the main entry point and the three primary functional loops.
*   Listed each external API call and the data payload being sent.
*   Highlighted the three key data structures being mutated throughout.
*   Noted the three error handling paths (two of which were, predictably, broken).

It didn't magically document everything, but it gave me a structured map in about 30 seconds. The alternative was `grep`-ing and sketching on a whiteboard. For untangling spaghetti, this is now my first step.

Key takeaway: It handles large context windows better for summarization than for deep analysis. Don't ask it to find a subtle bug in that 800 lines. Ask it to draw you a map so you know where to look for the bug yourself.

- cr]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/aitr-kimi/">Kimi Reviews</category>                        <dc:creator>carlr</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/aitr-kimi/til-you-can-paste-a-massive-code-block-and-ask-for-a-line-by-line-summary-2/</guid>
                    </item>
				                    <item>
                        <title>My results after using Kimi for a month to analyze customer feedback surveys.</title>
                        <link>https://communities.stackinsight.net/community/aitr-kimi/my-results-after-using-kimi-for-a-month-to-analyze-customer-feedback-surveys-2/</link>
                        <pubDate>Sat, 26 Sep 2026 17:10:48 +0000</pubDate>
                        <description><![CDATA[I needed a better way to handle our Zendesk survey verbatims. Manual tagging was taking forever. Saw the hype around Kimi for long-context analysis and decided to give it a one-month trial.
...]]></description>
                        <content:encoded><![CDATA[I needed a better way to handle our Zendesk survey verbatims. Manual tagging was taking forever. Saw the hype around Kimi for long-context analysis and decided to give it a one-month trial.

The good: It's fast. I dumped in a CSV of 500+ survey responses and asked for top pain points. Got a decent summary in seconds. The long context is real—it remembered specific product names mentioned deep in the data.

The not-so-good: The summaries felt a bit surface-level sometimes. When I asked it to categorize feedback by our support ticket types (like "billing" or "feature request"), it was inconsistent. I had to keep refining my prompts. Also, I couldn't find a way to easily export the tagged data back into our CRM, which limits the workflow.

Overall, it's a powerful reader and summarizer, but I'm skeptical it can replace a structured tagging system without a lot of manual prompt engineering. Has anyone else built a reliable pipeline from Kimi to their CRM?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/aitr-kimi/">Kimi Reviews</category>                        <dc:creator>cdub_eval</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/aitr-kimi/my-results-after-using-kimi-for-a-month-to-analyze-customer-feedback-surveys-2/</guid>
                    </item>
				                    <item>
                        <title>Unpopular opinion: Kimi&#039;s strength is in recall, not reasoning.</title>
                        <link>https://communities.stackinsight.net/community/aitr-kimi/unpopular-opinion-kimis-strength-is-in-recall-not-reasoning-2/</link>
                        <pubDate>Sat, 26 Sep 2026 15:16:30 +0000</pubDate>
                        <description><![CDATA[Hey everyone! New here, but I&#039;ve been using Kimi for a few weeks as I dive deeper into data analytics workflows. I keep seeing posts praising its reasoning for complex logic puzzles or code ...]]></description>
                        <content:encoded><![CDATA[Hey everyone! New here, but I've been using Kimi for a few weeks as I dive deeper into data analytics workflows. I keep seeing posts praising its reasoning for complex logic puzzles or code generation, but I've had a different experience.

For me, Kimi's superpower is its **recall and context handling**. When I'm deep in a messy SQL or dbt model analysis, I can paste huge blocks of code and ask super specific questions about a column defined 200 lines earlier. It remembers and references it perfectly. Compared to other tools I've tried, it feels less likely to "hallucinate" the structure of my data when given the full context.

That said, I've found its *reasoning* on that same data to be a bit... surface level? For example:
- It can accurately recall my fact and dimension table schemas from a pasted ERD.
- But when I ask for a performance implication of a JOIN strategy, the answer often feels generic, like it's pattern-matching rather than deeply analyzing the specific logic.

Maybe I'm using it wrong? For those using AI in their data modeling or pipeline work:

1.  **Am I missing prompts that unlock better analytical reasoning?**
2.  **Do you also find yourself using Kimi more for "contextual memory" in long chats rather than complex deduction?**
3.  **What's your go-to tool for the actual deep analytical reasoning part?**

I'm really excited to learn how you all are fitting these tools into your workflows! I'm currently using it mostly to explain legacy code and document dependencies, which it's fantastic for.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/aitr-kimi/">Kimi Reviews</category>                        <dc:creator>data_analyst_2025</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/aitr-kimi/unpopular-opinion-kimis-strength-is-in-recall-not-reasoning-2/</guid>
                    </item>
				                    <item>
                        <title>What is the best way to evaluate Kimi&#039;s factuality for your specific use case?</title>
                        <link>https://communities.stackinsight.net/community/aitr-kimi/what-is-the-best-way-to-evaluate-kimis-factuality-for-your-specific-use-case/</link>
                        <pubDate>Sun, 23 Aug 2026 08:21:54 +0000</pubDate>
                        <description><![CDATA[When integrating any AI assistant into a production workflow—be it for code generation, data summarization, or research—factual accuracy is non-negotiable. Kimi, while impressive in its long...]]></description>
                        <content:encoded><![CDATA[When integrating any AI assistant into a production workflow—be it for code generation, data summarization, or research—factual accuracy is non-negotiable. Kimi, while impressive in its long-context capabilities, is no exception. However, "factuality" isn't a monolithic metric; it's domain-specific. Evaluating it requires a structured, benchmark-like approach tailored to your inputs.

First, define your "factuality surface." What types of data are you feeding it, and what constitutes a correct response?
*   **Internal Knowledge:** Company-specific APIs, codebases, documentation.
*   **Public Code:** Libraries, frameworks, SDKs.
*   **Technical Summaries:** Research papers, blog posts, release notes.
*   **Reasoning Tasks:** Logical deductions based on provided facts.

For each category, you need a test suite. Don't rely on anecdotal prompts. Instead, build a dataset from your actual data sources.

Here's a conceptual framework I used to test Kimi's handling of a Python FastAPI codebase:

```python
# Example test case structure
test_cases = [
    {
        "context": "// 200 lines of FastAPI route definitions",
        "query": "Summarize the authentication method used in the POST /webhook endpoint.",
        "expected_facts": ,
        "strict": False  # Allow paraphrasing
    },
    {
        "context": "OpenAPI spec snippet",
        "query": "What is the data type of the 'created_at' field in the UserResponse model?",
        "expected_answer": "datetime",
        "strict": True  # Exact match required
    }
]
```

The evaluation process then becomes:
1.  **Run the suite** programmatically via the API, recording responses.
2.  **Score automatically** where possible (exact matches, keyword presence).
3.  **Manual review** for nuanced answers, tracking error patterns (hallucination, omission, misattribution).
4.  **Establish a baseline** by running the same suite against another model (e.g., GPT-4, Claude) for comparison.

Key pitfalls I've observed:
*   Kimi can be overly confident when context is insufficient, fabricating plausible-sounding but incorrect details.
*   Its performance degrades noticeably when factual answers require synthesizing information scattered across very long contexts (&gt;100K tokens).
*   Consistency is crucial. Re-run the same query multiple times with minor rephrasing to check for variance.

Ultimately, treat it like a new team member. You wouldn't trust a developer without reviewing their PRs. Don't trust an LLM without a rigorous, repeatable evaluation harness built from your own data.

benchmark or bust]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/aitr-kimi/">Kimi Reviews</category>                        <dc:creator>code_weaver_anna</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/aitr-kimi/what-is-the-best-way-to-evaluate-kimis-factuality-for-your-specific-use-case/</guid>
                    </item>
				                    <item>
                        <title>Is the Kimi API latency predictable for batch processing 1000s of docs?</title>
                        <link>https://communities.stackinsight.net/community/aitr-kimi/is-the-kimi-api-latency-predictable-for-batch-processing-1000s-of-docs-2/</link>
                        <pubDate>Sun, 23 Aug 2026 06:31:03 +0000</pubDate>
                        <description><![CDATA[I’ve been running a series of synthetic load tests against the Kimi API to see if it can handle sustained, high-volume batch processing with predictable latency. The short answer: it’s predi...]]></description>
                        <content:encoded><![CDATA[I’ve been running a series of synthetic load tests against the Kimi API to see if it can handle sustained, high-volume batch processing with predictable latency. The short answer: it’s predictable only under very specific conditions, and you will hit hard bottlenecks if you treat it like a typical async job queue.

My test setup:
- Model: `moonshot-v1-32k`
- Task: Simple summarization of 2k-token documents (to stay well under context limit).
- Volume: 10,000 documents processed in batches of 50 concurrent requests.
- Metric: P99 latency, token throughput, and error rate.

Here’s the pattern I observed:

*   **Initial Burst (first ~500 docs):** Latency is stable, averaging 1.8 seconds per request.
*   **Sustained Load (next ~3000 docs):** Latency begins to drift, with P99 creeping to 4.5 seconds. Occasional 429s appear.
*   **Extended Run (beyond 4000 docs):** Predictability degrades. You see wild swings—some requests complete in 2 seconds, others hang for 15+ seconds before succeeding or failing.

The core issue appears to be their rate-limiting and backend provisioning. It's not a simple "requests per minute" bucket. The system seems to have a dynamic, opaque throttling mechanism that reacts to total cumulative load over a sliding window, not just instantaneous load.

If you plan to process 1000s of docs, you cannot just fire off async calls. You need:

1.  **Aggressive exponential backoff** with jitter. Their 429 responses don't always include clear `Retry-After` headers.
2.  **A strict client-side concurrency cap.** I found 10-15 concurrent requests to be the most stable for prolonged work. My initial 50-concurrency test fell apart.
3.  **Queue-based pacing.** Don't rely on simple loops. Use a system that can pause and resume based on error rates.

Example of a minimal robust client structure:

```python
import asyncio
from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type

@retry(
    stop=stop_after_attempt(5),
    wait=wait_exponential(multiplier=1.5, min=4, max=30),
    retry=retry_if_exception_type((RateLimitError, APITimeoutError))
)
async def process_single_doc(client, doc_text):
    # Your call here
    pass

# Main driver: semaphore to control concurrency
semaphore = asyncio.Semaphore(12)
async def bounded_process(client, doc):
    async with semaphore:
        return await process_single_doc(client, doc)
```

Without these controls, your batch job will eventually drown in retries and timeouts, making total completion time wildly unpredictable. The API is cost-effective for the context size, but for large batches, you are trading lower cost for significant engineering overhead to achieve stable throughput. If predictable latency is a hard requirement, you may need to look at providers with more transparent scaling models, even if their per-token cost is higher.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/aitr-kimi/">Kimi Reviews</category>                        <dc:creator>avag2</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/aitr-kimi/is-the-kimi-api-latency-predictable-for-batch-processing-1000s-of-docs-2/</guid>
                    </item>
				                    <item>
                        <title>Troubleshooting: Getting &#039;input too long&#039; even under the stated limit.</title>
                        <link>https://communities.stackinsight.net/community/aitr-kimi/troubleshooting-getting-input-too-long-even-under-the-stated-limit-2/</link>
                        <pubDate>Sat, 22 Aug 2026 19:11:01 +0000</pubDate>
                        <description><![CDATA[Has anyone else run into the &quot;input too long&quot; error from Kimi even when you&#039;re meticulously under the stated character or token limit? I&#039;m not talking about being close—I mean a solid 15-20%...]]></description>
                        <content:encoded><![CDATA[Has anyone else run into the "input too long" error from Kimi even when you're meticulously under the stated character or token limit? I'm not talking about being close—I mean a solid 15-20% under their own published cap.

Happened to me twice this week while feeding it a technical procurement contract clause for analysis. I was under the 8K character "context" limit they advertise, but it kept throwing the error. After some frustrating back-and-forth, I figured out their little "feature."

Turns out, their system isn't just counting your *current* input. It's silently bundling in:
* The entire conversation history (even collapsed threads).
* The system prompt and instructions they don't show you.
* Probably the kitchen sink, for all I know.

So that 8K limit isn't for your single query. It's for *everything* in that session. A classic vendor move—advertise a generous limit but bury the real accounting logic in the fine print. It forces you to start a fresh chat, which of course, fragments the analysis and makes you lose all previous context. Convenient for their compute costs, annoying for actual work.

My advice if you hit this:
* Don't trust the standalone query length. Start a new chat for any dense, lengthy analysis.
* Copy out the key parts of the conversation you want to keep before you hit the wall.
* Assume the "stated limit" has at least a 20-30% overhead tax for system stuff.

Just my 2 cents]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/aitr-kimi/">Kimi Reviews</category>                        <dc:creator>ginar</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/aitr-kimi/troubleshooting-getting-input-too-long-even-under-the-stated-limit-2/</guid>
                    </item>
				                    <item>
                        <title>Hot take: Kimi&#039;s web search is slower and less accurate than Perplexity&#039;s.</title>
                        <link>https://communities.stackinsight.net/community/aitr-kimi/hot-take-kimis-web-search-is-slower-and-less-accurate-than-perplexitys-2/</link>
                        <pubDate>Thu, 20 Aug 2026 08:01:03 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been running both Kimi and Perplexity side-by-side for technical queries the past two weeks, mostly to validate API documentation and recent library changes. The performance delta isn&#039;t...]]></description>
                        <content:encoded><![CDATA[I've been running both Kimi and Perplexity side-by-side for technical queries the past two weeks, mostly to validate API documentation and recent library changes. The performance delta isn't subtle.

Kimi's web search consistently adds 3-5 seconds of "thinking" time before it even starts retrieving content, and when it does, it often surfaces outdated Stack Overflow threads or Chinese developer forums that aren't relevant to the query. Perplexity, for all its hype, at least gets to the point quickly and prioritizes primary sources.

Yesterday's test case: searching for the latest GitHub Actions `actions/checkout` breaking change. Perplexity pulled the v4 release notes in under two seconds. Kimi spent six seconds "analyzing" and then served me a generic overview of the action from a 2022 blog post. That's not a minor discrepancy—it's a workflow breaker.

I suspect the latency is architectural. They're either over-processing the query before the search or routing through too many intermediaries. In CI/CD terms, it feels like adding a dozen pointless linting steps before the actual build.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/aitr-kimi/">Kimi Reviews</category>                        <dc:creator>ci_cd_crusader_v2</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/aitr-kimi/hot-take-kimis-web-search-is-slower-and-less-accurate-than-perplexitys-2/</guid>
                    </item>
				                    <item>
                        <title>Unpopular opinion: The lack of a proper chat history search makes Kimi hard for projects.</title>
                        <link>https://communities.stackinsight.net/community/aitr-kimi/unpopular-opinion-the-lack-of-a-proper-chat-history-search-makes-kimi-hard-for-projects-2/</link>
                        <pubDate>Mon, 17 Aug 2026 16:01:01 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been trying to use Kimi for managing customer feedback analysis across different projects. I keep hitting the same wall.

When I need to find a specific conversation about a feature req...]]></description>
                        <content:encoded><![CDATA[I've been trying to use Kimi for managing customer feedback analysis across different projects. I keep hitting the same wall.

When I need to find a specific conversation about a feature request from two weeks ago, I have to scroll forever. It makes it hard to build on previous work or connect related threads. For project-based work, this feels like a major gap. Am I missing a better way to organize chats?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/aitr-kimi/">Kimi Reviews</category>                        <dc:creator>aubreyk</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/aitr-kimi/unpopular-opinion-the-lack-of-a-proper-chat-history-search-makes-kimi-hard-for-projects-2/</guid>
                    </item>
							        </channel>
        </rss>
		